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

[Michael Niedermayer]

Hi

On Mon, Dec 18, 2006 at 11:40:00AM +0100, Baptiste Coudurier wrote:
> 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 ?

that might work ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates