[FFmpeg-devel,v2] lavf/movenc: write track title metadata for mov files

Track title (atom 'name') is a well defined user data atom for mov files. Existing code (for mp4) only writes title metadata if present.

Relevant reference docs:

  https://developer.apple.com/library/content/documentation/QuickTime/Reference/QTRef_AtomsResources/Content/QTRef_AtomsResources4.html#//apple_ref/doc/uid/TP40004285-DontLinkChapterID_1--udta-
  https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-63839
---
 libavformat/movenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 3/19/2018 9:11 PM, Courtland Idstrom wrote:
> Track title (atom 'name') is a well defined user data atom for mov files. Existing code (for mp4) only writes title metadata if present.
> 
> Relevant reference docs:
> 
>   https://developer.apple.com/library/content/documentation/QuickTime/Reference/QTRef_AtomsResources/Content/QTRef_AtomsResources4.html#//apple_ref/doc/uid/TP40004285-DontLinkChapterID_1--udta-
>   https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-63839
> ---
>  libavformat/movenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Are you sure this is correct? The links above describe '©nam' as the
title of the content, and 'name' as 'Name of Object", whatever that is
supposed to mean.

Does this match what the MP4 spec says for 'name'?

- Derek

>
> Are you sure this is correct? The links above describe '©nam' as the
> title of the content, and 'name' as 'Name of Object", whatever that is
> supposed to mean.
>

From the spec, '©nam' appears to be a localized entry, which can also be
set per-track in Quicktime (exposed via their annotations editor). Name
appears to be the primary non-localized field used to identify the track,
which is the value I'm looking to set. I started with a Quicktime file as
my target (for some post production work), and worked backwards to figure
out how this field was encoded.


> Does this match what the MP4 spec says for 'name'?
>

I'm not familiar with the MP4 spec -- the specs I found online included the
definition of the user-data 'udta' section, but only one enumerated child
atom, which is copyright.

Any advice here? It's a requirement for my project that I set this field,
and the way it's being used for mp4 seemed exactly like what I wanted for
mov, and works perfectly. I submitted an earlier patch which included this
as an optional feature behind a flag, and I got a suggestion that since
it's a well-defined field, that perhaps it didn't need to be optional.

Cheers,
-Courtland

2018-03-20 5:48 GMT+01:00, Courtland Idstrom <cidstrom@telltalegames.com>:

> Any advice here? It's a requirement for my project that I set this field,
> and the way it's being used for mp4 seemed exactly like what I wanted for
> mov, and works perfectly. I submitted an earlier patch which included this
> as an optional feature behind a flag, and I got a suggestion that since
> it's a well-defined field, that perhaps it didn't need to be optional.

More precisely: I asked you if it is well-defined (assuming it is not since
this is the only reason I can think of it was not used so far).

Carl Eugen

On 3/20/2018 8:31 AM, Carl Eugen Hoyos wrote:
> More precisely: I asked you if it is well-defined (assuming it is not since
> this is the only reason I can think of it was not used so far).

He linked to the definition in the QTFF spec directly above, so it is
certainly defined, at least.

On 3/20/2018 4:48 AM, Courtland Idstrom wrote:
> From the spec, '©nam' appears to be a localized entry, which can also be
> set per-track in Quicktime (exposed via their annotations editor). Name
> appears to be the primary non-localized field used to identify the track,
> which is the value I'm looking to set. I started with a Quicktime file as
> my target (for some post production work), and worked backwards to figure
> out how this field was encoded.

I am OK with the patch so long as it matches the behavior of how QuickTime
Pro (or FCP) creates files, as those are the normative references, more
or less.

- Derek

On Tue, Mar 20, 2018 at 02:12:04PM +0000, Derek Buitenhuis wrote:
> On 3/20/2018 8:31 AM, Carl Eugen Hoyos wrote:
> > More precisely: I asked you if it is well-defined (assuming it is not since
> > this is the only reason I can think of it was not used so far).
> 
> He linked to the definition in the QTFF spec directly above, so it is
> certainly defined, at least.
> 
> On 3/20/2018 4:48 AM, Courtland Idstrom wrote:
> > From the spec, '©nam' appears to be a localized entry, which can also be
> > set per-track in Quicktime (exposed via their annotations editor). Name
> > appears to be the primary non-localized field used to identify the track,
> > which is the value I'm looking to set. I started with a Quicktime file as
> > my target (for some post production work), and worked backwards to figure
> > out how this field was encoded.
> 

