[FFmpeg-cvslog] r19173 - trunk/libavformat/adtsenc.c

[Michael Niedermayer]

On Mon, Jun 29, 2009 at 09:46:02PM +0100, Jethro Walters wrote:
> Michael Niedermayer wrote:
> > On Fri, Jun 26, 2009 at 09:04:11AM +0100, M?ns Rullg?rd wrote:
> >> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
> >>
> >>> Hi,
> >>>
> >>> On Thu, Jun 25, 2009 at 4:30 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> >>>
> >>>> On Wed, Jun 24, 2009 at 11:11:21PM -0400, Ronald S. Bultje wrote:
> >>>>> See attached. I chose libavutil because log.h is there.
> >>>> that i have to reject, libavutil is not your trashcan
> >>> Err, wait, I thought you wanted to dissect out pieces of lavc into lavu if
> >>> lavf used them also to decrease the dependence of lavf on lavc? Or is that
> >>> no longer the case? (Again, not that I care much, but I'm making lots of
> >>> mistakes in the "but I thought that..." department lately.)
> >> That was originally the intent.  Somewhere along the way it seems to
> >> have changed.
> > 
> > It was never my intent to make lavu into a place for code common to lavc&lavf
> > Thats also written in the 2nd sentance of doc/avutil.txt
> > the 1st sentance:
> > (libavutil is a small lightweight library of generally useful functions)
> > explains what it was intended for.
> > Its true this is my view and others might surely have a differnt view but
> > as far as i can remeber noone said anything against what is written in
> > avutil.txt ...
> > 
> > Besides all this, a lightweight lib of usefull things like balanced binary
> > trees, md5,sh1,crc,aes,portable reading of IEEE floats, ...
> > is usefull for many applications and libs.
> > a lib that contains exactly all code common to lavc & lavf is primarely
> > usefull to lavc & lavf.
> > Also if the goal is to make lavf useable withot lavc well, what else would be
> > used, propriatery codecs? nothing? iam surely in favor of seperating them
> > more cleanly but i think using lavu as a common trash dump would be a big
> > loss
> 
> Pardon me for thinking out loud, but could a new directory, something
> like "libavcommon", be useful in this regard? If it's common across more
> than one of the "libav" codebases, then shouldn't it be in one coherent
> place? Again, pardon me for thinking very much out loud here.

Pardon me for thinking out loud as well, whats the point of a common lib?
shouldnt the question abot how and why lavf without lavc be awnsered first
because if lavf depends on lavc, later is as good as a common lib


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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-cvslog/attachments/20090630/287efcb6/attachment.pgp>