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

Newegg Daily Deals

Reply
 
Thread Tools
Old 09-17-09, 10:07 AM   #1189
ir123
*BANNED*
 
Join Date: Jun 2008
Posts: 92
Default Re: mplayer vdpau

Quote:
Originally Posted by peter22 View Post
Hallo.

Here is a simple mpeg2 ts file, dumped from my dvb-s card:
http://home.arcor.de/webghost/stuff/vids/00001.ts

Playing like that:
Code:
mplayer -vo vdpau:deint=4 -vc ffmpeg12vdpau,ffh264vdpau,ffvc1vdpau,ffwmv3vdpau, -demuxer lavf -cache 8192 00001.ts
I can see a lot of micro stuttering.

When I play like that:
Code:
mplayer -vo vdpau:deint=4 -vc ffmpeg12vdpau,ffh264vdpau,ffvc1vdpau,ffwmv3vdpau, -demuxer lavf -cache 8192 -speed 2 00001.ts
I still see a lot of micro stuttering in window mode, but when pressing "f" (fullscreen)
the movie is very smooth/ no stutter.

What is the problem her? Why does this ts-file stutter without "-speed 2" in windowed and fullscreen mode?

My Setup:
Nvidia 190.32
MPlayer SVN-r29675-4.3.4 (C) 2000-2009 MPlayer Team
nVidia Corporation G86 [GeForce 8500 GT]
The monitor refresh and video fps difference. The monitor would have to run 50hz or 100hz (maybe 75hz).
ir123 is offline   Reply With Quote
Old 09-25-09, 09:37 AM   #1190
piotro
Registered User
 
Join Date: May 2007
Posts: 72
Default Blu-ray audio desync in 28900+ mplayer SVNs

Hi *

Wrt post #1175 in this thread, I finally found direction where issue starts:

Issue is caused by refresh rate change. Namely:
-If TV refresh-rate is 50Hz - my BD rip having 23.976 plays OK (but of course with judder)
-When I automatically switch via XrandR refresh rate to 24Hz - no judder, but slow AV desync start to be present.

It looks like after approx mplayer SVN28900-29000 and nv newer than 180.60, we start to have different behavior regarding A/V synchronization.

Well - indeed it is interesting topic.

My logic says me that audio & video channel should be slaves to fps/bitrate of content - if we want to avoid judder/sleeps in video/audio.
But my issue - where I have refresh v.close to fps, but not equal - shows that mplayer video speed fps follows TV refresh rate. Pls notice: 50Hz refresh gives perfect A/V sync.

Now, if we assume that A/V sync in mplayer is implementation where - for avoiding judder - video playback fps is following display refresh rate, but audio is going with content fps speed - we should have delay approx 1s for 16 minutes (23.976/24.000). This is delay which I approx observe, so probably above theory works.

Now question is: how can I change fps synchronization direction: from TV->mplayer to mplayer->TV ?

Of course another solution is to free run mplayer & TV with exact the same fps. I already tried try force TV refresh rate to 23.976 via X.org custom modes - but unfortunately such modes are not available via XrandR (they are reported in pool of XrandR available modes in Xorg.log, but not in XrandR tool).
I'm using perl script for auto refresh change - so use XrandR as toll for TV refresh rate change is essential for me.


Thx in advance for any help !
piotro is offline   Reply With Quote
Old 09-25-09, 10:16 AM   #1191
cehoyos
FFmpeg developer
 
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
Default Re: Blu-ray audio desync in 28900+ mplayer SVNs

Quote:
Originally Posted by piotro View Post
Wrt post #1175 in this thread, I finally found direction where issue starts:

Issue is caused by refresh rate change. Namely:
-If TV refresh-rate is 50Hz - my BD rip having 23.976 plays OK (but of course with judder)
I will try to explain why I cannot reproduce those problems (and you are not the first one reporting them):
My screen has a refresh rate of 85 Hz, so some frames will always (for real-world samples) be shown more than once, but I do not see this as a disadvantage. So I do not understand why it is a problem for you to see >90% of all frames exactly twice and the rest at least once.
But as I said, you are not the only one who does not like this behaviour.
Quote:
-When I automatically switch via XrandR refresh rate to 24Hz - no judder, but slow AV desync start to be present.
How do you notice? Are frames dropped? Does -framedrop help? -fps 24?
Did you try -demuxer lavf? -demuxer lavf -nocorrect-pts?
Is complete, uncut output of mplayer (preferably with sane configure line) available?
Quote:
It looks like after approx mplayer SVN28900-29000 and nv newer than 180.60, we start to have different behavior regarding A/V synchronization.
A range of 100 revisions is not very helpful if you claim a regression (and since this is probably libavcodec-related, you will have to also provide its version - or a date).

