[FFmpeg-devel] [PATCH] attachments support in matroska demuxer

[Michael Niedermayer]

On Wed, Jan 02, 2008 at 12:51:46AM -0500, Rich Felker wrote:
> On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
> > >  That would be a serious
> > > design flaw and hardly one upon which we should base our API.
> > 
> > API for doing what? 

That what libavformat is for, muxing and demuxing, the system used in
matroska is as such insufficient to remux a subset of streams. That is
even mkv->mkv


> > Libavformat should provide access to the contents of
> > Matroska attachments. 

Libavformat first needs a generic API for this, though if there is no
interrest in a clean solution iam prepared to reject attachment support
completely.
Ive no interrest in a "lets quickly just export attachments" to make ASS/SSA
in mplayer work with lavf.
lavc doesnt even have a ASS/SSA decoder, so from my point of view attachments
are not needed currently. Especially not in a half thought through way.


> > What other things should the same API be
> > generalized to do? Hypothetical attachments in other containers?

Lets say if the system doesnt work with avi/mov/nut its rejected.
And about there being a spec for AVI/MOV id rather preempt someone comming
up with storing mkv with attachments as is in a stream in avi. We had this
with ogg in the style of vorbis in ogg in avi ...


> > Restrict it to less than general attachment handling for subtitle fonts
> > only, but generalize that to hypothetical fonts in other containers?
> 
> I think Michael's concern is how you expect a decoder for ASS/SSA
> subtitles to obtain the fonts. Having demuxer-specific code (or even
> code which depends on a demuxer api at all) in the decoder is not
> acceptable.

Its not hard to add a pointer to AVCodecContext which points to lets say
a linked list of attachments.
If that is easy within other demuxer / decoder APIs though is less certain.


[...]
> 
> > Duplicating the fonts can be expensive if there are lots of subtitle
> > tracks (which there can be as they're otherwise small). In addition to
> > the memory directly used by the font files there are also whatever data
> > structures parsing and rendering them requires - duplicating the fonts
> > in the extradata of each track would force a decoder to do extra work
> > comparing them to go back to the shared representation if it wants to
> 
> This makes sense.

As already said this doesnt make attachments/fonts special, extradata or
parts of extradata are also commonly identical.
The solution here (attachments) is quite specific ignoring the general
problem of redundancy in extradata. That as well can be redundancy relative
to some default large vector quantizer tables.

Also sharing any non constant data generated from fonts or extradata 
between several decoder instances will require thread synchronization so half
of the "sensible" comment above really only applies for decoders peppered with
mutexes fromyour favorite thread API. (and its unlikely that a decoder would
be written like that ...)


> 
> > avoid that overhead. And what about other Matroska attachments?
> > Shouldn't there be a general way to access them? I think it would be
> > better to create an API for accessing Matroska attachments (generalized
> > to attachments in other containers if some get such functionality), and
> > leave issues specific to fonts and their relation to subtitle tracks
> > outside libavformat for now. 
> 
> The whole idea of attachments is rather disgusting and something of a
> hack... But I don't know any right way to deal with them, just that
> existing ways are not the right way..

Well, iam waiting to see some actually working solution from you and uoti
which is better
Minimum requirements are
* efficiently remuxing a subset of streams
* mov and avi support (the fonts can even be in seperate files but id like
  to see a working patch here not some general sketch of how it might work)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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-devel/attachments/20080102/c87a51a5/attachment.pgp>