Message ID | 20180319211137.45432-1-cidstrom@telltalegames.com |
---|---|
State | Accepted |
Commit | 65616bc191b110af6a81aa38b1d15aa9879d8cbc |
Headers | show |
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
diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 5b1e66c897..ca15a00265 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -3027,7 +3027,7 @@ static int mov_write_track_udta_tag(AVIOContext *pb, MOVMuxContext *mov, if (ret < 0) return ret; - if (mov->mode & MODE_MP4) + if (mov->mode & (MODE_MP4|MODE_MOV)) mov_write_track_metadata(pb_buf, st, "name", "title"); if ((size = avio_close_dyn_buf(pb_buf, &buf)) > 0) {