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

[Uoti Urpala]

On Thu, 2008-01-03 at 00:12 +0100, Michael Niedermayer wrote:
> 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:

> > 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.

And do you know what an application using lavf needs access to? Even if
you create a separate "generalized" hack for subtitles there are still
other attachment types. Do you think that lavf should not provide access
to Matroska attachments in general (at a level which does not care what
the application wants to use those attachments for)?

> > 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.

It does not when there is no spec how to format such extradata or how to
store SSA/ASS in those containers at all. And there can be other kinds
of attachments.

> 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.

Such an "extended solution" would not only be about lavf code but would
require extending the specs of the container formats in question. And
that solution would not solve access to Matroska attachments in general.

You won't accept what you consider an "inferior" solution and prefer the
inferior alternative of things not working at all.

> > > 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.

My reply is no more trolling than your "the decoding is not done in lavc
so nobody needs to demux them either". Do you actually have a better
reason for your comment than those I suggested?

> 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.

Whether it will cause problems depends on how that hypothetical decoder
that nobody is working on would be implemented. And even if you think
you'll want a more general solution later that doesn't mean you should
do it that way now when you don't need it yet.

> 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.

I've made a lot of points which have nothing to do with trolling, and
I've shown that several of your ideas were wrong. I think that should
make the discussion not completely pointless unless you refuse to learn
from anything said by me.

Your attitude in this discussion seems to be that the solution you
consider the most general or clean must be implemented, even if it does
not actually work all that well or isn't the most practical one to use
with container formats as they now exist. Instead of creating a solution
which works best in the current situation you want to create a solution
designed for a future where everyone else does things the way you want
and changes their code to fit your preferred design.

> > > 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

It's not possible to make an avi which would give identical results. To
get that you'd first need to extend specs and then change decoders.

> > 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.

Your analogy is stupid enough that you're probably just trolling, but
I'll write a short reply anyway. In a filesystem some files have
identical parts but are still stored separately (like video tracks).
Other resources are in separate files which are shared by multiple
contexts (like fonts).
 
> > > 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.

Your reply makes no sense. Of course separating .ass does not differ
from separating audio and video; the point is that it's natural to split
to an .ass file + font files, whereas nobody splits to a video extradata
file plus separate video main content file. And an .ass track without
(all) fonts attached still makes some sense, whereas nobody muxes video
tracks without the extradata.