[FFmpeg-devel] [PATCH] specify a name/description per stream

Aurelien Jacobs aurel
Thu Aug 28 03:34:41 CEST 2008


Michael Niedermayer wrote:

> On Wed, Aug 27, 2008 at 09:04:32PM +0200, Aurelien Jacobs wrote:
> > Michael Niedermayer wrote:
> > 
> > > On Wed, Aug 27, 2008 at 08:04:13PM +0200, Aurelien Jacobs wrote:
> > > [...]
> > > > > > [...]
> > > > > >  
> > > > > > Index: libavformat/avformat.h
> > > > > > ===================================================================
> > > > > > --- libavformat/avformat.h	(revision 14980)
> > > > > > +++ libavformat/avformat.h	(working copy)
> > > > > > @@ -409,6 +409,8 @@
> > > > > >       * - decoding: Set by libavformat.
> > > > > >       */
> > > > > >      AVRational sample_aspect_ratio;
> > > > > > +
> > > > > > +    char *name;  /**< name/description of the track */
> > > > > >  } AVStream;
> > > > > 
> > > > > Maybe char name[1024] is preferrable, like all other metadata in
> > > > > AVFormatContext ?
> > > > 
> > > > I tried to be consistent with other fields in AVStream, such as
> > > > filename. If an array is really preferred I can change it.
> > > > Any other opinion about this.
> > > 
> > > a more generic metadata API may be interresting
> > > Especially with user specified keys instead of "name" "author", ...
> > > the current system would break down.
> > 
> > I agree that a more generic metadata API would be useful.
> > But you should note that my current patch is not about adding
> > a new metadata field in AVFormatContext. It's about adding a
> > specific field in AVStream.
> > Well, I guess that a generic metadata API could also be used
> > per stream, but I wonder if this wouldn't be overkill. 
> 
> per stream, per chapter, per program, per file, ...

Well, I see the picture.

> > I doubt
> > that any muxer could really fully benefit from it.
> 
> nut would have no problem with it :)

BTW: matroska support some kind off recursive metadata.
eg:
     ALBUM: stupid name
     COMPOSER: Mr. X
         EMAIL: x at x.com
         PHONE: 00000
     LEAD_PERFORMER: Mr. Y
         EMAIL: y at y.com
         PHONE: 11111

So a tag can apply to stream, chapter, etc...
But a tag can also apply to another tag.

Would nut support such kind of nested tags ? (yes, sure, nut supports
everything one can imagine, and even what no one can imagine)

Is it worth to try to support such kind of nested tags in a
generic metadata API ?

> > So do you place the generic metadata API as a strong requirement
> > to export the stream name, or would my patch be an acceptable way
> > to do it, at least in the mean time ?
> 
> generic metadata is not a strong requirement but things slowly become
> messy without it

Agree.

> char [1024] vs char * being one, and iam in favor of char * i think

I'm also in favor of char *.

> Or
> how much metadata is lost when remuxing currently?

many

> Or
> What language is the metadata in

In matroska, each tag can have its language specified individualy.

> Besides, iam not sure if i just missed it when reading the thread but
> what exactly is a name of a stream ? Also iam curious about some
> examples about what value it would have before approving this ...

This is a random string describing the stream. Some people use it
to put the name of the movie in the video track, some use it to
add a full description of the codec and encoding parameters, some
use it to add the full name of the language...
Here are some examples for different kind of tracks:

== Video ==
kurenai - 06: The Light is Shining Above You
1280x528 @ 23.98 fps 4392 kb/s
Matrix Reloaded Trailer XviD 1.0 Beta1
Neon Genesis Evangelion Renewal 01: Angel Attack

== Audio ==
2ch Vorbis
English EAC3 48000Hz  640 kb/s tot , 3/2: L+C+R+SL+SR
5.1 HE-AAC
HE-AAC 50-70

== Subtitles ==
Styled Subtitles
Czech subtitles
Portuguese

So it is nothing more than a full text description of the stream,
supposed to help people 

Aurel




More information about the ffmpeg-devel mailing list