Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 04-03-10, 04:02 PM   #1237
mklein49
Registered User
 
Join Date: Oct 2006
Posts: 6
Question Re: mplayer vdpau

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?

Code:
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
mklein49 is offline   Reply With Quote
Old 04-04-10, 02:37 PM   #1238
uau
Registered User
 
Join Date: Sep 2009
Posts: 45
Default Re: mplayer vdpau

Quote:
Originally Posted by mklein49 View Post
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.
uau is offline   Reply With Quote
Old 04-04-10, 04:54 PM   #1239
cehoyos
FFmpeg developer
 
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
Default Re: mplayer vdpau

Quote:
Originally Posted by mklein49 View Post
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 is offline   Reply With Quote
Old 04-04-10, 04:58 PM   #1240
cehoyos
FFmpeg developer
 
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
Default Re: mplayer vdpau

Quote:
Originally Posted by mklein49 View Post
So, using "-lavdopts skipframe=nonref", does that enable dropping frames?
Yes, please see MPlayer manual (and this thread) for details.

Carl Eugen
cehoyos is offline   Reply With Quote
Old 04-05-10, 09:24 PM   #1241
mklein49
Registered User
 
Join Date: Oct 2006
Posts: 6
Default Re: mplayer vdpau

Quote:
Originally Posted by cehoyos View Post
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.
mklein49 is offline   Reply With Quote
Old 04-08-10, 09:29 AM   #1242
neurox
Registered User
 
Join Date: Mar 2010
Posts: 2
Default Re: mplayer vdpau

Quote:
Originally Posted by Stephen Warren View Post
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 :-(
neurox is offline   Reply With Quote
Old 09-16-10, 07:19 AM   #1243
cehoyos
FFmpeg developer
 
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
Default Re: mplayer vdpau

Quote:
Originally Posted by resoli View Post
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
cehoyos is offline   Reply With Quote
Old 09-16-10, 11:03 AM   #1244
primerib
Registered User
 
Join Date: Dec 2008
Posts: 128
Default Re: mplayer vdpau

Quote:
Originally Posted by cehoyos View Post
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.
primerib is offline   Reply With Quote

Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
xorg locks-up with newest nvidia drivers w/ vdpau. theroot NVIDIA Linux 1 06-24-12 11:04 AM
NVIDIA VDPAU Reference Benchmarks News Archived News Items 0 06-11-12 05:30 AM
VDPAU and KDE 4.8 compositing = slow Pie-rate NVIDIA Linux 30 05-23-12 07:07 AM
VDPAU testing tool crisalide NVIDIA Linux 392 04-29-12 06:01 PM
mplayer & xmms problems! replys2me NVIDIA Linux 5 09-06-02 02:34 PM

All times are GMT -5. The time now is 03:28 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.