[FFmpeg-devel] [PATCH 1/1] mov: read track title

[Đông Nguyễn]

> On Tue, Oct 12, 2021 at 3:54 AM Jan Ekström <jeebjp at gmail.com> wrote:

> Huh, so I seem to have incorrectly read things previously :) .I
> started implementing reading of the 3GPP titl box due to the QTFF spec
> saying that `name` is not supposed to be an end user facing name, but
> an internal/debug reference [1].
>
> Of course, then checking the actual contents of the 'name' box within
> the udta box, it seems like I was incorrect, as the box's structure
> doesn't match. The udta side of the spec has a one-liner that doesn't
> say much about how it should be utilized [2].
>
> So I guess this udta `name` is in this case not something internal,
> after all? ┐(´д｀)┌
>
> [1]
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html
> [2]
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25538

:) all I did is just trying to implement reverse path of [3]

[3]
https://github.com/FFmpeg/FFmpeg/commit/da9cc22d5bd5f59756c2037b02966376da2cf323#diff-e40972d5f339c353a7fef633294e1f13fbb2a972ec34f484e4a9fd6a516a11f4R1723-R1724


> Since this seems to be a barebones string-only box, if you set `key =
> "title"; raw = 1;` the string parsing should work. No need to add the
> track_title variable to skip other types of string parsing (data_type
> is zero so it shouldn't hit any of those pieces of custom data parsing
> logic, either).

nice, will update the patch, thanks
btw, `track_title` is also used to reduce checking that the `udta` is
inside track boxes but I guess it is a minor point and more clearer if
explicitly check it before setting metadata.


> Since QTFF, ISOBMFF, 3GPP and such all seem to utilize udta in both
> movie and track boxes, I think the correct thing to do would be to
> first to poke in something a la
>
https://github.com/jeeb/ffmpeg/commits/enable_writing_udta_metadata_for_tracks
> .
>
> Unfortunately currently movenc's track udta box writing seems to be
> *very* limited, which thus leads to things which were read from track
> udta boxes to not be propagated through (and thus you get a lot of
> FATE test diffs where information is only seemingly removed and not
> propagated from another location). Welcome to the mess that is
> mov(enc) :) .
>

So should I update the patch as suggested and/or wait for properly movenc's
udta patch?

Thanks
Dong