[FFmpeg-devel] [PATCH] Export mkv doctype via the metadata API

Michael Niedermayer michaelni
Wed Jul 28 23:50:48 CEST 2010


On Wed, Jul 28, 2010 at 11:14:45AM -0700, Baptiste Coudurier wrote:
> On 07/28/2010 06:18 AM, Michael Niedermayer wrote:
>> On Wed, Jul 28, 2010 at 08:41:57AM +0200, Anton Khirnov wrote:
>>> On Wed, Jul 28, 2010 at 07:51:24AM +0200, Reimar D?ffinger wrote:
>>>> On Wed, Jul 28, 2010 at 12:31:05AM -0400, Alex Converse wrote:
>>>>> We do something similar for mp4/mov.
>>>>>
>>>>> If people think this is stupid then I won't put up much of a fuss.
>>>>
>>>> I don't know. On the one hand it is useful, but it is stupid because
>>>> other formats will write it in their metadata.
>>>> Actually even the matroska muxer (if it supports/supported arbitrary 
>>>> metadata)
>>>> would write "doctype" literally into the new file when remuxing, which
>>>> does seem like not quite the intended behaviour...
>>> Same applies to some other tags we already export, e.g. "encoder", mp4
>>> brand stuff, etc. It seems we need a flag to mark these tags as
>>> nontransferrable.
>>
>> There is metadata that describes a video bitstream like its encoder (ex: 
>> x264)
>> There is metadata that describes the video content like it being recorded
>> with cammera xyz
>> There is metadata that describes the content of timespans of all streams,
>> namely chapters with their title and whatever else
>> There is metadata that describes all streams content like movie title and
>> director
>> There is metadata that describes the binary data of the muxed file,
>> if you call that metadata
>>
>> When what is described is being copied then it is correct to copy the
>> description too. Otherwise its not correct to copy. The problem just
>> starts when data about content and bitstream encodings is mixed by
>> sloppy or stuborn people.
>> The current metadata API is intended for content descriptions where
>> AVOption based structs take bitstream descriptions. Iam working on
>> extending AVOptions so they can easily be used to access fields in
>> the private context of codecs and (de)muxers.
>
> You say that like it is a fact, but I'm not sure I agree with you that 
> bitstream description belongs in AVOption, no demuxer use it yet to begin 
> with 

asf for example sets AVFormatContext.packet_size, which is available
through AVOption

having multiple APIs for this is really not good because applications
would have to support both to collect the information for demuxers and
they would have to somehow convert command like options to both on
muxing. I dont even know how we could do this with AVMetadata,
AVOption has an enumerateable array that one can check a
-packetsize 1024 against, that is find a entry that matches "packetsize"
but with AVMetadata theres no such array and dumping all command line
options into all metadata fields without any name or value checking
seems quite unpractical to me.

We could of course use AVMetadata for demuxers and AVOption for muxers
but this really feels wrong to me.
Thats why i spoke about it like a fact. I really dont see how the
alternative could work out in the big picture, it just would need
a lot of hacks right and left, that "non transferable" flag is just the
begin



>and IMHO AVMetadata looks much simpler for this usage (assuming it's 
> not a byte array, in which case AVMetadata is just limited and cannot 
> support it).

yes AVMetadata is simpler for a demuxer but once one includes an application
that has to decide what to copy, and muxers allowing the doctype to be set
by the user AVMetadata becomes quite inconvenient IMHO

iam open to other suggestions of course but they need to work out for the
whole demuxer+application+muxer system not just be easy for the demuxer


>
> Extending AVOptions is mainly for codec or format specific options when 
> encoding and muxing and per default codecs IMHO.

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100728/0b18f9d5/attachment.pgp>



More information about the ffmpeg-devel mailing list