[MPlayer-dev-eng] r32056 Causes Loss of A/V Sync with VOB files

[Steaphan Greene]

On 06/17/2011 02:28 AM, Dan Oscarsson wrote:
> tor 2011-06-16 klockan 19:02 -0400 skrev Steaphan Greene:
>> On 06/16/2011 03:24 PM, Steaphan Greene wrote:
>>> I hope that helps someone realize what's going on.  If not, I will
>>> continue to try to track it down in the code myself.
>>
>> I have found the culprit, but I'm not sure what the correct solution
>> really should be:
>>
>> Line 2514 of mplayer.c (r33634) has:
>>
>> 	sh_video->pts = pts;
>>
>> ....which adjusts the video time.  When the video is the component that
>> is lagging behind, this seems to just solidify the error, making it get
>> worse and worse until it finally resyncs (with a seek or moving to the
>> next file).  Disabling just this one line fixes my problem.
>>
>> Whatever the root issue here, it seems that every 12 frames or so, my
>> video is showing recalculated time-stamps that are a bit off.  If the
>> above line is used, the times are then forever off every 12 frames,
>> leading to serious A/V sync problems.  If this line is not used, then
>> these recalculated-time frames remain close, and sync is maintained.
>>
>> Perhaps this code was designed only for video that went too fast for the
>> audio, and not the other way around (and thus, ptsdiff should not be
>> calculated with fabs)?
>>
>> If anyone has any ideas as to what I should try/test next to correctly
>> solve this problem, please let me know.  I am out of my depth to try to
>> correctly fix this myself, as I don't understand what it was the
>> original patch was added to fix in the first place.
>
> I think the above code was added to fix some videos with defective time
> stamps.
>
> You have not said what refresh rate you are running your display at?
> If you use vo=vdpau:deint=4 I think that doubles the number of frames at
> vo layer and as standard code do not drop frames at vo layer you might
> get out of sync. It might work better if you do the deinterlacing at
> software level. I think the current code then can do frame drops on the
> deinterlaced frame rate. I had big problems when playing moves to my lcd
> tv running at 24 hz because frames were not dropped, so I have patched
> mplayer to take into account the vsyncs and do frame drops were needed -
> and then it works fine.

I don't think that's it, as it is able to properly drop frames when I 
comment out just this one line.  Even with speed=1.75 or more, it 
maintains sync without this one line (even with vo=vdpau:deint=4).

Also, it loses sync most severely when the video becomes most active 
(lots of motion or full-screen activity like snow or explosions).

Also, mplayer falsely believes it IS in sync when this line is active, 
even when it severely loses sync.

Also, I was able to reproduce this same problem with other vo settings, 
including vo=vdpau without interlacing and vo=xv, and using different 
-speed settings.

For the record, though, my display is running at 60Hz, and the sources I 
am using are all ~30Hz.

-- 
Steaphan Greene <sgreene at cs.binghamton.edu>
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt