Log in

View Full Version : Muxing with MKVMerge: broken MP4 input?


Amefurashi
7th February 2010, 13:26
Hi guys,

just got an issue I can't manage to resolve on my own.
I've been muxing MKV for ages, and everything went just fine... except this morning. Input files are a x264-encoded 720p MP4 stream, two audio streams (AC3 and MP4-AAC), three IDX/SUB subtitles: my average muxing elements.
As usual mmg starts the muxing procedure but then hangs up for a few seconds while the progress bar stays still, and finishes with the message "everything went fine". Unfortunately all went bad: the clip is only 2 minutes long.
Is there a problem with my MP4 input file (broken GCC output module in my x264 build or something)? Maybe my PC is cursed? The MP4 clip plays just fine in any media player I fed it into and has correct length.
Using MKVToolnix v.3.1.0, x264 rev. 1416. Analyzer log for MP4 file:


[ Info sul file ]

Nome: source.mp4
Data: 6/02/2010 21:15:01
Dimensione: 3,827,352,923 bytes (3650.048 MB)

[ Info generiche ]

Durata: 02:17:57 (8276.761666 s)
Tipo di contenitore: MP4/MOV
Major brand: JVT AVC version 0
Compatible brands: ISO Base Media
Data creazione: 5/02/2010 09:37:41 UTC
Data modifica: 5/02/2010 09:37:41 UTC
Streams totali: 1
Tipo stream n. 1: video (avc1) {GPAC ISO Video Handler}
Audio streams: 0

[ Dati rilevanti ]

Risoluzione: 1280 x 532
Larghezza: multipla di 32
Altezza: multipla di 4
DRF medio: 21.141217
Deviazione standard: 0.704584
Media pesata dev. std.: 0.677429

[ Traccia video ]

Codec: avc1
Risoluzione: 1280 x 532
Frame aspect ratio: 320:133 = 2.406015
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 320:133 = 2.406015
Framerate: 23.976043 fps
Frames totali: 198446
Bitrate: 3697.302720 kbps

[ Info sulla codifica H.264 ]

User data: x264
User data: core 84 r1416 fcf70c2
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2009
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=5
User data: deblock=1:-2:-1
User data: analyse=0x3:0x133
User data: me=umh
User data: subme=10
User data: psy=1
User data: psy_rd=1.0:0.0
User data: mixed_ref=1
User data: me_range=32
User data: chroma_me=1
User data: trellis=2
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: fast_pskip=1
User data: chroma_qp_offset=-2
User data: threads=6
User data: sliced_threads=0
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: constrained_intra=0
User data: bframes=5
User data: b_pyramid=2
User data: b_adapt=2
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: wpredp=2
User data: keyint=240
User data: keyint_min=24
User data: scenecut=40
User data: intra_refresh=0
User data: rc_lookahead=60
User data: rc=2pass
User data: mbtree=1
User data: bitrate=3698
User data: ratetol=1.0
User data: qcomp=0.60
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: vbv_maxrate=50000
User data: vbv_bufsize=50000
User data: ip_ratio=1.40
User data: aq=1:1.00
SPS id: 0
Profile: High@L4.1
Num ref frames: 5
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Codifica entropica: CABAC
Weighted prediction: P slices - explicit weighted prediction
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Sė
Frames totali: 198446
Drop/delay frames: 0
Frames corrotti: 0

P-slices: 40564 ( 20.441 %) #####
B-slices: 156264 ( 78.744 %) ####################
I-slices: 1618 ( 0.815 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

[ Analisi DRF ]

DRF medio: 21.141217
Deviazione standard: 0.704584
DRF max: 23

DRF<17: 0 ( 0.000 %)
DRF=17: 14 ( 0.007 %)
DRF=18: 365 ( 0.184 %)
DRF=19: 2075 ( 1.046 %)
DRF=20: 25403 ( 12.801 %) ###
DRF=21: 115128 ( 58.015 %) ###############
DRF=22: 52194 ( 26.301 %) #######
DRF=23: 3267 ( 1.646 %)
DRF>23: 0 ( 0.000 %)

P-slices DRF medio: 21.160265
P-slices deviazione std.: 0.669888
P-slices DRF max: 23

B-slices DRF medio: 21.158373
B-slices deviazione std.: 0.678455
B-slices DRF max: 23

I-slices DRF medio: 19.006798
I-slices deviazione std.: 0.767432
I-slices DRF max: 22


Thank you in advance. :)

