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

Tomas Härdin tomas.hardin at codemill.se
Tue Feb 4 16:23:13 CET 2014


On Tue, 2014-02-04 at 12:04 +0000, Tim Nicholson wrote:
> On 03/02/14 21:14, Tomas Härdin wrote:
> > On Mon, 2014-02-03 at 16:32 +0100, Michael Niedermayer wrote:
> > [..].
> > 
> >> maybe someone can figure out how to seperate them with a minimum of
> >> code. Might even make a good gsoc qualification task
> > 
> > Good idea
> > 
> >> Also can this not be done without using the UL ?
> > 
> > Nope :)
> > 
> > Example: the OPAtom spec mandates clip wrapping (all audio/video in one
> > huge KLV chunk). But the OP1a spec is vague on the subject - OP1a files
> > are usually frame wrapped (audio/video interleaved, like sane formats),
> > but they can also be clip wrapped since the spec doesn't forbid it.
> > That's how I interpret the specs at least
> > 
> > /Tomas
> > [..]
> 
> From a man who knows more than I do....
> 
> 
> "OP-Atom doesn't mandate clip wrapping. See for example D-Cinema files
> which use frame wrapping. OP-1A doesn't mandate frame wrapping. See for
> example AS-02 which uses clip wrapping in OP-1A for audio.

Hooray for open-ended specs. This solidifies the need for a EC UL ->
WrappingKind mapping

> I see the context for this is from the FFmpeg forums. I'm not on the
> email list, so you might want to point them to a libMXF commit I made
> fairly recently:
> http://sourceforge.net/p/bmxlib/libmxf/ci/fb7c9f74b7a93c4f70b21986534987565def42d3/
> This commit should provide some guidance in how the essence container
> labels can be summarised to extract the clip/frame wrapping information.
> bmx has some extra analysis beyond that, but the libMXF function should
> cover most cases."

Neat, and we can link it in the GSoC task. Makes me wonder why SMPTE
didn't just add a simple 1-byte field for the wrapping kind (conjecture
= not having a working implementation during standardization)

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)

/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/20140204/ea02bbbf/attachment.asc>


More information about the ffmpeg-devel mailing list