[FFmpeg-devel] [PATCH] Drop AVFrac at the next lavf major bump

[Michael Niedermayer]

On Tue, Jan 06, 2009 at 12:00:58AM +0100, Stefano Sabatini wrote:
> On date Monday 2009-01-05 23:03:10 +0100, Diego Biurrun encoded:
> > On Mon, Jan 05, 2009 at 11:18:29PM +0100, Michael Niedermayer wrote:
> > > On Mon, Jan 05, 2009 at 10:23:47PM +0100, Diego Biurrun wrote:
> > > > On Mon, Jan 05, 2009 at 09:10:41PM +0000, M?ns Rullg?rd wrote:
> > > > > Michael Niedermayer <michaelni at gmx.at> writes:
> > > > > 
> > > > > > On Mon, Jan 05, 2009 at 01:09:48AM +0100, Stefano Sabatini wrote:
> > > > > >> Hi all, this is just to revive the old discussions about the removal
> > > > > >> of AVFrac.
> > > > > >> 
> > > > > >> Related threads:
> > > > > >> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/60413
> > > > > >> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/38380
> > > > > >> 
> > > > > >> I picked up the Mans patch, with some little modifications to avoid to
> > > > > >> break backward compatibility, yes it's done with ugly ifvers but I
> > > > > >> don't think there are better ways... apart from bump major seems there
> > > > > >> seems to be many important changes (metadata API) in these days.
> > > > > >> 
> > > > > >> I think the AVRational64 approach is correct, since it shouldn't lose
> > > > > >> precision, unfortunately there is some regressions which I think are
> > > > > >> due to some roundings, I still didn't investigate but I will do if you
> > > > > >> like the approach.
> > > > > >
> > > > > > What is the point of "renaming" AVFrac to AVRational64 ?
> > > > > > we could just keep AVFrac ...
> > > > > 
> > > > > You were the one who marked AVFrac deprecated.  I assumed you had a
> > > > > reason for this.
> > > 
> > > i did, i thought we could avoid it just by AVRational & int64_t but this
> > > didnt work out
> 
> Are we sure we can't avoid AVFrac using AVRational + int64_t?  (This
> is not a rethorical question, as for me I'm still not sure.)

you can do it with 1bit variables and NAND doesnt mean it is a good idea
though ...


> 
> If we can avoid it, we should, since AVFrac is used just for one var
> and keeping a public struct (with a private interface) for just one
> use doesn't look nice.
> 

> The one advantage of AVRational64 with respect to AVFrac is that it
> seems to require less computations, also it doesn't need specific
> functions (av_frac_init/av_frac_add) to deal with it, so looks simpler
> to me.

AVRational64 without any way to add, multiple, divide, ... them and with
just a single use ...



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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090106/eed8cf4d/attachment.pgp>