[MPlayer-dev-eng] [PATCH] further dvr-ms playback improvements

[Nico Sabbi]

Uoti Urpala wrote:

>On Fri, 2006-08-25 at 22:32 +0200, Nico Sabbi wrote:
>  
>
>>I mean that the duration reported is always 20 seconds, with or without 
>>-correct-pts
>>    
>>
>
>So do you think that is incorrect? Since playing it does now take 20
>seconds, if you believe it's accelerated overall then the duration has
>to be wrong too.
>  
>

the duration reported is correct, but obviously the file doesn't play 
correctly
(from a visual point of view)

>>in my patch I removed the assignment sh_video->pts=1000.0 from demux_asf.c
>>because I consider absolutely random and arbitrary,
>>    
>>
>
>You mean fps=1000, not pts. 
>

right

>Apparently several demuxers use that to
>indicate that the video is VFR and does not have a constant frame rate.
>It's interpreted by video.c; if fps is set to some other value then that
>is used as frame duration ignoring timestamps, fps=1000 means packet
>timestamps are used (the code depends on demuxer type, does affect
>DEMUXER_TYPE_ASF). 
>

the interpolation used is hopelessly broken (because of b-frames)

>With -correct-pts that video.c code is not used at
>all and the fps value is mostly ignored, only packet timestamps are used
>always.
>
>  
>

as it should :)

>>but mplayer from svn doesn't even init when sh_video->pts == 0,
>>    
>>
>
>That means the value wasn't inited at all.
>  
>

here I meant that "mplayer from svn doesn't even init when sh_video->fps 
== 0"

>>thus I had to patch one of the decoders to assign the video framerate
>>    
>>
>
>Why? What was the point? Why did you want to remove the fps=1000
>assignment? Sure that is an ugly way to handle it but does it have
>anything to do with the problems with that file? 
>

not particularly with that file; the problem is that the fps 
interpolation in video.c is really broken

>Do you believe that the
>decoder has more accurate timestamp information which cannot be obtained
>in the demuxer 
>  
>
absolutely not.

It seems I can't explain myself very well today, so let me retry :)

1) The assignment sh->fps = 1000 is _arbitrary_ and completely fake, 
thus it should be avoided.
2) If we avoid that assignment sh->fps will be initialized with 0, 
leading mplayer to
refuse to play the file.
3) In order to play the file sh->fps will have to be initialized  to a 
sensible value;
since the demuxer doesn't know this value the only other component that can
possibily set it is the video decoder
4) from now on the _initial_  value of sh->fps is set and everything 
will proceed as usual,
so the value of sh->pts will depend on the demux_packets pushed to 
demuxer->video
by the demuxer (hence sh->pts will be correct irrispective of sh->fps)  
and playback
will (hopefully) be smooth