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

Baptiste Coudurier baptiste.coudurier
Wed Jul 28 20:14:45 CEST 2010

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

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

Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list