[FFmpeg-devel] [NUT-devel] [PATCH] nut: Add per frame sidedata and metadata

Michael Niedermayer michaelni at gmx.at
Thu Mar 28 16:07:13 CET 2013


On Wed, Mar 27, 2013 at 05:14:23PM +0100, Luca Barbato wrote:
> On 27/03/13 15:41, Michael Niedermayer wrote:
> >  reserved_count[frame_code] (v)
> > -    MUST be <256.
> > +    Muxers conforming to this version of the specification MUST set it to
> > +    !!(flags[frame_code] & FLAG_SIDEDATA)
> > +    Demuxers MUST support any value from 0 to 255
> > +    These rules are to ensure extensibility of the format.
> 
> Would enjoy a better explanation.
> Such as "muxer supporting FLAG_SIDEDATA MUST set the reserved_count to 1
> if side data is in used in order to be compatible with older demuxers"

ok, added


> 
> > +
> > +sidedata_size[frame_code] (v)
> > +    Size in bytes at the end inside data which represent frame sidedata and
> > +    frame metadata.
> 
> metadata and sidedata are different items, I'm not exactly cool in
> lumping everything in the same serialized dictionary.

i see what you mean, ill post a different suggestion in a moment


> 
> > +
> > +side_data
> > +    This data structure is used both in frames for per frame side and metadata
> > +    as well as info tags for metadata covering the whole file, a stream
> > +    chapter or other.
> > +    Metadata is data that is about the actual data and generally not essential
> > +    for correct presentation
> > +    Sidedata is semantically part of the data and essential for its correct
> > +    presentation. The same syntax is used by both for simplicity.
> > +    The use of sidedata should be avoided and the information be put inside
> > +    the codec bitstream, if its syntax supports carrying such information.
> 
> This statement should be omitted.

ok


> 
> > +    Types of per frame side data:
> > +    "Channels", "ChannelLayout", "SampleRate", "Width", "Height"
> > +        This frame changes the number of channels, the channel layout, ... to
> > +        the given value (v)
> > +        If used in any frame of a stream then every keyframe of the stream
> > +        SHOULD carry such sidedata to allow seeking.
> > +    "Extradata", "Palette"
> > +        This frame changes the codec_specific_data or palette to the given
> > +        value (vb)
> > +        If used in any frame of a stream then every keyframe of the stream
> > +        SHOULD carry such sidedata to allow seeking.
> > +    "CodecSpecificSide<num>"
> > +        Codec specific side data, equivalent to matroskas BlockAdditional (vb)
> > +        the "<num>" should be replaced by a number identifying the type of
> > +        side data, it is equivalent/equal to BlockAddId in matroska.
> > +    "SkipStart", "SkipEnd"
> > +        The decoder should skip/drop the specified number of samples at the
> > +        start/end of this frame (v)
> > +    "UserData<identifer here>"
> > +        User specific side data, the "<identifer here>" should be replaced
> > +        by a globally unique identifer of the project that
> > +        uses/creates/understands the side data. For example "UserDataFFmpeg"
> 
> I'm not certain serializing type and enumeration this way would work
> that well.

its easy extendible and quite flexible, it also uses existing syntax

Thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130328/dd731edd/attachment.asc>


More information about the ffmpeg-devel mailing list