[Ffmpeg-devel] [PATCH] get rid of AVFrac

[Baptiste Coudurier]

Hi

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Dec 16, 2006 at 01:29:48AM +0100, Baptiste Coudurier wrote:
>> Hi
>>
>> Michael Niedermayer a ?crit :
>>> Hi
>>>
>>> On Sat, Oct 14, 2006 at 07:01:59PM +0200, Reimar D?ffinger wrote:
>>>> Hello,
>>>> On Fri, Oct 13, 2006 at 09:33:18PM +0200, Michael Niedermayer wrote:
>>>> [...]
>>>>> this doesnt look correct ...
>>>> Hmm.. well, no idea what exactly the old code does and how.
>>>> Here is another try, it's the best I can do without further hints.
>>> [...]
>>>
>>> so what the code does is it simply fills in missing timestamps on
>>> the encoding side and it does so without rounding errors assuming
>>> constant framerate and a few other things allthough
>>> the usefullness of the whole is questionable (the user app should set
>>> the timestamps and not leave it to lav* to guess something)
>>>
>>> [...]
>>>
>>> IMHO drop "support" for missing dts on the encoder side completely it makes
>>> no sense at all, its like sending emails with no To: field
>>>
>> Here is an updated patch which drop support for missing pts or dts on 
>> the encoder side.
>>
>> However ffmpeg.c does not compile anymore, 
> 
> that is a problem, patch rejected :)

Hehe, yes, but is the patch the good approach (get rid of AVFrac and
drop support for missing dts or pts on the encoder side), and therefore
ffmpeg.c must be updated, or should we keep st->pts ?

If the latter, I would that say AVFrac is not that useless since
ffmpeg.c uses it, and it is exact.

>> and Im not sure to know 
>> exactly what ffmpeg.c does, could st->pts be updated to use rescaled 
>> st->cur_dts ? Seems that cur_dts would only be 1 frame less that 
>> st->pts.val in that case, maybe Im wrong.
> 
> yes cur_dts and st->pts represent the same thing IIRC ...
> the difference is that st->pts is exact and cur_dts is not, using the later
> will cause terrible AV-desync under the correct circumstances, think about
> a container timebase of 1/1000 and 30fps video, the duration of one frame
> is 33.333... in the container timebase, if you repeatly add 33 you will be
> off by 0.6 seconds per minute ...
> 

I see. Now if st->pts is changed to int64_t and uses av_rescale_q from
codec timebase to stream timebase, is it less exact than AVFrac ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312