[FFmpeg-devel] [PATCH] specify a name/description per stream
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 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.
ALBUM: stupid name
COMPOSER: Mr. X
EMAIL: x at x.com
LEAD_PERFORMER: Mr. Y
EMAIL: y at y.com
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
> char  vs char * being one, and iam in favor of char * i think
I'm also in favor of char *.
> how much metadata is lost when remuxing currently?
> 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 ==
English EAC3 48000Hz 640 kb/s tot , 3/2: L+C+R+SL+SR
== Subtitles ==
So it is nothing more than a full text description of the stream,
supposed to help people
More information about the ffmpeg-devel