Muxing Raw 264 to MP4 file problem

[virtualdub]

I'm using MeGUI or CommandLine for encoding avs file to .264 raw file.Before x264 build 1649, MP4 box could muxing correctly.
But with the current build 1688 keeping Open-GOP disabled ,the Muxed output mp4 file is strange ,looks like having some bad frames. But the MKVMuxer dosen't have such prob.
Does anyone have suggestion for this?Or roll back to old 1649 build.
MP4Box-0.4.6-dev_20100612
x264 core:104 r1688 0b36c6d

[b66pak]

try this:
http://forum.doom9.org/showthread.php?p=1422915#post1422915
_

[virtualdub]

I see.thanks man, I'll try this temporary solution later to see if MP4 goes well.

[virtualdub]

Just tried few times.Seems the muxed mp4 files are working without any issue under my laptop player. But all of my portable devices as NWZ-XK1060 even could not recognize/play these muxed mp4 files as usual.What's wrong with this Open-Gop patch? Why Para "open-gop = none" can't just simply disable this new imported function ? So I'll keeping the "last" 1649 build for encoding sessions. Really confused result.Hoping for some advices.

[Trahald]

Open gop doesnt work with mp4box from raw currently, and the gpac guys are working on it. Open gop when disabled should have nothing to do with it. (Im pretty sure mkvmuxer isnt magic)

[Trahald]

Can u post your command line and maybe a small sample (raw h264) that shows the problem. ( state what frames to pay attention to).

[b66pak]

