> On Tue, Oct 12, 2021 at 3:54 AM Jan Ekström <jee...@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 _______________________________________________ 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".
