[MEncoder-users] Sound problem when transcoding and joining 2 mpg-files

[Jan Ehrhardt]

Jan Ehrhardt in gmane.comp.video.mencoder.user (Fri, 21 Sep 2012
18:33:12 +0200):
>5. Transcode the files separately and knit them together with:
>   - asfbin for wmv
>   - flvbind for flv
>   - mencoder (!) for mp4, followed by mp4creator -optimize
>
>I am now timing the 'knitting' on a SD card for a 1:21h video file,
>consisting of 6 parts.

Timing, including the initial transcoding:
22/09/12  6:03:48,12 start transcoding 
22/09/12  6:21:07,13 start knitting with mencoder 
22/09/12  6:23:24,98 start mp4creator -optimize 
22/09/12  6:23:58,49 optimized mp4concat-by-mencoder.mp4 ready 
22/09/12  6:23:58,51 start knitting with mp4box 
22/09/12  7:44:32,68 optimized mp4concat-by-mp4box.mp4 ready 

The initial encoding of the 6 parts takes    17:19 minutes
The joining of the six parts takes            2:18 minutes
Mp4creator -optimize the joines mp4 takes     0:35 minutes

But joining the parts by mp4box (on the SD card) takes no less than
1:20:34 hour (in stead of the 2:53 minutes by mencoder+mp4creator).

Because pictures say more than 1000 words:
http://x32.elijst.nl/mp4mp4.htm

The first screenshot shows the initial transcoding of the parts (between
50 and 70% CPU usage), then the joining by mencoder (25% CPU usage),
followed by mp4creator -optimize (about 5% CPU usage).

After that MP4box starts its job with somewhere around 1% CPU usage. I
do not know what cause the spike at about 80% of the first shot, but it
came in handy, bacause the same spike is on the left side of the second
screenshot. On the second screenshot you'll see at the far right side
the beginning of a small hill in the CPU usage. I deliberately caused
that one myself, because the same hill is at about one third of the
third screenshot.

The two spikes on the right side of the third screenshot mark the
beginning and the end of the last phase of MP4box: 'writing ISOM file'.
Even that phase takes about twice the time mencoder+mp4creator need to
join the files.

Food for thought for the GPAC developers...

Jan