MP4Box crashes in trusty importing chapters file with raw video
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gpac (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
This is a kind of follow-up to a bug I posted last year, here:
https:/
The problem: MP4Box crashes in Raring when importing a chapters text-file. As I noted in the above bug report, this problem effectively prevents OGMrip from ripping a DVD to mp4-format - at least directly.
Some work seems to have been done on this bug in Trusty, because if we now use MP4Box to import a chapters file, say like so:
azed@azed-N110:~$ MP4Box -new -nodrop -brand mp42 -itags name="KDoc" -add KDoc.mp4#video -add KDoc.mp4#audio -chap KDoc.txt KDoc2.mp4
There's no problem:
IsoMedia import KDoc.mp4 - track ID 201 - Video (size 368 x 208)
Warning: track ID 201 has references to a track not imported
IsoMedia import KDoc.mp4 - track ID 101 - Audio (SR 48000 - 2 channels)
Warning: track ID 201 has references to a track not imported
Warning: track ID 101 has references to a track not imported
[Chapter import] Guessed video frame rate 29.97 (30000:1001)
Saving KDoc2.mp4: 0.500 secs Interleaving
azed@azed-N110:~$
So OGMrip now works OK, then?
Unfortunately not. Everything goes fine until we get to the final file-merging stage:
Importing AAC: |================== | (90/100)
Importing AAC: |================== | (91/100)
Importing AAC: |================== | (92/100)
Importing AAC: |================== | (93/100)
Importing AAC: |================== | (94/100)
Importing AAC: |======
Importing AAC: |======
Importing AAC: |======
Importing AAC: |======
Converting to ISMA Audio-Video MP4 file...
[Chapter import] Guessed video frame rate 29.97 (30000:1001)
(me again) and at this point the ap dies.
What's gone wrong?
We recall that OGMrip builds its mp4 outfile out of raw video and audio files (it actually encodes the video to avi-format with a "dummy" audio-track, and then extracts the raw video using MP4Box with the -aviraw option)
OK, as an experiment, let's unbundle our original mp4 into its component raw-audio and raw-video parts (we already have the chapters file), and see if we can put them back together again a la OGMrip. Thus, we obtain the track IDs with:
azed@azed-
Then extract the raw video with (in this case):
azed@azed-
Extracting MPEG-4 AVC-H264 stream to h264
azed@azed-N110:~$
[The track actually appears as: "KDoc_track201.
And the raw audio with:
azed@azed-
Extracting MPEG-4 AAC
azed@azed-N110:~$
[MP4Box o/ps the track as: "KDoc-track101.aac"
We can now try to build our new mp4 with, say:
azed@azed-N110:~$ MP4Box -new -nodrop -brand mp42 -itags name="KDoc" -add KDoc2_track201.
we get:
AVC-H264 import - frame size 368 x 208 at 29.970 FPS
AVC Import results: 5933 samples - Slices: 30 I 2883 P 3019 B - 1 SEI - 28 IDR
Stream uses forward prediction - stream CTS offset: 2 frames
AAC import - sample rate 48000 - MPEG-4 audio - 2 channels
[Chapter import] Guessed video frame rate 29.97 (30000:1001)
Segmentation fault (core dumped)
azed@azed-N110:~$
i.e., the ap crashes.
But if we now omit the chapters-file:
azed@azed-N110:~$ MP4Box -new -nodrop -brand mp42 -itags name="KDoc" -add KDoc2_track201.
AVC-H264 import - frame size 368 x 208 at 29.970 FPS
AVC Import results: 5933 samples - Slices: 30 I 2883 P 3019 B - 1 SEI - 28 IDR
Stream uses forward prediction - stream CTS offset: 2 frames
AAC import - sample rate 48000 - MPEG-4 audio - 2 channels
Saving KDoc2.mp4: 0.500 secs Interleaving
azed@azed-N110:~$
Then everything is fine.
And we can even, now, add the chapters-file back in:
azed@azed-N110:~$ MP4Box -new -nodrop -brand mp42 -itags name="KDoc2" -add KDoc2.mp4#video -add KDoc2.mp4#audio -chap KDoc.txt KDoc2.mp4
IsoMedia import KDoc2.mp4 - track ID 1 - Video (size 368 x 208)
IsoMedia import KDoc2.mp4 - track ID 2 - Audio (SR 48000 - 2 channels)
[Chapter import] Guessed video frame rate 29.97 (30000:1001)
Saving KDoc2.mp4: 0.500 secs Interleaving
azed@azed-N110:~$
Odd.
Questions
1. Is there any chance of this annoying little bug being fixed in the near future?
If the answer to the above is: NO
2. Would compiling and installing the latest gpac in my system help matters?
The answer to the second question above would appear to be "Yes"
First up, the problem is indeed caused by a fault in the version of gpac - version 4288 - in the standard repos. I know this because I installed the std gpac in a live-cd ubuntu 14.04 environment, and it bombed as usual. I then uninstalled the std version and installed a more up-to-date version from source. This performed perfectly.
To compile gpac from source and then install it, first read these notes
https:/ /help.ubuntu. com/community/ CompilingEasyHo wTo
Read also the on-line man-page for checkinstall - an ap for creating deb-files
Then head for this page:
http:// gpac.wp. mines-telecom. fr/2011/ 04/20/compiling -gpac-on- ubuntu/
which will tell you how to access the gpac source-code, how to prep your system for the install, and how to configure and build the ap (for tips on how to carry out the actual install itself, refer to the first couple of sources listed above)
Working in a bog-standard 32-bit version of ubuntu 14.04 installed in a samsung N110 netbook, I did this:
PREPARATION
Began by making a full backup of my system to a tar-file [always a wise precaution, especially if (like me) you have no background in computing and are not a linux / ubuntu expert]
I then uninstalled OGMrip with:
sudo apt-get remove ogmrip
Purged my existing copy of gpac with:
sudo apt-get purge gpac
removed the (hidden) gpac configuration file in my home folder with:
rm ~/.gpacrc
*******
Created a folder in which to do the needed construction work for the new gpac with:
sudo mkdir /usr/local/src
Gave it the appropriate permissions with:
sudo chown $USER /usr/local/src
The permissions came out as:
drwxr-xr-x 3 azed root
Thus the "user" has read, write and execute permissions. If not do:
sudo chmod u+rwx /usr/local/src
cd-ed into the new folder with:
cd /usr/local/src
******
Installed the tools to collect the source-code and carry-out the construction work with:
sudo apt-get install subversion build-essential checkinstall
BUILDING THE PACKAGE
Obtained the source with:
svn co svn://svn. code.sf. net/p/gpac/ code/trunk/ gpac gpac
This fetches the source-code and deposits it in a directory called "gpac" in your current working directory. I copped version 5269
Installed the 30-odd dependences with:
sudo apt-get install <a whole bunch of stuff listed in the gpac w/page above>
dpkg put up a couple of warnings here, which I ignored; one relating to the removal of libavcodec54 (replaced by libavcodec- extra-54) , the other to the removal of libjack- jackd2- 0:i386
cd-ed into the gpac folder, and then configured the source-code with:
./configure --prefix=/usr
NOTE: the switch "--prefix=/usr", here, ensures that the executables MP4ox and MP4Client are installed to /usr/bin, in place of the default /usr/local/bin.
Had no problems here.
Built the new software with:
make
Again, no problems
At this stage, you can test how well the newly-built MP4Box (sitting in some subdirectory of the present directory) performs, but I didn't bother with this having already tested out the new software in a flash-install. Instead I proceded directly to the install phase.
INSTALLING THE NEW PACKAGE...