Ed Sweetman | 1 Feb 04:05 2006
Picon
Picon

roughly .25 second delay in playback of avi files

I say avi files because I dont have any reliably in sync media files in 
other formats.

The only other video players i have to compare mplayer to is gxine and 
windows media player and vlc in windows (the windows players are on a 
different 32bit computer).   My box is running dual core athlon 64 in 
64bit mode. 
Kernel is 2.6.16-rc1 (though this has been going on in every kernel 
version i've tried since i made the box)

mplayer version is cvs (over the course of the previous weeks till now)
alsa playback, xv video output

I even tried the stream delay patch posted to the devel list and still 
no change.

The problem is, playback of media either encoded by mencoder or 
transcode or virtualdub is played back at about a quarter of a second 
off, almost always the audio precedes the video.  I played with 
different values of delay, and .25 seems to bring the audio back in sync 
with every one I tried that was out of sync.   Only a couple seem to be 
in sync by default, and it seems to be a fluke that it is, since they 
were encoded by the same encoder using the same settings and the same 
codec as the ones that are now out of sync.

The reason I believe this is an mplayer problem is that before i changed 
to a 64bit system, on my old athlon tbird, these videos were in sync, 
and right now, playing from the exact same copies, in windows (on 
another box) they are in sync and with gxine (same box as mplayer) they 
are in sync.  Only mplayer seems to be out of sync on most of the video 
(Continue reading)

Corey Hickey | 1 Feb 05:05 2006

Re: roughly .25 second delay in playback of avi files

Ed Sweetman wrote:
> I say avi files because I dont have any reliably in sync media files in 
> other formats.
> 
> The only other video players i have to compare mplayer to is gxine and 
> windows media player and vlc in windows (the windows players are on a 
> different 32bit computer).   My box is running dual core athlon 64 in 
> 64bit mode. 
> Kernel is 2.6.16-rc1 (though this has been going on in every kernel 
> version i've tried since i made the box)
> 
> mplayer version is cvs (over the course of the previous weeks till now)
> alsa playback, xv video output
> 
> I even tried the stream delay patch posted to the devel list and still 
> no change.

Neither of the logs you posted show either stream being delayed by
dwStart, so the patch I'm working on isn't applicable to playing them
back correctly.

Un-delayed video stream from your attached log:
====== STREAM Header =====
Type: vids   FCC: xvid (64697678)
Flags: 0
Priority: 0   Language: 0
InitialFrames: 0
Rate: 2997/125 = 23.976
Start: 0   Len: 137657        <--- "Start", on this line, is 0
Suggested BufferSize: 127016
(Continue reading)

Kichigai Mentat | 1 Feb 06:59 2006
Picon
Picon

Re: Compiling MPlayer CVS On OS X Errors


"Linux: the operating system with a CLUE... Command Line User  
Environment."
  --(seen in a posting in comp.software.testing)

On Jan 30, 2006, at 13.54, Mohammad A. Haque wrote:

> On Jan 30, 2006, at 13:45, Kichigai Mentat wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Jan 30, 2006, at 09.02, Mohammad A. Haque wrote:
>>
>>> Matched up to your configuration and everything still compiled  
>>> and ran fine here. I did have to hack up cdparanoia/libcdio  
>>> support to get it compiled but that only explains your _read_toc  
>>> undefined symbol. I'll clean that code up some and post a patch.  
>>> For now you can bypass this with the --disable-cdparanoia -- 
>>> disable-libcdio configure flags.
>> That'll be just fine for me. I didn't really plan to use MPlayer  
>> with CD audio anyway.
>>>
>>> Did you do a clean install when you installed 10.4 or was it an  
>>> upgrade? My guess is that some library was compiled with an older  
>>> version of gcc and now you're trying to compile mplayer with gcc  
>>> 4.0.0
>> Clean install with 10.4.
>>>
>>> If it is the case where you have upgraded from an older system,  
(Continue reading)

Lunadog | 1 Feb 09:45 2006

nsv problems

Shoutcast nsv video streams seem to be well handled on the whole,
however a few streams do not seem to work properly. They seem to be
ones that have two nsv files (i.e. one with adverts and the other with
main content). Mplayer plays the first file but when the stream
switches to the second file, it locks up.

Some examples are available on the tv listing in my program tunapie

http://www.sourceforge.net/projects/tunapie

I apologise, but most of the files where this problem occurs most
frequently are adult content, so you have to install tunapie with the
--adult switch. I know that none of the dldvd streams work properly.

Some of the urls for these streams (although I am not sure if they
change frequently):

http://69.9.181.179:9500
http://69.9.181.179:8750
http://66.28.200.43:7669

Interestingly, vlc seems able to play these streams without problem,
but is less able to play most other nsv streams than mplayer.

Also if I record the streams using streamripper, the full content part
of the stream does not play with mplayer.. I have put a couple of
snippets (<200k) here for bug fixing purposes:

http://www.jmstone.dsl.pipex.com/ads.nsv

(Continue reading)

Reimar Döffinger | 1 Feb 11:44 2006
Picon
Picon

Re: roughly .25 second delay in playback of avi files

Hi,
On Tue, Jan 31, 2006 at 10:05:28PM -0500, Ed Sweetman wrote:
> The problem is, playback of media either encoded by mencoder or 
> transcode or virtualdub is played back at about a quarter of a second 
> off, almost always the audio precedes the video.  I played with 

Even though it is unlikely (an I start looking like bashing ALSA is my
favourite - well, maybe it is :-P), try with -ao oss, too.

Greetings,
Reimar Döffinger
RC | 1 Feb 12:08 2006
Picon

Re: nsv problems

On Wed, 1 Feb 2006 08:45:08 +0000
Lunadog <lunadog <at> dsl.pipex.com> wrote:

> Shoutcast nsv video streams seem to be well handled on the whole,
> however a few streams do not seem to work properly. They seem to be
> ones that have two nsv files (i.e. one with adverts and the other with
> main content). Mplayer plays the first file but when the stream
> switches to the second file, it locks up.

Yes, I reported similar results several months ago.  What you apparently
haven't discovered is, most files the NSV demuxer can't handle, work
with the lavf demuxer (-demuxer 35).

It's an annoyance to operate this way, but it works.
Steven Adeff | 1 Feb 14:21 2006
Picon

midentify ID_LENGTH wrong on mpegs, another option?

I've been trying to use ID_LENGTH to do a 2-pass encode using a
"length*desired average bitrate" formula, but I'm finding that it is hasn't
been correct on any of the 13 files I've tried it on. I assume its due to a
changing fps in the file (from between 23.97 to 29.97) screwing with the
calculation, but whatever...

Does anyone know of another command line applications that will accurately
give me the length of an mpeg? I don't mind it scanning/analyzing the file
and taking some time to do it as long as I get an accurate value that I can
grep/sed in my script.

Thanks!
--
Steve
Dirk Meyer | 1 Feb 14:31 2006

Re: midentify ID_LENGTH wrong on mpegs, another option?

Steven Adeff wrote:
> Does anyone know of another command line applications that will accurately
> give me the length of an mpeg? I don't mind it scanning/analyzing the file
> and taking some time to do it as long as I get an accurate value that I can
> grep/sed in my script.

mmpython (http://sourceforge.net/projects/mmpython/) or the successor
kaa.metadata (http://www.freevo.org/kaa).

Dischi

--

-- 
panic("kmem_cache_init(): Offsets are wrong - I've been messed with!");
	2.2.16 /usr/src/linux/mm/slab.c
_______________________________________________
MPlayer-users mailing list
MPlayer-users <at> mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-users
Giacomo Comes | 1 Feb 14:39 2006

Re: midentify ID_LENGTH wrong on mpegs, another option?

On Wed, Feb 01, 2006 at 08:21:58AM -0500, Steven Adeff wrote:
> I've been trying to use ID_LENGTH to do a 2-pass encode using a
> "length*desired average bitrate" formula, but I'm finding that it is hasn't
> been correct on any of the 13 files I've tried it on. I assume its due to a
> changing fps in the file (from between 23.97 to 29.97) screwing with the
> calculation, but whatever...
> 
> Does anyone know of another command line applications that will accurately
> give me the length of an mpeg? I don't mind it scanning/analyzing the file
> and taking some time to do it as long as I get an accurate value that I can
> grep/sed in my script.

mencoder source.mpg -ovc copy -nosound -o /dev/null -quiet 2>&1 | awk '/^Video stream:/{print $10+$10/$12}'

Giacomo
Tony Houghton | 1 Feb 15:17 2006
Picon

Re: roughly .25 second delay in playback of avi files

In <43E02578.1090606 <at> comcast.net>, Ed Sweetman wrote:

> I dont know what type of data could be useful, and the lack of anyone 
> else reporting the problem is not promising.   I can provide any info 
> required, but my experience playing with mplayer internals is lacking. 

I've been having similar problems with 3 machines, but the delay is less
consistent than what you're seeing. I've got a P3 with cheap CMedia
sound card, Duron 1800 with VIA onboard audio, AMD64 with nForce onboard
audio. The first two are outputting to TVs with -vo dfbmga... -vsync so
I guess that makes keeping in sync a little more difficult for MPlayer.

Using -ao oss fixes it for me in most cases, but sometimes a glitch in
the stream can throw the sync out until I manually readjust it. I don't
think that was happening with -ao alsa. I should be replacing the CMedia
sound card with a Santa Cruz shortly.

--

-- 
TH * http://www.realh.co.uk

Gmane