[FFmpeg-devel] [PATCH] attachments support in matroska demuxer
Wed Jan 2 12:03:30 CET 2008
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
> On Wed, 2008-01-02 at 04:31 +0100, Michael Niedermayer wrote:
> > On Wed, Jan 02, 2008 at 03:47:40AM +0200, Uoti Urpala wrote:
> > > On Tue, 2008-01-01 at 13:27 +0100, Michael Niedermayer wrote:
> > > > On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
> > Well, if the demuxer cannot know which streams need an attachment then so
> > the matroska file cannot be remuxed with a subset of the streams unless you
> > also include all (likely) unneeded attachments.
> AFAIK this is the case - you cannot know which attachments decoders
> might be able to use based on container-level information only.
> > That would be a serious
> > design flaw and hardly one upon which we should base our API.
> API for doing what? Libavformat should provide access to the contents of
> Matroska attachments. What other things should the same API be
> generalized to do? Hypothetical attachments in other containers?
and about "Hypothetical attachments in other containers"
info packets in nut
cd covers in id3
looking in the mov spec i found the following:
Image font data. This atom contains two more atoms. An 'idat'
atom contains compressed image data to be used to draw the text
when the required fonts are not available. An 'idsc' atom contains
a video sample description describing the format of the compressed
and the swf filespec even has a complet chapter about fonts and text
So i hope it will be clear to everyone that a solution only considering
mkv is problematic.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel