[FFmpeg-devel] [PATCH] avformat/mov: parse 3gpp titl from media or track udta

Jan Ekström jeebjp at gmail.com
Sun Aug 1 23:49:57 EEST 2021


On Sat, Jul 24, 2021 at 9:48 PM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Wed, Jul 21, 2021 at 8:30 PM Jan Ekström <jeebjp at gmail.com> wrote:
> >
> > On Wed, Jul 21, 2021 at 8:28 PM Jan Ekström <jeebjp at gmail.com> wrote:
> > >
> > > Seems to be:
> > > * Utilized by Handbrake for track titling
> > > * Actually defined as "title for the media"
> > >
> > > Definition from 3GPP TS 26.244 follows:
> > >
> > > Field               Type                Details                             Value
> > > BoxHeader.Size      Unsigned int(32)                                        BOX_SIZE
> > > BoxHeader.Type      Unsigned int(32)                                        'titl'
> > > BoxHeader.Version   Unsigned int(8)                                         0
> > > BoxHeader.Flags     Bit(24)                                                 0
> > > Pad                 Bit(1)                                                  0
> > > Language            Unsigned int(5)[3]  Packed ISO-639-2/T language code
> > > Title               String              Text of title
> > >
> > > Semantics:
> > >
> > > Language: declares the language code for the following text. See
> > > ISO 639-2/T for the set of three character codes. Each character
> > > is packed as the difference between its ASCII value and 0x60.
> > >
> > > The code is confined to being three lower-case letters, so these
> > > values are strictly positive.
> > >
> > > Title: null-terminated string in either UTF-8 or UTF-16 characters,
> > > giving a title information. If UTF-16 is used, the string shall
> > > start with the BYTE ORDER MARK (0xFEFF).
> > > ---
> >
> > A sample for this sort of metadata can be seen with
> > https://0x0.st/-zjq.m4v , which was posted at
> > https://github.com/mpv-player/mpv/issues/8488 .
> >
> > The sample contains both "name" and "titl" boxes:
> > [udta: User Data Box]
> >     position = 3991500
> >     size = 71
> >     [name]
> >         position = 3991508
> >         size = 28
> >     [titl]
> >         position = 3991536
> >         size = 35
> >
> > ...out of which if I read QTFF documentation correctly "name" should
> > not be utilized for user-facing naming, and "titl" is actually a
> > user-facing metadata box. Thus I implemented the latter.
> >
> > Jan
>
> Ping.
>
> Includes a link to a testable file, and the specification of the box
> is in the commit message :)
>
> Jan

Will apply tomorrow after work unless there are any comments.

The only thing I more or less was unsure about was whether there was
any nice way of first figure out the length of the string (since it
might not go all the way to the end of the box) and then allocating a
buffer for it for parsing, or if people wanted static buffers of
arbitrary length (I saw arbitrarily ~200 char limited things nearby,
which probably work for most things, but would indeed lead to randomly
cut strings). At the point of writing the patch, since the value was
an unsigned int, I decided to allocate a buffer of left_bytes + 1 as
that seemed simple enough, and then pass that buffer into either the
AVFormatContext metadata, or the AVStream's metadata.

The way that per-language metadata is handled (adding the language as
a suffix a la "title-fin" for example) was noticed being done in
another function in this file, and that style was followed. It did
make me think if at some point having a set of language-specific
sub-keys for a base metadata key would at some point make sense.

Also, is that linked sample good enough for a FATE test (3,9MiB), or
should I try to generate a more limited sample?

Jan


More information about the ffmpeg-devel mailing list