Carl Eugen

PS: Are you sure this is VDPAU related?
cehoyos is offline   Reply With Quote
Old 09-25-09, 12:01 PM   #1192
_panic_
Registered User
 
Join Date: Dec 2008
Posts: 2
Default Re: mplayer vdpau

Cannot compile mplayer-vdpau-4728141
Code:
Checking for DPMS ... yes (using Xdpms 4)
Checking for Xv ... yes
Checking for XvMC ... no
Checking for VDPAU ... ./configure: line 4289: syntax error near unexpected token `fi'
./configure: line 4289: `      fi'
_panic_ is offline   Reply With Quote
Old 09-25-09, 06:05 PM   #1193
uau
Registered User
 
Join Date: Sep 2009
Posts: 45
Default Re: Blu-ray audio desync in 28900+ mplayer SVNs

Quote:
Originally Posted by cehoyos View Post
How do you notice? Are frames dropped? Does -framedrop help? -fps 24?
Did you try -demuxer lavf? -demuxer lavf -nocorrect-pts?
Is complete, uncut output of mplayer (preferably with sane configure line) available?
No need to bother trying those, they won't help. It doesn't depend on MPlayer configuration either. The problem is that VDPAU insists on showing every frame for at least one monitor refresh cycle, even if timing would require them to be shown faster (correct playback would mean that some frames never actually appear on the monitor). This means that the video will fall behind if AV sync would require it to be played back faster than monitor refresh rate.

I'll have code to work around this problem by manually dropping frames ready soon, though it'd still be nice if the VDPAU implementation made it easier. Correctly deciding which frames to drop requires knowledge about the timing of future frames, and since VDPAU doesn't allow dropping already queued frames you need to buffer them to have future timing available before sending one to the VDPAU output queue. Calculating the timing also requires you to know the current monitor refresh rate. If the VDPAU implementation can't handle the framedropping correctly itself it could at least directly export the current refresh rate of the display it's syncing to to make it easier to calculate things on the client side.
Quote:
A range of 100 revisions is not very helpful if you claim a regression (and since this is probably libavcodec-related, you will have to also provide its version - or a date).
I doubt there has been any change in this behavior. And it is not libavcodec-related in any way.

Quote:
PS: Are you sure this is VDPAU related?
Such video update rate limitations do depend on the video output method used, though VDPAU is not the only one which suffers from this.
uau is offline   Reply With Quote
Old 09-25-09, 10:01 PM   #1194
cehoyos
FFmpeg developer
 
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
Default Re: Blu-ray audio desync in 28900+ mplayer SVNs

Quote:
Originally Posted by cehoyos View Post
How do you notice? Are frames dropped? Does -framedrop help? -fps 24?
Did you try -demuxer lavf? -demuxer lavf -nocorrect-pts?
Does
Code:
export VDPAU_NVIDIA_NO_OVERLAY=1
make any difference?

Carl Eugen
cehoyos is offline   Reply With Quote
Old 09-26-09, 06:39 AM   #1195
danoscar
Registered User
 
Join Date: Jul 2009
Posts: 11
Default Re: Blu-ray audio desync in 28900+ mplayer SVNs

The problem is how mplayer handles frame display in VDPAU (and some other video outputs). It results in mplayer getting out of A-V sync when refresh rate is nearly the same as fps of movie. To fix this I have patched mplayer to drop frames in VDPAU layer when they cannot be displayed in time to avoid A-V gets out of sync (if frames are dropped it will be displayed on status line)

Also, to avoid having to drop frames, I have added the option -displaysync which adjusts speed of movie to match refresh rate (if within 5% of refresh rate or double refresh rate).
So a 23.976Hz or 25Hz movie will be adjusted to match a 23.976 refresh rate (or a 50hz refresh rate). It will save in the .mplayer directory data that is reused next time to calculate better speed adjustments. Some movies are more unstable and produce less good data, full screen normally gets better results and using VDPAU overlay. When using this option, do not change refresh rate after movie has started as my patches only reads refresh rate when movie starts.

I have used these patches for many months and they works well for me.

You are welcome to try my patches, which I have attached.

