H.264 video lagging with MPlayer
 

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?

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

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

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%.

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.

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".

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

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

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

It is '-cache'.

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:
In this case I killed the playback after about 3 seconds.

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?

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.

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.

x86-64 kernel. Everything built from source.

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

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.

If it helps anyone, I have uploaded a 10 second dump (19 MB) of the stream I'm trying to watch.

Have you ever tried hardware video acceleration version of mplayer (vdpau/vaapi)? It must be less CPU usage.

MT.

Hardware-accelerated playback doesn't appear to work on x86-64. -vo xv, gl, gl2 all give similar results.

Further observations:
* CPU utilization with mplayer is about 75-80% with 32-bit build and 70-73% with 64-bit build (video still runs slow and desyncs)
* -vo null does not have any effect on CPU usage or desync
* -nosound or -ao null has no effect, video still runs slightly faster than half speed, no change in CPU usage

I am running ArchLinux (x86_64) and mplayer-vaapi work just fine. All I need are libav, vdpau-video driver and mplayer-vaapi.

Have a look at:
Video Acceleration (VA) API

MT.

When I try to play that dump it says:

lots of times with mplayer, which then hangs.

However, it plays fine with 'ffplay', try that.

I think that this message might be correct, the input may be corrupt. It could be a driver problem with the capture card or something.

I have already tried ffplay, as mentioned earlier in the thread. It maintains sync but stutters due to high CPU consumption.

Did you enable vdpau in ffplay ? when compiling it ? that might help.

Makes no difference

I've tried to play your 'test.ts' sample on my ArchLinux (x86_64)
CPU usage is very low. This is output log:
Regards,
MT.

Alright, tried building mplayer-vaapi as mentioned earlier in the thread. Builds OK but I get this when I try to run it:

mac.tieu: What versions of mplayer, libva, vdpau_video and Nvidia driver are you using?

I am using nVidia driver version 195.36.15-2, latest snapshot of libva, vdpau_video, mplayer-vaapi.

You should check for valid path of nvidia_drv_video.so (your is /usr/lib64/va/drivers/nvidia_drv_video.so). There are a utility named 'vainfo' which use to check whether libva installed properly or not.
You should also pay attention at matching two defines of libva and vdpau-video. Mine is:
Good lucks,
MT.

Is your user in the video group?

What's your specs with regards to other baselines speeds?

$ glxinfo | grep -i "direct"

$ glxgears -info
(or -printfps depending on distro / version)

$ xvidtune -show

$ ffmpeg -i <video>

$ cat /proc/cpuinfo | grep -i "bogomip"
(while you're trying to play the video, frequency scaling ruins it if you're not maxed)

mac.tieu: I checked the defines you mentioned and they match. I'm using the same versions of everything as you except for the Nvidia driver: 195.36.24

vainfo does the same thing:

/usr/lib64/va/drivers/nvidia_drv_video.so exists and is a symlink to vdpau_drv_video.so in the same directory.

Shadow_7: User is in video group. All video and 3D apps run correctly and at reasonable speeds. MPEG-1/2/4 HD video plays without difficulty. CPU scaling is disabled in the kernel (I was using it at one point but found that it screwed up virtualbox).

vdp_device_create_x11 had been failed. It may be due to multiple nvidia library existed. I suggest you to search 'vdp_device_create_x11 error', there are several results related.

Hope that help,
MT.

After doing some research, it looks like my card (Geforce 7800 AGP) does not support VDPAU/VA API, so this was all a dead end.

If there are no other suggestions, I give up.

Have you checked the /usr/lib/codecs/ to see if you have the latest versions of things?

Some of the players like VLC enable filters by default. Disabling them might boost performance to a tolerable level. ffplay is good in running multi-threaded that which can be run multi-threaded. mpeg2video is multi-threaded. msmpeg4v2 is not. Most things h.264 are becoming multi-threaded. Make sure you enable threading (pthreads?) where appropriate. Plus all that other stuff. Your card on that system should be more than capable IMO. I got an aftermarket card, just to get HDMI output. If you're in the market for a new card, you might check out some of that Cuda stuff.

Oh, so that's why it doesn't work. I didn't know that, sorry.