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

[Michael Niedermayer]

On Wed, Jan 02, 2008 at 09:10:22PM +0200, Uoti Urpala wrote:
> On Wed, 2008-01-02 at 11:21 +0100, Michael Niedermayer wrote:
> > 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:
> 
> > > > 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.
> 
> Do you not want to provide access to the exact contents stored in the
> container through lavf? For Matroska attachments that most likely

Id like to provide access to what is needed and do so in a clean and
flexible way.


> requires some container-specific functionality. Or do you intend lavf to
> only allow access to some common-denominator subset of container
> functionality that is easy to remux in any of them?

Using extradata supports remuxing in avi/mov/nut.
Using AVAttachments as in the patch does not on its own, it could be
extended somehow to make storage in avi/mov possible, until then this
soluton though is inferrior. And i wont accept an inferrior solution.


[...]
> > 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.
> 
> Why would lavf functionality be "not needed" unless lavc has
> corresponding functionality too? 

> Do you consider ffmpeg.c to be the only
> worthwhile program using the libraries? Or think that all video-related
> functionality must be added to FFmpeg and other programs shouldn't use
> SSA/ASS decoding without adding it to lavc? 

Could you please refrain from trolling.
I repeat it again, we need a clean system. If we alread now know that it
will cause problems with a hypothetical ass/ssa decoder in lavc then the
system certainly is not well designed.
Anyway the discussion with you is pointless, you seem to be on a trolling
crussade, ive better things to do then to reply to you any further.


> 
> > > > 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.
> 
> Work to give what result? What are you supposed to get when you try to
> remux an mkv with attachments to avi?

a avi which when decoded results in bit identical video+subs


> 
> 
> > > > 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.
> 
> There are (as already said...) reasons why memory usage by fonts is
> different from video tracks. Video extradata may commonly happen to be
> identical, but subtitles refer to "the same font" in a stricter sense.
> The memory usage associated with fonts can be significant while the
> subtitle track itself is small. It's very rare to have a huge number of
> video tracks as that would make the file size much larger than versions
> with separate tracks, but adding a large number of subtitle tracks
> causes no such problems.

My .avi files also are bigger than my .txt files still they coexist on the
same file system. Based on your aruments one should design a new filesystem
for each mime type.


> 
> > 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.
> 
> It's much more of a problem for fonts than for video or audio extradata.
> And memory use is not the only reason to use attachments. I already
> explained that whether to attach the fonts or assume the decoder has
> them is a decision which can be separate from the contents of the
> subtitle track (unlike video), and that a natural format for demuxing
> a .mkv into separate files is to have .ass files and separate font files
> (unlike video).

You are just describing common practice. Seperate .ass does not differ from
separte audio and video files.

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20080103/1cbfa0eb/attachment.pgp>