MP4Box: Import options which have colons in them not properly parsed

[bilditup1]

When importing a track, when using an import option which itself could take a colon in its parameters, that option is not properly parsed: everything after the colon is treated as its own import option, and is flagged as invalid.

For example, consider this command:
mp4box -add "video.mp4#trackID=1:fps=59.960:par=10:11" -new "video_new.mp4"

This results in the error,
Unrecognized import option 11, ignoring

Or this command:
mp4box -add "video.mp4#trackID=1:fps=59.960:name=file://trackname.txt" -new "video_new.mp4"

This results in the error,
Unrecognized import option //trackname.txt, ignoring

In each of these cases, there is an alternative - using the separate "-par" or "-name" options after the initial -add. But both the help screen in mp4box and the official documents still list the use of :par and :name as valid import options (in other words, as valid parameters to modify a string being fed to the '-add' parameter).

If this functionality was intentionally removed, and end users wanting to specify a pixel aspect ratio or a trackname contained in a text file should use the general -par and -name options, then the help text and documentation should be changed to reflect this. Otherwise, whatever change was made that broke these options should be reverted.

This issue occurs with the latest nightly on Windows 10 x64.

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, this issue persists in an identical manner on GPAC version 0.7.2-DEV-rev192-gd1ee384-master.

[jeanlf]

indeed now fixed, thanks for the report

[miguelapg]

This issue is happening again.

I see again an error message like:

mp4box -add C:/Temp/input.h264 -new C:/Temp/output.mp4

Unrecognized import option /Temp/input.h26, ignoring

[aureliendavid]

ok the previous changes dealt with C:\... paths (backslash) and paths inside options, but didn't handle C:/... (forward slash) properly

(note that the command should still work since the unrecognized option is ignored but it's not great)

(note2: the 0.9 / filters branch handles this properly)

anyway I fixed it, should be ok now, reopen if needed

[miguelapg]

Thank you very much! I tested it and worked fine. That warning is not appearing anymore.