On Sat, Jul 24, 2021 at 9:48 PM Jan Ekström <jee...@gmail.com> wrote: > > On Wed, Jul 21, 2021 at 8:30 PM Jan Ekström <jee...@gmail.com> wrote: > > > > On Wed, Jul 21, 2021 at 8:28 PM Jan Ekström <jee...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
