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

Tomas Härdin tomas.hardin at codemill.se
Wed Feb 5 16:09:17 CET 2014


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.
Plus isn't this the kind of stuff that package managers are supposed to
handle? "FFmpeg version X requires ingex version [Y,Z)"

What will be a problem are UUIDs, which libMXF uniquely generate each
time as the spec *highly recommends*. But that's a minor problem that
can be solved by either zeroing them before hashing or mocking libuuid
with a predictable version during test.

Finally, mxfenc's way of generating predictable UUIDs is bad since the
top-level SourcePackages in two different files will have the same UID
despite containing different essence. A third MXF file would then be
unable to unambiguously reference either essence in the two other files.

/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/20140205/df9fac84/attachment.asc>


More information about the ffmpeg-devel mailing list