Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Issue converting file, MP4Box Segfaults #2
First, this is awesome. Thanks for putting it together.
I am having an issue when running your script though, MP4Box is unable to create the file due to a segfault. I think the problem really is MP4Box but I had a couple questions about modifications that might make troubleshooting MP4Box easier.
I think you can see where I'm going with this, I'd like to invoke MP4Box directly and get the output from MP4Box as I'm sure it will be requested from those guys.
If you have encountered this before I'd be open to any suggestions.
I have attached the relevant logs below for the sake of completeness.
The error I get in /var/log/syslog is:
Here is the full output of my attempt to invoke xenonmkv
ok, I was able to make those modifications,
Diffs are below, essentially, I added self.log.debug(cmd) to mp4box.py and I commented out the line, cleanup_temp_files(args, log) in xenonmkv.py
this prints the full array of arguments, so I had to manually remove the ' and , (well... search and replace in a text editor.)
The cleaned up version is:
/usr/bin/MP4Box -v output.mp4 -add /var/tmp/temp_video.h264 -fps 23.976 -par 1=1:1 -add /var/tmp/audiodump.aac -tmp /var/tmp/ -itags name=foo
obviously, this is variable. e.g. fps
Interestingly, when I run the command manually, I get a core dump, then when I re run it, it is able to complete, however, the file is nearly double the original. I've opened a support request with the MP4Box guys ( https://sourceforge.net/tracker/?func=detail&aid=3585833&group_id=84101&atid=571739 )
If you have any input I'd like to hear it.
The problem with the second attempt at MP4Box is that it tries to append to the existing file. So for a true "run again from scratch" test, you'd have to do the following:
I would suspect the second attempt would fail as well in the same manner as the first file.
For a full output log with XenonMKV (well, at least what the utility tries to parse), try the
I will check the code during the next week and add this as a debug option if it's not already there in the development branch.
Ah, sorry, saw the
I'm a GPAC maintainer. First thank you for reporting, we're always happy to fix bugs.
Be careful on Unix, the filesystem of /var/tmp and your current dir must be the same. Otherwise the final 'mv' can fail.
We have a '-new' option to avoid this :)
On the README.md file, one wrote:
We write in /usr/local/bin (and /usr/local/lib/) whereas the system installs its packets in /usr/bin. So there shouldn't be any overlap. This is a general behaviour for all software on Linux. You can also ask GPAC to install in '/opt/mydir' by calling './configure --prefix=/opt/mydir'.
I hope it helps. Otherwise you can come and write on our forums.
Thanks Romain. I will make the appropriate adjustments (add
Curious, though - what about with tmpfs to ext4, for example? As in, distributions that mount /tmp as tmpfs and then a "mv" to an ext4 path could have interesting side effects.
As of commit f813703, XenonMKV performs the following in the development branch. This will be pushed to the master branch, probably when I've added more Windows/OS X support and those code paths have been tested a bit better.
I'm not sure exactly what to do with the filesystem concern. XenonMKV does perform a final
I'll leave this open for a few more days but I'm not certain there's anything else I can do on the XenonMKV side to resolve. We'll have to wait for the friendly GPAC folks to investigate (they may need a sample, or specific bug report, etc...)
Romain, What are you considering a "problem" regarding my second attempt? As I stated in GPAC thread ( http://sourceforge.net/tracker/?func=detail&atid=571739&aid=3585833&group_id=84101 ) I was able to create the .mp4 on the second attempt, if the file already existed.
When I add the -new flag, MP4Box core dumps even if output.mp4 exists.
Also, I have cd'd to /var/tmp where the files currently exist, and where I assume the work is going on. I also added the "-tmp /var/tmp" flag to attempt to force MP4Box to using /var/tmp
Perhaps I'm confusing the issue since I opened tickets with maintainers of the two projects before I knew if it was a MP4Box or a xenonmkv issue? Would it be better to keep all correspondence on SourceForge?
PS, at this point, I'm pretty sure the issue is with MP4Box, but as a work around, is there some way to get MP4Box to "incompletely complete" such that output.mp4 is left over and a second run of MP4Box will allow the file to be created? It's a bit of a "hack" for the time being, but it would at least allow me to convert MKVs for the time being.