sneaker_ger
7th February 2010, 16:56
You might wanna post a sample in the mkvtoolnix thread (http://forum.doom9.org/showthread.php?t=120648).

b66pak
7th February 2010, 18:40
@Amefurashi try demuxig the .mp4 to raw...and then feed it to mmg...

mp4box -raw 1 mymp4file.mp4
_

Amefurashi
10th February 2010, 11:24
Thanks b66pak, once demuxed to raw .h264 stream I remuxed it into MP4 via MP4Box and mmg did the job flawlessy. Seems the x264 output was broken, even if it seemed proper to me (and to players/analyzers).

b66pak
10th February 2010, 18:29
once demuxed to raw .h264 stream I remuxed it into MP4 via MP4Box and mmg did the job flawlessy

or you can add directly the .h264 stream to mmg...
_

Dark Shikari
10th February 2010, 19:36
Thanks b66pak, once demuxed to raw .h264 stream I remuxed it into MP4 via MP4Box and mmg did the job flawlessy. Seems the x264 output was broken, even if it seemed proper to me (and to players/analyzers).Or maybe mkvmerge's mp4 support is broken.

Amefurashi
13th February 2010, 11:55
Or maybe mkvmerge's mp4 support is broken.

Don't really know, I just got this issue again with mmg 3.2.0 using a 1080p file encoded with rev. 1416. :confused:

Dark Shikari
13th February 2010, 12:09
Don't really know, I just got this issue again with mmg 3.2.0 using a 1080p file encoded with rev. 1416. :confused:That's not surprising, it's not exactly the kind of problem I would expect to go away after a good night's sleep.

Mosu
13th February 2010, 14:25
Can you please upload such a problematic mp4 file to my FTP server? I'd like to take a look at it and fix the problem.

saint-francis
15th February 2010, 16:23
I too am having such issues. I go through the exact same procedure as the OP and occasionally end up with a .mkv that is several GB to small. MMG says it finished without an error but the process is unusually fast. They all mux to .mp4 just fine and all of the constituent files play fine.

Mosu
15th February 2010, 16:25
Like I said I need access to such problematic files. Otherwise I cannot fix the issue

saint-francis
15th February 2010, 17:12
I'm uploading a sample for you right now. Should be done in about 15-20 minutes.

Mosu
16th February 2010, 08:45
I'm uploading a sample for you right now. Should be done in about 15-20 minutes.

Thanks for the upload. Unfortunately I cannot reproduce the problem with that file. It muxes fine with 3.1.0 and 3.2.0 on both Linux and Windows. Can you please verify that it does NOT mux fine for you?

saint-francis
16th February 2010, 14:37
Yeah, sorry, I didn't test it. I just used YAMB to split it off of a file that didn't mux. Maybe the process fixed the issue? I'm out of town for several days but I will find one that doesn't work when I return. Thanks for looking into it though.

Mosu
16th February 2010, 14:40
No, the problem hasn't been fixed yet. I've received another file in the meantime by someone else, and that file still shows very short output files. I've also identified the part that mkvmerge seems to have a problem with: the MP4 file in question contains an edit list entry for the first 800 frames, but the whole file contains rougly 90000 frames. At the moment mkvmerge stops after processing all the frames mentioned in the edit lists. I'll have to fix this.

Mosu
17th February 2010, 18:54
You can try the following build on your problematic file(s). It works fine for the one file I've received from someone else, but I don't have more material to test.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.2.0-build20100217-216-setup.exe

saint-francis
27th February 2010, 14:54
You can try the following build on your problematic file(s). It works fine for the one file I've received from someone else, but I don't have more material to test.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.2.0-build20100217-216-setup.exe

Yep, it works for the couple trouble files I've had. Thanks.