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

[Michael Niedermayer]

On Tue, Feb 04, 2014 at 04:23:13PM +0100, Tomas Härdin wrote:
> 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)

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.
Also with external libs you generally cannot do regression tests as
their output changes depending on their and not our revission.

but maybe you meant something else and i misunderstood ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140204/01d1188a/attachment.asc>