you can try also the ffmpeg muxer (http://forum.doom9.org/showthread.php?t=152419)...
ffmpeg -y -i my_h264_muxed_with_x264.mp4 -vcodec copy -i my_audio.xxx -acodec copy my_new_file.mp4
_

[virtualdub]

Ok,more detailed info here.
x264 cmd line
--profile baseline --level 2.1 --crf 21.5 --threads 8 --keyint 240 --min-keyint 1 --open-gop none --scenecut 30 --chroma-qp-offset -3 --qcomp 0.7 --aq-strength 1.04 --merange 24 --me umh --direct auto --subme 9 --psy-rd 0.40:0 --output test.h264 test.avs
mp4box cmd line
-fps 23.976 -add test.h264 -add test.m4a test_mp4box_raw_muxed.mp4
unique ffmpeg mux cmd line
-y -i test.h264 -vcodec copy -i test.m4a -acodec copy test_ffmpeg_raw_muxed.mp4

sorry for no sample clips.but this could easily be discovered if anyone tried to encoding something.
Maybe,it is the muxer's issue , not the x264's. If I'm using mp4box muxing raw h.264, all devices(w/ players on PC) could play it but with some unexpected bad frames. Definitely PLAYABLE.
Using mp4box ,adding audio track to encoded MP4 file ,or using ffmpeg muxer, PC players works great without any issue.This time all handy devices could even NOT PLAY this muxed file. Like it is an corrupt video file. WE know,these devices have some limitation, but we can't change it,right?
Encoding with the 1649 build x264, both muxer do working correctly. So the new x264 and the muxer could improve compatibility for each other?
Thanks all your replies.

[RBO]

As I wrote in the thread quoted above about open-gops, you can mux to MP4 using MP4Box but it will generate files that are difficult to seek. MP4Box generates fully compliant files. The problem has been discussed at the last MPEG meeting and we're waiting for a normative solution. If it takes too much time, we'll see to release a patch :devil:

You can already create mp4 that are easy to seek (although not strictly compliant but players don't care) using directly x264 (with libgpac support) to create your mp4 files:

Romain

[b66pak]

unique ffmpeg mux cmd line
-y -i test.h264 -vcodec copy -i test.m4a -acodec copy test_ffmpeg_raw_muxed.mp4

you tested from only from raw!

please test form .mp4 and .mkv too (instead to encoding to .h264 encode to .mp4 and .mkv)!

ffmpeg -y -i test.mp4 -vcodec copy -i test.m4a -acodec copy test_ffmpeg_from_mp4_muxed.mp4

ffmpeg -y -i test.mkv -vcodec copy -i test.m4a -acodec copy test_ffmpeg_from_mkv_muxed.mp4

i am waiting for results!
_

[SeeMoreDigital]

There's also MP4muxer GUI (http://forum.doom9.org/showthread.php?t=138445) for you to try...

[Trahald]

Tell me what you mean by 'some bad frames' I encoded 1000 frames with your command line and muxed it with mp4box using your command line and I didnt see any issues. How many frames should i encode... describe what bad frames means (totally messed up or hard to see small issues, blocks, discoloration, etc) is it something you see playing normally or when you seek around? if you could encode something and post a sample that would help (i'll approve an attachment soon as i see it) Where you using the 32 bit or 64 bit x264?

[Trahald]

Ok.. I found an issue. "293b47b Support infinite keyint (--keyint infinite)." r1665 is where the curroption starts (when muxed with gpac). I think its the tight framenum/poc max formulas. The only thing is, everything looks legal. I'll look further but it appears there isnt a bug in x264, just that gpac isnt handling certain conditions well. So I wouldnt look for anything to change in x264. If x264 is legal, the code wont change for gpac.

[virtualdub]

to b66pak
the result is NOT WORKING.The handy players could not play these muxed files.BAD LUCK.
to SeeMoreDigital
thanks but not working again.
to Trahald
Yes, the issue maybe related to GPAC itself.But we don't know how long this could be solved. Can we expect that the future fixed video files are suitable for current SMARTPHONE、IPAD、PSP、MP4 PLAYER? Of coz the players on PC platform do working with current muxed files. If the
x264 binary could give us an option to seperate this special condition, that would be very nice.

[b66pak]

@virtualdub today i had some time to make a testing encode with your line:

x264 --demuxer lavf --vf resize:480,270,1:1 --profile baseline --level 2.1 --crf 21.5 --threads 8 --keyint 240
/--min-keyint 1 --open-gop none --scenecut 30 --chroma-qp-offset -3 --qcomp 0.7 --aq-strength 1.04 --merange 24
/--me umh --direct auto --subme 9 --psy-rd 0.40:0 --output video.mp4 43_minute_tv_rec.avi

ffmpeg -y -i video.mp4 -vcodec copy -i audio.m4a -acodec copy test.mp4


result:
General
Complete name : test.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 159 MiB
Duration : 43mn 23s
Overall bit rate : 512 Kbps
Writing application : Lavf52.78.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L2.1
Format settings, CABAC : No
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 43mn 23s
Bit rate mode : Variable
Bit rate : 386 Kbps
Width : 480 pixels
Height : 270 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.124
Stream size : 120 MiB (75%)
Writing library : x264 core 104 r1688 0b36c6d
Encoding settings : cabac=0 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=9 / psy=1
/ psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11
/ fast_pskip=1 / chroma_qp_offset=-5 / threads=8 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0
/ constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=1 / scenecut=30 / intra_refresh=0
/ rc_lookahead=40 / rc=crf / mbtree=1 / crf=21.5 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.04

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 43mn 23s
Bit rate mode : Variable
Bit rate : 122 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 37.8 MiB (24%)


the file play perfect (in sync) on my PSPgo (fw 6.20)!
_

[Trahald]

I made a file with both L-SMASH and GPAC with current rev. that itunes will not accept at all and quick time is giving a 2002 (bad public atom) error. I tried 1649(gpac) from x264.nl and got the same error. the file is 85000 frames. short encodes do not have the error.. Im gonna keep adjusting the --frames until i find where it no longer errors so i can see if its duration or filesize or whatever. @b66pak - can you encode something longer (1hr+) with the same settings and see if it still works?

[Trahald]

Never mind b66pak. I put assumefps(24000,1001) in my script and it worked fine. The original fps came up as 10000000/417083(23.9760431........) Im guessing mp4 container doesnt like the fraction(some compounding rounding error?) Quicktime/itunes accepts the files fine now. My clue was while 20k or above encodes would give 2002 bad public atom errors, at around 10k i would get duration errors from quicktime.

So for now to use the mp4 output of x264 (lsmash or gpac) watch your input framerate.

[b66pak]

more info:

i demuxed my previous encode to raw (using mp4box) and i get this with dgavcindex:

Stream Type: AVC Elementary
Profile: Baseline
Level: 2.1
Frame Size: 480x270
SAR: 1:1
Display Size: 480x270
Frame Rate: 48000/2002 fps
Colorimetry: BT.601* [2]
Frame Structure: Frame
Frame Type: not yet
Coded Number: 62414
Playback Number: 62414
Frame Repeats: 0
Field Repeats: 0
Bitrate: 0.315
Bitrate (Avg): 0.393
Bitrate (Max): 1.920


mp4box info on my previous encode:

* Movie Info *
Timescale 1000 - Duration 00:43:23.243
Fragmented File no - 2 track(s)
File Brand isom - version 512
Created: GMT Fri Jan 02 00:00:00 1970
File has no MPEG4 IOD/OD
Chapters:
Chapter #1 - 00:00:00.054 - ""
iTunes Info:
Encoder Software: Lavf52.78.1
Track # 1 Info - TrackID 1 - TimeScale 24000 - Duration 00:43:23.183
Media Info: Language "Undetermined" - Type "vide:avc1" - 62414 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 480 x 270 - Profile Baseline @ Level 2.1
NAL Unit length bits: 32
Pixel Aspect Ratio 1:1 - Indicated track size 480 x 270
Self-synchronized
Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:43:23.242
Media Info: Language "Undetermined" - Type "soun:mp4a" - 122027 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1


i remuxed the raws with GPAC 0.4.6-DEV (internal rev. 5) (http://kurtnoise.free.fr/mp4tools/MP4Box-0.4.6-dev_20100612.zip) and i get this:

Import results: 62372 samples - Slices: 964 I 61450 P 0 B - 1 SEI - 964 IDR

* Movie Info *
Timescale 600 - Duration 00:43:23.241
Fragmented File no - 2 track(s)
File Brand isom - version 1
Created: GMT Tue Aug 17 17:59:28 2010
File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD
Track # 1 Info - TrackID 1 - TimeScale 24000 - Duration 00:43:21.432
Media Info: Language "Undetermined" - Type "vide:avc1" - 62372 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 480 x 270 - Profile Baseline @ Level 2.1
NAL Unit length bits: 32
Pixel Aspect Ratio 1:1 - Indicated track size 480 x 270
Self-synchronized
Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:43:23.242
Media Info: Language "Undetermined" - Type "soun:mp4a" - 122027 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

this file play on PC (with QT too) but is OOS...this file don't play on my PSP...

as you can see is 42 frames shorter...
_

[Trahald]

Ok.. I found the set of circumstances that cause the other problem (sync issues/frame drops/corruption above) this occurs when an IDR occurs immediately after a frame (that isnt an IDR) with a frame_num/poc_lsb of 0/0 . Until now I assumed it was just mp4box acting up, because l-smash and even gpac when directed to by x264 advances frame numbers correctly under the circumstance and sync is fine. ...But look at my attachment. That is elecard viewer. It is using the same frame number. That is a raw h264 file. However, I cant find anywhere saying that it is illegal to do create the circumstance.

http://img837.imageshack.us/img837/7039/doubleframe.jpg

[virtualdub]

Solved...
Trahald,you are the man. "assumefps(24000,1001)" did the trick to make everything back to normal.
DON'T care if x264 output raw or muxed mp4, both are working if muxed with that ffmpeg tool.All devices could play output file without any probs.
AND if x264 output muxed mp4,mp4box also can produce correct video clip. BUT still BAD LUCK for raw h264 muxed by mp4box with some corrupt frames.

//So we need this "assumefps(24000,1001)". Without this the avisynth engine could not report exact 24000/1001 fps (instead of 23.976) to x264 binary? or DirectShowSource's fault? All devices detect this muxed file as non-standard fps media file, so not working before.
We'are so happy to find this solution.

[kemuri-_9]

//So we need this "assumefps(24000,1001)". Without this the avisynth engine could not report exact 24000/1001 fps (instead of 23.976) to x264 binary? or DirectShowSource's fault?

DirectShowSource has never been known to give accurate frame rates, you should always use assumeFPS with it.
When the fps rate display changed in x264cli from a float to num/den some time ago,
the bizarre fps rates that DirectShowSource produces should've been made more obvious, e.g.

avs [info]: 640x480p 0:0 @ 5000000/166833 fps (cfr)

is what I get from DirectShowSource for a 30000/1001 source without the AssumeFPS

[b66pak]

this is not DirectShowSource fault! this is do to users incompetence or faulty muxers!

here is some examples:

mkv:
Seems stream 0 codec frame rate differs from container frame rate: 47.95 (5000000/104271) -> 23.98 (5000000/208542)

Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

Seems stream 0 codec frame rate differs from container frame rate: 48.00 (10000000/208333) -> 24.00 (10000000/416666)

Seems stream 0 codec frame rate differs from container frame rate: 23.98 (2997/125) -> 11.99 (2997/250)


Seems stream 0 codec frame rate differs from container frame rate: 47.95 (48000/1001) -> 23.98 (48000/2002)

Seems stream 0 codec frame rate differs from container frame rate: 48.00 (48/1)-> 24.00 (48/2)

Seems stream 1 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 29.97 (60000/2002)



avi:
Seems stream 0 codec frame rate differs from container frame rate: 23.98 (65535/2733) -> 23.98 (24000/1001)

Seems stream 0 codec frame rate differs from container frame rate: 23.98 (24000/1001) -> 23.98 (2997003/125000)

Seems stream 0 codec frame rate differs from container frame rate: 23.98 (24000/1001) -> 23.98 (10000000/417083)


Seems stream 0 codec frame rate differs from container frame rate: 23.98 (24000/1001) -> 23.98 (24000/1001)


_

[virtualdub]

One more question to discuss.The x264 build 1649 could handle this flawlessly with the exact same encoding environment but won't working for the later builds. What has been changed in these builds?
I hope someone to clarify a conclusion for this.

[Trahald]

Build 1649 is the last public revision that can be muxed by mp4box without skewing and corruption. What changed is that a different formula for frame_num_max/poc_lsb_max is used (r1665 in the changelog). The formula attempts to use smaller numbers than older revisions. This creates a set of circumstances that can cause mp4box to drop an occasional IDRs which obviously will cause some corruption and change the duration(sync). The solution would be to revert the code... HOWEVER.... there is no evidence the code is wrong. tsmuxer, mkvmerge, etc , etc are just fine with it and nothing i can see in the h264 spec says its wrong. So it probably wont be changed (unless someone can show evidence its wrong per the specs). Since the other method exists (create mp4 with x264) to work around it, people arent stuck. The reason only a few people see this, btw is because when b-frames are used, the formula uses larger values for frame_num_max/pocv_lsb_max so the set of circumstances that cause the dropped IDR in mp4box never occur.

So simple answer... a legal change occurred in r1665 that mp4box cant handle. legal changes dont get reverted for other software.

[b66pak]

now that you discovered this what is ETA for a fixed mp4box?
_

[b66pak]

Build 1649 is the last public revision that can be muxed by mp4box without skewing and corruption. What changed is that a different formula for frame_num_max/poc_lsb_max is used (r1665 in the changelog). The formula attempts to use smaller numbers than older revisions. This creates a set of circumstances that can cause mp4box to drop an occasional IDRs which obviously will cause some corruption and change the duration(sync). The solution would be to revert the code... HOWEVER.... there is no evidence the code is wrong. tsmuxer, mkvmerge, etc , etc are just fine with it and nothing i can see in the h264 spec says its wrong. So it probably wont be changed (unless someone can show evidence its wrong per the specs). Since the other method exists (create mp4 with x264) to work around it, people arent stuck. The reason only a few people see this, btw is because when b-frames are used, the formula uses larger values for frame_num_max/pocv_lsb_max so the set of circumstances that cause the dropped IDR in mp4box never occur.

So simple answer... a legal change occurred in r1665 that mp4box cant handle. legal changes dont get reverted for other software.

actually mkvmerge can't deal with this type of h264 raw (baseline)...muxing from raws with mkvmerge v4.2.0 will lead to a OOS .mkv with 62371 frames instead of 62414!!!
_

[Trahald]

What did you verify the amount of frames with? I couldnt duplicate it.
{EDIT}
Never mind. I was using a file a made with 1649 (when i was testing the fps issue).

Is this something new or do older ones fail also?

[Lyle_JP]

Not to nitpick, but r1659 is the last compatible version of x264 widely released that is GPAC-friendly, and it has (non blu-ray compliant) Open GOP as well. Of course, there's nothing really wrong with r1649 either.

BTW, Does anyone know if the Jeeb or Komisar builds of r1649/59 contained the fade detection patch? It's not clear from their sites which patches were used on older builds.

[komisar]

Lyle_JP, i dont use x264_fade_compensation patch

[Trahald]

Not to nitpick, but r1659 is the last compatible version of x264 widely released that is GPAC-friendly, and it has (non blu-ray compliant) Open GOP as well. Of course, there's nothing really wrong with r1649 either.

BTW, Does anyone know if the Jeeb or Komisar builds of r1649/59 contained the fade detection patch? It's not clear from their sites which patches were used on older builds.

Ahh.. Thanks.. I missed that build. Any builds (public or private) before 1665 will be fine.

[Mosu]

actually mkvmerge can't deal with this type of h264 raw (baseline)...muxing from raws with mkvmerge v4.2.0 will lead to a OOS .mkv with 62371 frames instead of 62414!!!

Please try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.2.0-build20100828-304-setup.exe

[b66pak]

thank you Mosu...it works!!! perfect sync! no droped frames (62414)!
_

[Mosu]

Thanks for testing & confirming the issue's been fixed.

[Trahald]

The problem is the implementation of 7.4.1.2.4 in the avc spec for mp4box. the check for IdrPicFlag != isnt being done. I will write a patch and try to make a binary (maybe...) shortly.

[kypec]

You're THE MAN, Trahald! Patched MP4Box binary would be mostly appreciated :)

[Trahald]

http://www.mediafire.com/?pv1cjac4gih9lbi
is MP4Box from rev 1988... there is a change in bitstream.h in newer version that cause crashes for me (untouched) .. so i started with 1988 and patched that. Attached to the post is the patch

(edit) rev1988 is fairly new so check your output file.

(edit) removed attachment

[Trahald]

To be fair, the "IdrPicFlag !=" line was not in older AVC specs and was added later.

[b66pak]

thank you Trahald...it works!!! perfect sync! no droped frames (62414)!
_

L.E. tested on PSP, PS3, iPad, iPhone, Samsung Galaxy S...
_

[Sharktooth]

Tharald, could you rebuild with your and this patch (http://www.webalice.it/f.corriga/patches/gpac_20100410.patch) (only if necessary) please? a 64 bit version is also very welcome (still with the patch :) ... still if it's necessary)

[Trahald]

I really just did it to help ppl with muxing which 32 bit should be plenty for (yeah i know mp4box is capable of more) I am trying to get the patch committed so hopefully, at that point whoever is making 64 bit binaries of the development builds will do it.

[Sharktooth]

it would be helpfull to have working 32 and 64 bit binaries for MeGUI. eventually ill setup msys/mingw and do it by myself.
thanks anyway.

[Trahald]

if i get time to figure out how, ill do it ( i only have a 32 bit setup )

[komisar]

check this builds of MP4Box, pls... (http://komisar.gin.by/tools/)

[Lyle_JP]

http://www.mediafire.com/?pv1cjac4gih9lbi
is MP4Box from rev 1988... there is a change in bitstream.h in newer version that cause crashes for me (untouched) .. so i started with 1988 and patched that. Attached to the post is the patch

(edit) rev1988 is fairly new so check your output file.

I'm sorry to report some problems with this newly patched muxer. Although it keeps the sound in sync on baseline, I'm seeing a lot of visual problems in playback, both on the PS3 and my PC using Haali splitter and the latest stable ffdshow. This is with video streams created by r1703 of x264, and happens with baseline and high profile material. Sometimes I see the players lock up on a frame and then play "catch-up" a second or two later, or I see messy block trails like the player missed where an I frame was. Remuxing the same video and audio streams with Kurtnoise's Apr 10 x64 mp4box eliminates all video playback issues (although sound is still terribly out-of-sync on baseline).

EDIT:
check this builds of MP4Box, pls... (http://komisar.gin.by/tools/)
I'm getting the same issues in the same spots with this muxer.

[Trahald]

Try this one... it didnt make any difference in my output (since it worked fine already.) i commented out a line i shouldnt have.

patch http://pastebin.com/8ydDjMca
bin http://www.mediafire.com/?7bz33g9gwo6j94s

ill see if i can patch an older version if this doesnt work.

--> http://www.mediafire.com/?jc42t16540a03my this is r1784 which should be the or close to the apr14 revision kurtnoise did... it includes his patch and mine. only try this one if the above one doesnt do the trick for you.

[Lyle_JP]

Try this one... it didnt make any difference in my output (since it worked fine already.) i commented out a line i shouldnt have.

patch http://pastebin.com/8ydDjMca
bin http://www.mediafire.com/?7bz33g9gwo6j94s

ill see if i can patch an older version if this doesnt work.

--> http://www.mediafire.com/?jc42t16540a03my this is r1784 which should be the or close to the apr14 revision kurtnoise did... it includes his patch and mine. only try this one if the above one doesnt do the trick for you.

I would love to just try that first one, but Mediafire has not allowed me to download it since your initial post. I just get a "no server with that file available" message.

The second I was able to DL with no problem, and I will test it soon.

[Trahald]

http://rapidshare.com/files/416873096/MP4Box_r1988_2.zip try that

[b66pak]

on second look MP4Box_r1988 and MP4Box_r1988_2 lead to video corruption for me! (tested with a baseline stream)...

only this MP4Box_r1784_apr2010 don't have video corruption for me! (tested with a baseline stream)...
_

L.E. check this builds of MP4Box, pls... (http://komisar.gin.by/tools/)

this one is missing frames (62372 instead of 62414) so the audio is OOS...
_

[Trahald]

Ok so i need to go back a few revisions but maybe not april ;) can you make a sample available b66pak on medifire or something. i need to be able to duplicate so i can compile to newest possible version that still works. well also see if lyle_jp confirms.

[komisar]

MP4Box_0.4.6_5.x86_64.1.exe seems good (on http://komisar.gin.by/tools/ ). no?