[FFmpeg-devel] [Bulk] Re: [Bulk] [PATCH] avformat/mxfdec: dont truncate packets

[Tomas Härdin]

On Wed, 2014-02-05 at 22:25 +0100, Michael Niedermayer wrote:
> On Wed, Feb 05, 2014 at 04:09:17PM +0100, Tomas Härdin wrote:
> > On Tue, 2014-02-04 at 16:54 +0100, Michael Niedermayer wrote:
> > > On Tue, Feb 04, 2014 at 04:23:13PM +0100, Tomas Härdin wrote:
> > > > Aside: can we just use libmxf instead? Or would that cause problems? I
> > > > know NIH runs deep in this project, but for stuff like MXF it makes
> > > > sense to have fewer confused implementations around (especially true for
> > > > muxers)
> > > 
> > > adding libmxf wrapers, sure perfectly welcome
> > > 
> > > prefering libmxf if available, would probably be the decission of the
> > > mxf muxer/demuxer maintainer if there is no consensus. That first
> > > would need libmxf wrapers though
> > > 
> > > droping our mxf (de)muxer, in favor of libmxf, well that has a
> > > problem. no libmxf package in ubuntu LTS (and i guess others) and that
> > > would make this rather inconvenient for the end user.
> > 
> > Sounds like "no worries" to me - just add ingex as a submodule/subtree*
> > and link lavf to libMXF statically unless told to use the system's
> > libMXF.so. That way future distributions can create ingex packages with
> > dynamic libraries and tell lavf to link to them instead.
> > 
> > *) libMXF is part of the ingex project which uses CVS, but perhaps the
> > Beeb can be convinced to switch to git (or FFmpeg keeps an endorsed git
> > mirror of it)
> > 
> 
> > > Also with external libs you generally cannot do regression tests as
> > > their output changes depending on their and not our revission.
> > 
> > Not a problem if we point to specific commits via submodule/subtree.
> 
> I wouldnt call that external
> rather thats just one of several ways to include the code internally
> which yes would work
> 
> 
> > Plus isn't this the kind of stuff that package managers are supposed to
> > handle? "FFmpeg version X requires ingex version [Y,Z)"
> 
> do you volunteer to maintain this ?
> 
> I mean debug and fix all the regression test failures like
> when someone on netbsd who has ffmpeg 1.2 and libmxf 7.8 installed on
> a alpha having a different checksum from what you have on linux
> with maybe not exactly the same versions ?
> 
> and would any distribution package it with such tight dependancies?
> they might have other packages and if they have different but
> similarly tight dependancies that would prevent them fro being
> installed at the same time with some luck

Well, I could probably manage to maintain one package. But more
importantly, if no other FOSS project in any distribution needs libmxf
then there's no need for packagifying it.

In either case, I'm getting the feeling that replacing the demuxer would
cause drama. So I'm happy just ensuring it gets fixed for now, and
porting that code from libmxf should be fine thanks to LGPL.

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140207/8baffa97/attachment.asc>