H.264 video lagging with MPlayer

Electrode · 05-16-2010, 01:46 AM

As mentioned in an earlier thread, I've been playing around with a DVB-S card for about a week. I've worked out most of the initial problems I ran into, but now another one has cropped up.

Some broadcasts use H.264 video, rather than the more common MPEG-2. MPlayer plays it, but the audio and video go badly out of sync. It looks like the video is only running at half speed. I don't think this is due to a lack of CPU or video card power, because top shows only 76% utilization, and the desync still happens even if I disable video output (-vo null), or even if I transcode with MEncoder (the resulting file is desynched).

If it matters, the video I'm trying to watch is in 1080i resolution at 29.97 fps.

Any ideas?

thecarpy · 05-16-2010, 07:38 AM

What CPU, mem and graphics card is in your system?
Do you have the open source or proprietary graphics drivers?

Electrode · 05-16-2010, 01:42 PM

CPU: 2x dual-core AMD Opteron 290 (2.8 GHz)
RAM: 5.12 GB PC2100
GFX: Nvidia GeForce 7800GS AGP w/ binary driver 195.36.15

thecarpy · 05-16-2010, 02:40 PM

Those specs should be enough, this is weird. Have you tried playing around with the nvidia settings (e.g. Anti-aliasing and stuff like that)? I would not know of anything else you could possibly try, sorry. One moment, maybe you need a realtime kernel, I need one of those because I do audio recording, with ardour. Maybe that could help? The latency on stock linux kernels is too high, maybe that is a possible solution. Then again, I have a core2quad 2.3Ghz, 6Gb Ram, Ge9800GT, and my work linux has an ordinary debian kernel, I sometimes don't bother rebooting into my "home" linux and watch tv over ADSL. I have HD content I watch with vlc, have not seen this happen on my system, it should technically be the same thing, hm. When I watch HD content fullscreen, my CPU use is at ~35%.

Electrode · 05-16-2010, 02:55 PM

Haven't done much of anything with the video driver config other than setting up my dual-head display, but as I mentioned in the original post, I don't think the video card or driver has anything to do with this, since I can play HD MPEG-2 video just fine, and this problem occurs even when I disable video output.

I'm using a realtime kernel here as well.

Electrode · 05-16-2010, 07:15 PM

I just tried VLC and that actually seems to be even worse than mplayer. CPU usage goes up to about 104% according to top and the video plays at about 2 FPS. During one test it actually crashed X, with dmesg showing several "machine checks".

H_TeXMeX_H · 05-17-2010, 04:46 AM

Maybe try to increase the buffer size for mplayer, if the buffer is too small it could cause lagging and a/v desync:

Code:

mplayer -cache 4096

Electrode · 05-17-2010, 09:10 AM

There doesn't appear to be a -bufsize option, did you mean -cache?

H_TeXMeX_H · 05-17-2010, 09:19 AM

Oh, yeah, oops, that must be deprecated, yes in the manual it says:

Code:

-cache <kBytes>
    This option specifies how much memory (in kBytes) to use when precaching a file or URL. Especially useful on slow media.

It is '-cache'.

Electrode · 05-17-2010, 03:10 PM

I've been using -cache 8192 all along (it's in my ~/.mplayer/config), it makes no difference in this case.

If it's of any significance, I see a lot of this when I try to play the video:

Code:

electrode@belphegor:~$ mplayer /dev/dvb/adapter1/dvr0
MPlayer SVN-r30554-4.4.2 (C) 2000-2010 MPlayer Team

Playing /dev/dvb/adapter1/dvr0.
Cache fill:  19.43% (1630208 bytes)   
TS file format detected.
VIDEO H264(pid=517) AUDIO MPA(pid=751) NO SUBS (yet)!  PROGRAM N. 9
FPS seems to be: 29.970030
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
[AO SDL] Samplerate: 48000Hz Channels: Stereo Format s16le
AO: [sdl] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
[h264 @ 0xa5b9e0]number of reference frames exceeds max (probably corrupt input), discarding one
(previous message repeated hundreds of times)
[h264 @ 0xa5b9e0]mmco: unref short failure
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1920x1080 => 1920x1080 Planar YV12 
[h264 @ 0xa5b9e0]mmco: unref short failure   2/  2 ??% ??% ??,?% 0 0 
[h264 @ 0xa5b9e0]mmco: unref short failure   8/  8 ??% ??% ??,?% 0 0 
A:18127.0 V:18125.8 A-V:  1.193 ct:  0.168 126/126 56%  5%  1.1% 0 0 
Exiting... (Quit)

In this case I killed the playback after about 3 seconds.

Shadow_7 · 05-17-2010, 05:26 PM

You might try:

-nocache

-lavdopts skiploopfilter=all
(-skiploopfilter 0 in vlc)

mpeg2video is a lot less CPU needy. Not that that cpu should be struggling that much. You might try:

ffplay -threads 0

Was that 5.12 GB of ram or 512MB aka 0.512GB?

Electrode · 05-17-2010, 06:01 PM

The options you suggested have no impact whatsoever. ffplay maintains sync, but stutters badly and shows ~130% CPU utilization.

System has 5120 MB of RAM.

Shadow_7 · 05-17-2010, 06:24 PM

Are you running a kernel optimized for an i386? or 686 or better?

Distro version of mplayer? Or compiled from source?

Does -noaudio for mplayer make a noticeable difference (cpu usage)? If it's AAC audio, some implementations of it are in a lot of flux and some are not optimized well. To the point of almost taking longer to decode the audio than it does to decode the video.

Electrode · 05-17-2010, 06:30 PM

x86-64 kernel. Everything built from source.

-noaudio makes no difference. Audio is in MP3 format.

Electrode · 05-17-2010, 07:08 PM

Some observations:

* the latest ffmpeg gives garbled video output. SVN r20373 works better.
* I tried building a 32-bit ffplay binary in a chroot, and that uses much less CPU (102% vs. 130%).
* Building a 32-bit mplayer seems to make no difference vs. 64-bit.