MP4Box: Track references not stripped on import - breaks TTXT chapters

[bilditup1]

Consider an mp4 video that has a gpac ttxt menu track in it, plus an arbitrary amount of other tracks (audio, subtitle, whatever). Let's say one were to create a new mp4 by importing the video track only, and wanted to replace the current gpac ttxt menu with a different gpac ttxt menu.

For example, video.mp4 has video track 1, audio tracks 2, and 3, subtitle track 4, and ttxt chapter track 5, and I want to create video_new.mp4 with video track 1, a new audio track from a separate file, and a new chapter track, also from a separate file:

mp4box -add "video.mp4#trackID=1" -add "audio.mp4#trackID=1" -add "new_chapters.xml:name=:chap" -new "video_new.mp4"

This results in a video that indeed has the new chapter track. However, we are warned about the reference to the now-orphaned original menu:

Warning: track ID 1 has references to a track not imported

and the presence of the reference to the old chapter track remains. In other words, if one runs MediaInfo on video_new.mp4, the 'Menus' line of the video track will list two track IDs: the ID of the original track in video.mp4 - in this example, 5 - and the ID of the new chapter track - here, 3. In other words,
<Menus>5,3</Menus>.

On playback, phantom chapter track 5 will preempt real chapter track 3. Real chapter track 3 will never be parsed or acknowledged by the player in question. Practically, it's like it isn't there at all.

If, by chance, the trackID of the chapters track added to the new video matches the trackID of the chapters track in the original video, then there is no problem - there is no duplicate track entry in the Menus line of the video track in MediaInfo, and everything works fine. Obviously that isn't an acceptable workaround, though.

Additionally: in the example above, I specified a new chapters file. Importing the old chapters track from the old file, like so:

mp4box -add "video.mp4#trackID=1" -add "video.mp4#trackID=3" -add "video.mp4#trackID=5:name=:chap" -new "video_new.mp4"

does result in a warning about not importing a referenced track, but does NOT result in the phantom menu issue, because the track IDs of the original mp4 are retained! This is appears to be odd behavior - while on the plus side, other track information, like track language and track name, is also retained, having trackIDs skip around instead of simply being reassigned from scratch is odd. And it doesn't stop there. Let's say one decided to import the video track and one of the audio tracks from the original file, but supply a new ttxt chapters file:

mp4box -add "video.mp4#trackID=1" -add "video.mp4#trackID=3" -add "new_chapters.xml:name=:chap" -new "video_new.mp4"

In this case, the audio file imported retains its track ID of 3, and the chapters file is assigned a track ID of 4 - the next whole number. This results in the same issue - two menus being referenced, one of which isn't in the file, but preempts the second, extant menu from being recognized or loaded. As might be guessed, importing the audio track with track ID 4:

mp4box -add "video.mp4#trackID=1" -add "video.mp4#trackID=4" -add "new_chapters.xml:name=:chap" -new "video_new.mp4"

works, since the track ID of the the new chapters file would be assigned 5 - the same as in the original file.

This only straightforward, complete workaround to this problem is first manually exporting the video track from the original mp4, and then importing it, instead of importing the original mp4 directly and specifying the trackID of the video in the import parameters. While this works, it is also an extra, inelegant, time-consuming step.

Alternatively, one can also, either after the fact or in the original creation of the new file, change the trackID of the new chapters file to match that of the trackID of the chapters in the original file. For example, in the case of a file with chapters that have a trackID of 4, but which originated from another file with chapters that had a trackID of 5:

mp4box video_new.mp4 -set-track-id 4:5

Or, equivalently, during the original creation of video_new.mp4 (again, using an audio track other than the one with the trackID of 4):

mp4box -add "video.mp4#trackID=1" -add "video.mp4#trackID=3" -add "new_chapters.xml:name=:chap" -set-track-id 4:5 -new "video_new.mp4"

In these cases, in MediaInfo, there are still two entries in the Menus line of the video track's information - it changes from <Menus>5,4</Menus> to <Menus>5,5</Menus> - but the chapters do get parsed (at least with the playback software I was using). If one decides to change the track ID again - let's say to 2 - the chapters will still work, however, the Menus entry for the video track reads <Menus>2,5</Menus>, rather than <Menus>5,2</Menus>. The lingering presence of an extra track reference seems undesirable: I have only tested these videos with one piece of playback software, after all, and even if I haven't, this just seems 'wrong'.

In conclusion, if possible, a flag should be added that strips the original file of useless/obsolete track references upon importation. Or, even better, the default behavior should be the stripping of such track references, and a flag should be added that would disable such stripping. (Aside from that, it might make good sense to renumber tracks upon import, rather than retaining original trackIDs from a now obsolete context. But, this is a separate issue, whose consequences are not always obvious. The obsolete track reference issue is more concretely negative.)

All this was observed with the latest nightly on Windows 10 x64. I have only been able to test whether chapters work in MPC-HC 1.7.11 x86 as I do not have an iDevice handy at the moment, but it is clear that the reference to the no-longer-existing chapters file is undesirable regardless.

ED: All of this was actually observed with GPAC version 0.7.0-rev3-g10dc09c-master (I had installed the newest nightly to a different location, but forgot to change the PATH variable in Windows to reflect this). But when using GPAC version 0.7.2-DEV-rev192-gd1ee384-master, the issues are even stranger: instead of 2 Menus entries, there are 3, so, it seems like things haven't improved (or potentially, have gotten worse...)

ED2: It appears that if one simply does mp4box -add "video.mp4" -new "video_new.mp4" on a video file containing a ttxt menu, a) the ttxt menu is still imported, b) it is assigned a trackID of two, c) none of the other tracks are imported, d) the Warning: track ID 1 has references to a track not imported error still occurs, and e) the Menus entry of the video track in MediaInfo still contains two references, first to the original track ID, then to track 2.

[jeanlf]

Indeed this is strange. I patched the code so that single track imports (-add file#ID) no longer keeps track references, unless the imprt switch :keep_refs is set. Note that when importing the complete file the track references will still be kept.
This should also fix your issues with ttxt import, reopen if needed.

[bilditup1]

Very cool, thank you. I don't think I have a proper build environment set up atm (either via Visual Studio, lxss, or msys) and don't think I'll have the time to set one up any time soon. I don't want to bother you but will there be a new nightly out soon reflecting the patches for #873 and #874?

[jeanlf]

yes soon, we have a small issue with our buildbot, should be fixed any time soon

[aureliendavid]

The windows builder was indeed stuck. The new builds are now available. The latest one is here: https://download.tsi.telecom-paristech.fr/gpac/latest_builds/win64/gpac-0.7.2-DEV-rev198-gdf5f0cd-master-x64.exe