To answer Carl Eugen, one reason that seeing 90% of frames twice and the rest once gives bad display is that some TVs (like Sony's) include motion interpolation which will get disrupted by uneven display of frames.
Attached Files
File Type: gz mplayer-vsync-vdpau-09-11.txt.gz (10.4 KB, 152 views)
danoscar is offline   Reply With Quote
Old 09-26-09, 07:12 AM   #1196
teox99
Registered User
 
Join Date: Jan 2009
Location: Italy - Rome
Posts: 56
Default Re: mplayer vdpau

@danoscar

i compiled mplayer-svn using your patch,
how can i know if it's working and correctly installed?

i decided to use it in front of your note about Sony's TV...
when i play 1080p watching the slow movie scenes of a film you can notice that is not 100% fluids.

i'm using VDPAU and -cache ...

it seems your patch didn't fix myprob.
can u help me?

this can help?
Display vsync rate to far from video rate, no syncing of speed 0 0 99%
A: 58.3 V: 58.3 A-V: -0.000 ct: -0.001 0/ 0 1% 1% 0.2% 0 0 48%

vync.log
16 0 0 0 0 0 0 1 0.000000 inf 16656.000000 0 Planet Earth - 06 - Mondi di ghiaccio [1080p, x264, ac3 ita-eng, subs] by GuglielmoDaBaskerville.mkv
teox99 is offline   Reply With Quote

Old 09-27-09, 02:24 AM   #1197
danoscar
Registered User
 
Join Date: Jul 2009
Posts: 11
Default Re: mplayer vdpau

Quote:
Originally Posted by teox99 View Post
@danoscar

i decided to use it in front of your note about Sony's TV...
when i play 1080p watching the slow movie scenes of a film you can notice that is not 100% fluids.

this can help?
Display vsync rate to far from video rate, no syncing of speed 0 0 99%
A: 58.3 V: 58.3 A-V: -0.000 ct: -0.001 0/ 0 1% 1% 0.2% 0 0 48%

vync.log
16 0 0 0 0 0 0 1 0.000000 inf 16656.000000 0 Planet Earth - 06 - Mondi di ghiaccio [1080p, x264, ac3 ita-eng, subs] by GuglielmoDaBaskerville.mkv
The 16656 in the log is time between two vsyncs. It shows you are using a refresh rate
of 60hz. Your Planet Earth movie is probably at 25hz or 23.976 hz which is not close
enough to 30hz or 60hz to sync speed. That is why it says no syncing of speed.
Change the refresh rate of your TV to 50hz or 24hz, and then play the movie again.

To get a 25hz movie to work best with 60hz you would have to speed the movie up by 1.2.
But that much increase in speed would be easily noticeable by you and therefore not done.
danoscar is offline   Reply With Quote
Old 09-28-09, 03:04 PM   #1198
piotro
Registered User
 
Join Date: May 2007
Posts: 72
Default Re: mplayer vdpau

@danoscar

Thx for trying help !
Unfortunatelly patch works only for analog audio.
For SPDIF based systems I' receiving error like below.

IMHO Your patch isn't fully resolving issue - it is rather workaround, as wrong synchronization direction is still present (TV->mplayer playback).

I believe only proper solution is solution proposed by "uau". Also for me all this looks like constrain of vdpau design.
Having possibility to inform player code about display rate is essential for keeping sync. If judder less playback is expected - only sync display to source is solution.

Honestly speaking, I'm little surprised. Design where we are not able to sync display to source is IMHO issue - as long as we want to use VDPAU as support for serious player with no judder, no tearing playback.

Unfortunately - due bug in all nv VDPAU driver versions - approach with free running player and display, both with the same fps, isn't working for non-integer refresh rates (at lest in my system)

br

br

Code:
----------------------------
Increasing filtered audio buffer size from 0 to 65536
Syncing speed to double display vsync rate 1.0427083050% ??,?% 0 0                                                                                     
Building audio filter chain for 50050Hz/2ch/ac3 -> 48000Hz/2ch/ac3...
[dummy] Was reinitialized: 50050Hz/2ch/ac3
[libaf] Adding filter lavcresample 
[libaf] Adding filter format 
[format] Sample format big-endian AC3 not yet supported 
*** [vo] Direct Rendering (slices) mp_image_t, 1920x1088x0bpp RGB packed, 0 bytes
Unicode font: 661 glyphs.
Unicode font: 661 glyphs.


MPlayer interrupted by signal 11 in module: decode_audio
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.
minimyth@FE-Salon:~ $
piotro is offline   Reply With Quote
Old 09-28-09, 03:39 PM   #1199
Stephen Warren
Moderator
 
Stephen Warren's Avatar
 
Join Date: Aug 2005
Posts: 1,327
Default Re: mplayer vdpau

MPlayer (and unfortunately all apps so far I believe) isn't using the VDPAU presentation queue as designed. It's intended to work like this:

a) Player decodes N frames ahead of time, so that some number of frames can be queued in the presentation queue at all times. In other words, adequate buffering is required at all stages.