> I am OK with the patch so long as it matches the behavior of how QuickTime
> Pro (or FCP) creates files, as those are the normative references, more
> or less.

+1

[...]

>
> > I am OK with the patch so long as it matches the behavior of how
> QuickTime
> > Pro (or FCP) creates files, as those are the normative references, more
> > or less.
>
> +1
>

What can I do to facilitate this? Would it help to create a couple of
samples from QuickTime Pro, and perhaps show the metadata atoms as
displayed by ffprobe -v trace?

Thanks,
-Courtland

On Wed, Mar 21, 2018 at 4:30 AM, Courtland Idstrom
<cidstrom@telltalegames.com> wrote:
> What can I do to facilitate this? Would it help to create a couple of
> samples from QuickTime Pro, and perhaps show the metadata atoms as
> displayed by ffprobe -v trace?
>
> Thanks,
> -Courtland

Hi,

As a way of dumping MOV/ISOBMFF specifics, most likely the output of
L-SMASH's boxdumper's `boxdumper --box FILE.MOV` will be helpful in
checking if similar data is written :)

(as I didn't have a file on hand, I didn't check, but - if dumping of
that specific MOV box isn't added yet into L-SMASH - it should be
relatively straightforward)

Best regards,
Jan

On 3/21/2018 2:30 AM, Courtland Idstrom wrote:
> What can I do to facilitate this? Would it help to create a couple of
> samples from QuickTime Pro, and perhaps show the metadata atoms as
> displayed by ffprobe -v trace?

Any way of verifying will do, even a hex editor.

- Derek

>
>
> Any way of verifying will do, even a hex editor.
>
>
Output from Quicktime (screenshot of the movie inspector -- initial movie
was created in ffmpeg, title added in quicktime, file saved:
https://imgur.com/a/TPCkN)

00308ef0  00 00 00 21 75 64 74 61  00 00 00 15 6e 61 6d 65  |...!udta
....name|

00308f00  54 72 61 63 6b 20 54 69  74 6c 65 20 31 00 00 00  |Track Title
1...|

00308f10  00 00 00 0a 3e 74 72 61  6b 00 00 00 5c 74 6b 68
|....>trak...\tkh|


[size = 33]["udta"]

  [size = 21]["Track Title 1"]

  [0000]



Output from ffmpeg with the patch applied. It looks like this when opened
in Quicktime: https://imgur.com/a/LbT9m


ffmpeg -i acodec-pcm-s24le.wav -i acodec-pcm-s24le.wav -map 0 -map 1
-metadata:s:a:0 title="Track Title 1" -metadata:s:a:1 title="Track Title 2"
-codec copy test-two-tracks-ffmpeg.mov

00307bf0  30 14 1c 00 30 34 14 00  30 54 0c 00 00 00 1d 75
|0...04..0T.....u|

00307c00  64 74 61 00 00 00 15 6e  61 6d 65 54 72 61 63 6b
|dta....nameTrack|

00307c10  20 54 69 74 6c 65 20 31  00 00 08 60 74 72 61 6b  | Title
1...`trak|


[size = 29]["udta"]

  [size = 21]["Track Title 1"]


You'll note that these are different! The Quicktime version is terminated
with a 32-bit integer 0, which is included in the initial size. Relevant
excerpt from the Movie Atoms Quicktime reference:

"A user data list that is formatted as a series of atoms. Each data element
in the user data list contains size and type information along with its
payload data. For historical reasons, the data list is optionally
terminated by a 32-bit integer set to 0. If you are writing a program to
read user data atoms, you should allow for the terminating 0. However, if
you are writing a program to create user data atoms, you can safely leave
out the terminating 0."

See:
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25538


Please let me know if this is sufficient. I can also upload these movies
somewhere, I didn't think it would be appropriate to attach them to this
email.


Cheers,

-Courtland

On 3/21/2018 9:30 PM, Courtland Idstrom wrote:
> Please let me know if this is sufficient. I can also upload these movies
> somewhere, I didn't think it would be appropriate to attach them to this
> email.

I'm satisfied with with it, thanks for checking!

Patch LGTM.

- Derek

On Wed, Mar 21, 2018 at 11:30 PM, Courtland Idstrom
<cidstrom@telltalegames.com> wrote:
>
>
> Please let me know if this is sufficient. I can also upload these movies
> somewhere, I didn't think it would be appropriate to attach them to this
> email.
>
>
> Cheers,
>
> -Courtland

Thanks for the verification, pushed.

Jan