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

[Michael Niedermayer]

On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
> On Sat, 29 Dec 2007 22:38:24 +0300
> Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
> Conclusions:
> - Attachment really looks like a stream itself. You can select
>   the one you want to remux. For example the film poster would
>   just be a jpeg stream with a single picture. The specificity
>   of those streams would be:

>     * contain one single packet
>     * not pts

Contain no packets, just one global extradata, this was proposed already.
If you use normal packets there will be problems with them disapearing
if a stream is split timewise or if you seek before demuxing the
first packet.
Iam not completely happy with this use of streams but we will need some
solution and maybe its the least ugly, we will see ...

at least iam pretty sure extradata to be a better choice than 1 normal
packet


>     * has a filename (important so that an ASS decoder can
>       select the proper ttf based on it's name)

>     * always demuxed before other (normal) streams (IIRC)

extradata should be available before packets ...


>   It seems to me that attachment would fit pretty well, each one
>   in its own AVStream. Does this sound reasonable ?
> - Here is how remuxing to other formats (avi, mov...) could work:
>     * supported codec (jpeg poster) could be muxed as a normal
>       JPEG stream with only one picture
>     * ttf streams should be written in a separate file (that's
>       the way various players expect to find ttf fonts when
>       demuxing AVI, IIRC)

> - I think the only required API modifications to support this
>   would be:
>     * adding AVStream.filename and maybe AVStream.id_of_link_stream.
>     * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble)
>     * adding a way to mux ttf font in a separate file (maybe use
>       a separate muxer for this, ie. call 2 different muxers from
>       ffmpeg. seems ugly, but I've no better idea right now).

Well, there are a few more things i think
We need name / (mime) type to remux attachments
(CD Cover / ? / tiff)
(Fan art / image/x-photoshop / psd)
There also could be other things like Author, ...

Also we need a way to get the attachments to the decoders, yes we dont
have a ASS/SSA decoder but lets assume we had.

And while we can just store the streams in avi/mov, where does the
filename/name/type go? if its dropped you could end up with a huge
number of images and not know what each is.


> 
> What do you think about this proposal ? Does it sounds like a
> reasonable base ?

> If it's not, the only viable alternative seems to be
> AVFormatContext.attachments just like in the original patch,
> but with some additionnal code to allow "remuxing", etc...

yes, these seem to be the 2 options we have

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/af7af29d/attachment.pgp>