mplayer vdpau

[mklein49]

I just ran with the integrated 9300. The frame rate of 46 is very similar to what I experience in XBMC.

I noticed that the GT220 results appear to exceed 60 fps. But, I also see discussion that smooth playback is not possible with the card. Can anyone clear up what the status is with that particular card? Also, is that the best possible card to use?

Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
NVIDIA GPU GeForce 9300 / nForce 730i (C79) at PCI:3:0:0

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library  195.36.15  Thu Mar 11 23:42:13 PST 2010

SURFACE GET BITS: 551.908 M/s
SURFACE PUT BITS: 449.818 M/s

MPEG DECODING (1920x1080): 58 frames/s
MPEG DECODING (1280x720): 127 frames/s
H264 DECODING (1920x1080): 46 frames/s
H264 DECODING (1280x720): 85 frames/s
VC1 DECODING (1440x1080): 60 frames/s
Profile unsupported.

MIXER WEAVE (1920x1080): 215 frames/s
MIXER BOB (1920x1080): 307 fields/s
MIXER TEMPORAL (1920x1080): 84 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 56 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 116 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 30 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 24 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 34 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 89 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 53 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 53 fields/s

[uau]

Originally Posted by mklein49

I came on here today looking to see what I was doing wrong that I was unable to play back 1080p60 h264 encoded video. I just got a Panasonic HDC-TM700 which records h264 video at 1080p60 with a bit rate around 28mb/s. I was disappointed when the video did not play back smoothly using VDPAU. I would max out around 45 fps.

After scanning this thread, it looks like I don't have a problem but the hardware simply does not support what I was hoping to do. I tried decoding with software using a e8500 cpu and was unsucsesfull as well.

Try compiling a player from git://repo.or.cz/mplayer-build.git. Compared to MPlayer svn this has both superior VDPAU support and direct support for multithreaded decoding with FFmpeg-mt (see README). VDPAU performance is better than in svn (by how much depends on the exact setup), but if you only get 45 FPS with the svn driver then it probably won't improve so much as to reach 60. With a dual core chip like the e8500, threaded decoding with 2 threads should give a bit less than double performance compared to non-threaded.

[cehoyos]

Originally Posted by mklein49

I noticed that the GT220 results appear to exceed 60 fps.

No current PureVideo (= NVIDIA VDPAU) hardware allows hardware accelerated decoding and presentation of (some) H264 1080p60 media files keeping A/V sync without dropping frames, no matter if you use MPlayer svn or the git fork (disclaimer: I do not know about GT240 and GF100, no test reports in this forum so far).
With your CPU (E8500), software decoding and presentation of typical H264 1080p60 camera recorded source is possible while keeping A/V sync without dropping frames using MPlayer svn and vo vdpau (if the vertical refresh rate of your screen is higher than 60Hz).
The git fork allows you to keep A/V sync with vo vdpau if the frame rate of your video is identical with the native vertical refresh rate of your screen (MPlayer svn drops frames in this case).

If you really used a thread called "mplayer vdpau" to report XBMC performance issues, I can't help you;-)

Carl Eugen

[cehoyos]

Originally Posted by mklein49

So, using "-lavdopts skipframe=nonref", does that enable dropping frames?

Yes, please see MPlayer manual (and this thread) for details.

Carl Eugen

[mklein49]

Originally Posted by cehoyos

No current PureVideo (= NVIDIA VDPAU) hardware allows hardware accelerated decoding and presentation of (some) H264 1080p60 media files keeping A/V sync without dropping frames, no matter if you use MPlayer svn or the git fork (disclaimer: I do not know about GT240 and GF100, no test reports in this forum so far).
With your CPU (E8500), software decoding and presentation of typical H264 1080p60 camera recorded source is possible while keeping A/V sync without dropping frames using MPlayer svn and vo vdpau (if the vertical refresh rate of your screen is higher than 60Hz).
The git fork allows you to keep A/V sync with vo vdpau if the frame rate of your video is identical with the native vertical refresh rate of your screen (MPlayer svn drops frames in this case).

If you really used a thread called "mplayer vdpau" to report XBMC performance issues, I can't help you;-)

Carl Eugen

Sorry about that. The reason I mentioned it, was because the results I got with qvdaputest matched the performance within XBMC. So, I wanted to find out if there was a hardware solution for mplayer. I assumed if there was, the same would be true for XBMC.

[neurox]

Originally Posted by Stephen Warren

neurox, that MPlayer version is ~5 months old. Can you try a more recent version to see if it solves the crash?

The green flash is just the overlay's chroma key showing through once the overlay is disabled. It's nothing to worry about.

I've rebuilt mplayer SVN-r30980-4.4.3, and it appears the crash is gone - there's still a rather nasty green flash when the movie ends - something that's tolerable on my TV but pretty bad when our little Ion box is showing movies in a full cinema. Is there any way to disable the green overlay or perhaps change it to black? Nothing else is running in X besides the player :-(

[cehoyos]

Originally Posted by resoli

Oh, my be I have not understand well, but my mplayer problems (compiled from trunk) are related to interlaced content, so I'm incline to think to a deinterlacing issue.
Bye the way, the "slow motion" effect is there even without deint= parameter.

The - often reported - "slow motion" effect on PAFF H264 videos was finally truly fixed in MPlayer svn: It should work fine now with both the native ts demuxer (default, more reliable seeking) and the lavf demuxer (-demuxer lavf, works with broken H264 streams that lack PMT/PAT).
The old work-around, to use -demuxer lavf -nocorrect-pts does not work anymore, the two working options now are: -demuxer lavf -correct-pts and -demuxer mpegts -nocorrect-pts (note that correct-pts is default for demuxer lavf and nocorrect-pts default for the native demuxer, so there should be no need to explicitly mention correct-pts on the command line).

Carl Eugen

[primerib]

Originally Posted by cehoyos

The - often reported - "slow motion" effect on PAFF H264 videos was finally truly fixed in MPlayer svn: It should work fine now with both the native ts demuxer (default, more reliable seeking) and the lavf demuxer (-demuxer lavf, works with broken H264 streams that lack PMT/PAT).
The old work-around, to use -demuxer lavf -nocorrect-pts does not work anymore, the two working options now are: -demuxer lavf -correct-pts and -demuxer mpegts -nocorrect-pts (note that correct-pts is default for demuxer lavf and nocorrect-pts default for the native demuxer, so there should be no need to explicitly mention correct-pts on the command line).

Carl Eugen

Thanks for this update. I'm amazed it took so long to be properly fixed but the important thing is that it finally is. Now hopefully package maintainers will update as that's a significant change which affects a LOT of users.