b) Player should provide a timestamp associated with each frame, indicating when to display it. This is what allows players to control which VSYNC each frame is displayed at, the duration frames are displayed, etc. (although VDPAU will always display each frame for at least one VSYNC by design; apps that don't want a frame to be displayed should not send it into the presentation queue)

c) Player should look at the "first_presentation_time" result from either VdpPresentationQueueBlockUntilSurfaceIdle or VdpPresentationQueueQuerySurfaceStatus to measure any desync, and skip/repeat frames based on that.

In fact, MPlayer (and likewise all apps) is simply queueing a single frame into the presentation queue, with no timestamp (i.e. display "now"), and not using the "first_presentation_time" data at all. It's no surprise that this isn't entirely optimal.

NVIDIA takes at least some of the blame for this; our MPlayer patches never implemented the correct way to use the presentation queue. However, it's equally true that it appears very difficult to get ffmpeg to work in the model VDPAU wants; I don't think the surface ownership tracking is there to support this amongst other things. I suppose this isn't much of a surprise, since VDPAU's presentation queue is a somewhat ground-breaking new concept.

Comments on the ffmpeg mailing list indicate that even if we had modified ffmpeg to support this (the changes may have been significant), the patches still would not have been accepted, since some ffmpeg maintainers don't see the presentation queue concepts as being necessary.
Stephen Warren is offline   Reply With Quote
Old 09-28-09, 05:51 PM   #1200
uau
Registered User
 
Join Date: Sep 2009
Posts: 45
Default Re: mplayer vdpau

Quote:
Originally Posted by Stephen Warren View Post
MPlayer (and unfortunately all apps so far I believe) isn't using the VDPAU presentation queue as designed. It's intended to work like this:
I'm aware that the intended use is somewhat different; however as far as I can tell queuing frames ahead the way VDPAU designers expected it to be used would not help much with this problem.
Quote:
(although VDPAU will always display each frame for at least one VSYNC by design; apps that don't want a frame to be displayed should not send it into the presentation queue)
This is the basic problem. What's the rationale for this design? Is there a hardware limitation requiring it? I can't see how this would be desirable as the default behavior if you have a choice. For the application to make the dropping decisions needed because of VSYNC rate requires it to know about VSYNC timing, information which is not readily available and would not be needed otherwise.
Quote:
c) Player should look at the "first_presentation_time" result from either VdpPresentationQueueBlockUntilSurfaceIdle or VdpPresentationQueueQuerySurfaceStatus to measure any desync, and skip/repeat frames based on that.
Why would you ever need to explicitly repeat frames? Anyway skipping is the main issue here, and detecting afterwards that frames already were late and then dropping some (without explicit awareness of VSYNC rate) is not a good solution at least if the display device is low FPS. You don't want to constantly have the video some multiple of 1/24 second late.


Quote:
In fact, MPlayer (and likewise all apps) is simply queueing a single frame into the presentation queue, with no timestamp (i.e. display "now"), and not using the "first_presentation_time" data at all. It's no surprise that this isn't entirely optimal.
I don't see how timestamps alone would help with the issues in this thread. You could measure the delay in flipping regardless of whether the frames were queued with a timestamp or not (just use the VDPAU time at the moment of queuing as the time to compare against); but noticing that they were delayed is not enough alone to implement a good _solution_ to the problem.

Quote:
NVIDIA takes at least some of the blame for this; our MPlayer patches never implemented the correct way to use the presentation queue. However, it's equally true that it appears very difficult to get ffmpeg to work in the model VDPAU wants; I don't think the surface ownership tracking is there to support this amongst other things. I suppose this isn't much of a surprise, since VDPAU's presentation queue is a somewhat ground-breaking new concept.

Comments on the ffmpeg mailing list indicate that even if we had modified ffmpeg to support this (the changes may have been significant), the patches still would not have been accepted, since some ffmpeg maintainers don't see the presentation queue concepts as being necessary.
I think it would be possible to implement queuing frames ahead, and no FFmpeg changes would be needed. Video surfaces are allocated through the get_buffer() function in MPlayer's vd_ffmpeg.c, and MPlayer can control their reuse through that. I may implement that later. But, again, I think the queuing has little to do with the framerate problem here.

If NVIDIA is unable or unwilling to change the queue behavior to automatically drop frames which should be dropped because of timing then I hope at least a way to directly get the current VSYNC rate of the synced-to device is added to the VDPAU API. That would allow properly calculating on the application side which frames should be dropped. The application can already try getting that value through other APIs or measure it from the reported display times, but that is somewhat tedious especially when the value can plausibly change (if the user starts watching videos then that's a time when he's particularly likely to switch display modes).
uau 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 12:59 PM.


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