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

[Michael Niedermayer]

On Thu, Jan 03, 2008 at 02:47:09AM +0200, Uoti Urpala wrote:
> 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

approximately yes, in all perfect fine detail no.


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

I do want attachments to be exported to the application in some _CLEAN_ way,
hey this is even the topic of this thread.
But i guess i can say whatever i want you will keep asking questions as if i
said something i didnt say.


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

yes


> and prefer the
> inferior alternative 

no, sorry even if you want that, i wont accept any inferrior variant no matter
who proposed it, be it you or myself


> of things not working at all.

they would work, so would AVAttachments with some changes


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

Iam just trying to make it clear that we need a clean solution. Iam not
seriously planing to not support attachments.
But threatening with that makes people think about the half baked mess they
proposed, hey i even got you to write some comments. Even if they are
90% trollinga and flaming.


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

Really, how do you know?


> would be implemented. 

Not really, no, it doesnt matter how its implemented. You need to pass the
fonts to the decoder independant of its implementation.
Its even quite bad design if you base the API used for passing attachments
to the decoder on a specific decoder implementation.


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

Many applications use lavc and lavf, changing the API continuously is quite
annoying for most of their developers. Its also a lot of extra work for them 
to repeatly change the code used to access lavc/lavf.



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

You have mostly shown that your interpretations and guesses of what i
meant were wrong.


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

Your ability to read my thoughts fails. I dont want the things you claim
i do.


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

let me simplify that
"its not possible. To make it possible you would ..."

Is it just me or is that what you say selfcontradicting? And iam not claiming
that would be limited to the above 2 sentences.


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

Its hard to find a smart analogy to a stupid claim. After all the point
was to show that your claim is stupid.


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

That rather would have to be fonts stored duplicated in some .txt files.


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

Just compare fonts to some refinement streams (mpeg/jpeg/jpeg2k scalability)
They both are optional and improve presentation if available.

Your arguments are based on the idea that mkv attachments and fonts (2
distinct things implemented with the same syntax) are mkv specific and
dont exist in other containers. This is false.
Still you skip over the presented facts and continue to claim we should
ignore the other containers. And design a API based on how mkv handles
fonts and attachments

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/459bd82d/attachment.pgp>