x264 mp4 output borked (rev 295) (mkv fixed)

[Sirber]

Source: Simpsons episode
FPS: 29.97
Length: 22m57s

Result:
+ EBML head
+ Segment, size unknown
|+ Segment information
| + Muxing application: Haali Matroska Writer b0
| + Writing application: x264
| + Timecode scale: 50000
| + Duration: 214.781s (00:03:34.781450000)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 38
| + Default duration: 33.367ms (29.970 fps for a video track)
| + Video track
| + Pixel width: 640
| + Pixel height: 480
| + Display width: 4
| + Display height: 3
|+ Cluster

[Sharktooth]

does it b0rk for every 29.97fps source or just that one?
is the mp4 output ok or is it b0rked too?

[Sirber]

I changed my code (RealAnime 3.1) to use MKV output. Now testing MP4. It will takes some hours :(

I will post the source if MP4 fails too, or if someone wants it to test.

[Sirber]

fails. Using MP4 it crash. Same bug as the old one.

[Doom9]

exact source designation please? I have all Simpson R1 releases

[Sirber]

Source is tv rip, in AVI, 29.97 FPS.

[Revgen]

@Serber

Try using www.yousendit.com to send the file to either Sharktooth or whomever would be able to test it. They can handle files up to 1 GB to upload for free.

[Egh]

Hi!

MKV output is TOTALY b0rked in x264!!! Just WASTED WHOLE DAMN 18 HOURS of encoding!!! Thanx!!!!

Now YOU tell me what to do now. VIDEO stream is ok, but TIMECODES ARE TOTALLY B0RKED. IT IS NOT ONLY DURATION WHICH IS B0RKED!!!

Get the timecodes file from Rapidshare. And the ALL infromation saved by mkvextract.

See for you self how the blocks are b0rked, reference frame to -33ms, oh yeah...

Now the question is, is there ANY TOOL, which can simply change the timecodes into right ones? Like i have earlier same file encoded from vfw interface [with different settings though] (and muxed into mkv later of course). I can rip timecodes from that file, the question is how to include those into b0rked one?

Timecodes:

http://rapidshare.de/files/5036468/b0rked_timecodes___.zip.html

All information saved from mkvinfo:
http://rapidshare.de/files/5036509/b0rked_info.zip.html

P.S. x264 core:34 svn-292 was used, from MeGUI 2.2.4 automated 2-pass, if needed, i'll post which settings were used for x264 encoding.

[Sirber]

Hey dude, relax. Yelling won't get you anywhere, only brings troubles. No one owe you anything. :devil:

From the sticky you can read:This is not an official x264 build and may not work at all, destroy all the data on your hard drive or make your house or your dog explode (i doubt it can, though...). I'm not responsible for anything that could happen (i just checkout the SVN, apply some patches and compile the sources) - use it at your own risk.I lost a lot on time debugging x264, took me more than a week to discover the GPAC bug. The only solution for your problem is:

1) Reencode and output to raw h264
2) use avc2avi or mp4box to merge in another container.

[Egh]

Hey dude, relax. Yelling won't get you anywhere, only brings troubles.

From the sticky you can read:I lost a lot on time debugging x264, took me more than a week to discover the GPAC bug. The only solution for your problem is:

1) Reencode and output to raw h264
2) use avc2avi or mp4box to merge in another container.

iirc from my experience, mp4box support of h264 is quite b0rked too. And why t3h hell i need to use avc2avi if I can just use old good vfw interface from Virtual Dub??? If at least that is not broken in new build... (In 291 last time i checked it worked at least). And yet all developers yell that vfw mode is obsolete... In fact I don't deny this, but when other modes fail...

And reencode.. I *somehow* now feel like REencode will be done with REcode. Although it has issues, but NOT *THAT* KIND. And, although in this case it's not relevant (source is clean), nero avc at least doesn't create crazy blockness on noisy gradients, which x264 is keen on.

[Sirber]

And why t3h hell i need to use avc2avi if I can just use old good vfw interface from Virtual Dub???In case you never saw this, RealAnime uses CLI applications to do the job, and by CLI, I mean real manly CLI applications :angry: ;). It's the most elegant way to get things done.And reencode.. I *somehow* now feel like REencode will be done with REcode. Although it has issues, but NOT *THAT* KIND. And, although in this case it's not relevant (source is clean), nero avc at least doesn't create crazy blockness on noisy gradients, which x264 is keen on.No blocks here. What are your settings?

[movax]

The x264 VFW interface IMO shouldn't be used. Become friendly with the concept of commandline and CLI programs, and it'll help you a lot in the future.

[Sirber]

Yep, but until MPV and MP4 flaws are fixed, it's not better than VFW version :(

[movax]

Well, using the x264 CLI at least ensures that end users with the Nero Video decoder can view your content, as opposed to the VFW's borking it. :)

[Sirber]

well, if you convert your RAW to MP4, it's ok, but I don't do coz merging MP4 into MKV has issues. Prevent the extraction later.

[Egh]

In case you never saw this, RealAnime uses CLI applications to do the job, and by CLI, I mean real manly CLI applications :angry: ;). It's the most elegant way to get things done.No blocks here. What are your settings?

ask WHAT'S MY SOURCE.

In my case pretty much all noisy gradients in anime (skyline etc, fuzzy edges of spots and s on) give blocking. If source is clean, then no blocking.

Otherwise they are. In fact in that case in-loop deblocker tend to make things worse, so i turn it off. Better but still not perfect.

In *all* that cases nero avc was actually better. Not ideally, but noticably better. And ALL that cases were from real source (anime content) not some specially designed samples.

[Egh]

well, if you convert your RAW to MP4, it's ok, but I don't do coz merging MP4 into MKV has issues. Prevent the extraction later.

Imo it's convertion from .h264 to mp4 which is b0rked (although may depend on the actuall version used). Once you get it, there will be no problems with conversion to mkv and anything else.

[Egh]

The x264 VFW interface IMO shouldn't be used. Become friendly with the concept of commandline and CLI programs, and it'll help you a lot in the future.

Orly comrade?? And what t3h h3ll megui is??? Encoding, which was b0rked, was produced by MeGUI and x264.exe!! (not even mencoder)

And yet old g00d vfw interface produces at least not b0rked results :)

[Egh]

Well, using the x264 CLI at least ensures that end users with the Nero Video decoder can view your content, as opposed to the VFW's borking it. :)

So far using x264 cli ensures that NO ONE will be able to read it, unless hacking thru timecodes and changing them all in the file.

Damn, I wished Nero Recode had better setup for the avc codec, than i wouldn't use anything else. The quality of encoded material is not worse than x264 by all means, in not so rare cases -- slightly better.

[movax]

Four posts in a row?
Ok, for the purpose of this section of my post, let us define "bork" as "not being able to view using Nero's video decoder"
In this respect, x264 CLI doesn't produce borked files, x264 VFW interface does produce borked files.
Now let's change back to your original post...you complain that MKV output in x264 is borked. Ok. What can we do instead? Output to mp4 instead, and use mmg from Mosu's mkvtoolnix to mux in + timecodes, and we're set.

[foxyshadis]

Wow, you are one angry dude.

You don't have to use bleeding edge beta versions of software the day after they come out. Run thorough tests every upgrade and stick to a stable version for a few weeks if you can't handle betas. If you think recode is better, go ahead and use it, no one's going to stop you.

VFW has few supporters in the AVC world because it's easier to code for, and most standalones now and in the future will be play only raw mp4-ordered bitstreams. Of course, most will only play MP4 or MOV so that point is kind of moot if you use mkv.

Of course vfw would work, there's no timecodes to break. :p

If you have a constant framerate you can always generate a timecode file. All you need is to make a text file with:
# timecode format v1
Assume 29.970
Or whatever your framerate is. Add your video and the timecode into mkvmerge gui and poof, correct timecodes. You may not even need to do that if mmg recalculates timecodes anyway.

I've been blissfully ignorant of timecode problems because I mux my own in at the end, except for either megui or x264 deleting the first frame and throwing mine off if I don't compensate. :p

[Haali]

well, if you convert your RAW to MP4, it's ok, but I don't do coz merging MP4 into MKV has issues. Prevent the extraction later.
This is not true. mkvextract handles that.

[vidhead]

This is not true. mkvextract handles that.

mkvextract GUI 1.5.5 produced Track1.mp4 (it asked for extension and i typed mp4) from an mkv - an mp4 video muxed with mp3 audio using mkvmerge gui 1.5.5 or 1.5.4 created with MeGUI.

however, the extracted "mp4" is "light". the original mp4 is 314,174 kb. track1.mp4 is 313,905 kb.

mpc /haali media splitter reports Invalid first byte EBML ID:
and fails, mv2player fails, zoom player fails, vlc fails to play Track1.mp4

only mplayer/gui plays, with this output:
ID_VIDEO_ID=0
FPS seems to be: 23.976000
ID_FILENAME=V:\source\Track1.mp4
ID_DEMUXER=h264es <--??
ID_VIDEO_FORMAT=0x10000005 <-??
ID_VIDEO_BITRATE=0
ID_VIDEO_WIDTH=0 <--?
ID_VIDEO_HEIGHT=0 <--?
ID_VIDEO_FPS=23.976
ID_VIDEO_ASPECT=0.0000
ID_LENGTH=0.00 <--?

original output:
ID_FILENAME=V:\source\241082.mp4
ID_DEMUXER=mov
ID_VIDEO_FORMAT=avc1
ID_VIDEO_BITRATE=0
ID_VIDEO_WIDTH=640
ID_VIDEO_HEIGHT=368
ID_VIDEO_FPS=23.976
ID_VIDEO_ASPECT=0.0000
ID_LENGTH=2571.24

and when you "jump" the timeslider the picture looks like "liquid" distortions - static and moving - for a few seconds (until a complete scene change?)

when track1.mp4 is dropped on mkmerge 1.5.6 gui it rejects it with: file identification failed...return code 2...error...has unknown type.

[stephanV]

mkvextract outputs raw h264, not wrapped in mp4 (mentioned in the documentation BTW)... the distortions when seeking are due to not seeking to keyframes.

[Sirber]

This is not true. mkvextract handles that.Merging MP4 into MKV, you don't have a "Default duration" for the video track, so you can't extract :)

[Egh]

Wow, you are one angry dude.

You don't have to use bleeding edge beta versions of software the day after they come out. Run thorough tests every upgrade and stick to a stable version for a few weeks if you can't handle betas. If you think recode is better, go ahead and use it, no one's going to stop you.


In fact I was using Nero Recode for complicated sources, and that was good. Somehow I ask myself why I even came back to x264 now? The source was clean, so i thought that at least here it won't provide any complications... As if.... In fact the only problem of Nero is it's AVS support, or lack of thereof. Well, of course solution is encoding into lossless format and then feeding the avi into Nero. In fact l33t encoders do that, and I have too.


If you have a constant framerate you can always generate a timecode file. All you need is to make a text file with:
# timecode format v1
Assume 29.970
Or whatever your framerate is. Add your video and the timecode into mkvmerge gui and poof, correct timecodes. You may not even need to do that if mmg recalculates timecodes anyway.

Don't you tell me that. Before telling me this, you should have looked at timecodes and generally blocks information in the encoded mkv file. Links on rapidshare hosted file were posted previously. I can get zillions of timecode files, the actual problem is that it need to replace those *inside* the mkv. And if you suggesting ripping the h264 stream out of that mkv... Do you really think i didn't try this?? Of course it rips, only ripped stream is garbage at the end...

[Egh]

Merging MP4 into MKV, you don't have a "Default duration" for the video track, so you can't extract :)

Iirrc there's an option to set default duration for a track in mkvmerge.

[Sirber]

Do you really think i didn't try this?? Of course it rips
4) Be nice to each other and respect the moderator. Profanity and insults will not be tolerated. If you have a problem with another member turn to the respective moderator and if the moderator can't help you send a private message to Doom9.You were warned enougn...

[Sirber]

Iirrc there's an option to set default duration for a track in mkvmerge.It's better to have it done automaticly than having to set some crazy nanoseconds manually :)

[stephanV]

You dont need default duration to extract to raw h264...

[Sirber]

ok, here'e the full story:

Source: xvid and aac in MP4
1) Convert MP4 to MKV
2) Analyze MKV tracks
3) Extract tracks to .avi and .aac
--> fails

That's why RealAnime still doesn't have MP4 management. :)

[stephanV]

and xvid is related to h264 in what sense?

[Sirber]

I never spoken of h264 for that case. MP4 merged in MKV can't be extracted in AVI after. That was my point.

[movax]

It seems like there's a lot unnecessary craziness happening. If I was encoding an ep using Nero Recode, I'd either feed it the AVS directly, or in a Huffy/Lagarith/etc/etc, and end up with a mp4 containing my h264 video. Then, drop this in MMG + Audio, Subs, Chapters, Timecodes (if necessary), and you're set.

Going back to your first post on this thread, you're wondering if there's anyway to repair your borked x264 you outputted directly to MKV. In the time you've spent yelling on the board, you could have reencoded in Recode, muxed that mp4, and been done with it. :)

And IIRC, x264 CLI doesn't only output to MKV, also raw and mp4 (I think). So use those if you're averse to Recode for some reason. (Later versions do not crash for me, and some reports of its bugginess are overrated, though it doesn't like complex AVS scripts as much.)

[Sirber]

x264 MKV b0rkiness is the same for MP4. So only raw is avalible if MKV b0rk.

[SeeMoreDigital]

....The only solution for your problem is:

1) Reencode and output to raw h264
2) use avc2avi or mp4box to merge in another container.For those who may be interested..... I've recently been in contact with Alexander Noé regarding adding RAW H.264 stream support to AVI-Mux GUI, as his application already handles MPEG-4/AVC streams in .AVI and MKV.


Cheers

[Sirber]

AVC in AVI is not optimal... :(

[movax]

For those who may be interested..... I've recently been in contact with Alexander Noé regarding adding RAW H.264 stream support to AVI-Mux GUI, as his application already handles MPEG-4/AVC streams in .AVI and MKV.


Cheers

Yes...AVC in AVI is indeed extremely suboptimal. :(

[SeeMoreDigital]

Agreed..... AVC in AVI is not an optimum solution.... But AVI-mux GUI can generate MKV muxes too!

If it could accept RAW H.264 streams and save them to MKV, that's got to be useful ;)


Cheers

[Isochroma]

How about dividing x264 into two downloads, one a Stable version and the other an Experimental?

The stable version would advance until someone finds a bug, then it would be decremented to the previous one. Thus, people who want to use x264 in a production environment would be able to make a choice which would nearly guarantee them good output, and those who wanted to experiment with bleeding-edge features would have the option to do so as well.

So, we'll go thru this thread and all others in the MPEG-4 AVC subforum, and search for every bug reported on x264. Then, we'll pick the last version that has no bugs reported and post it as Stable.

[movax]

So, we'll go thru this thread and all others in the MPEG-4 AVC subforum, and search for every bug reported on x264. Then, we'll pick the last version that has no bugs reported and post it as Stable.

Good luck.

[Revgen]

So, we'll go thru this thread and all others in the MPEG-4 AVC subforum, and search for every bug reported on x264. Then, we'll pick the last version that has no bugs reported and post it as Stable.

There is no stable build.

If you look at this page (http://developers.videolan.org/x264.html) the developers make it quite clear that X264 is in "early development stage."

There really isn't a stable build yet. I don't believe there will be for quite awhile.

We just have to report the bugs to the developers and let them fix it until the program improves to the point where it can be considered stable.

[foxyshadis]

[Testing a few options in mkvmerge, had to edit out the post...]

Dammit, the message is not too short.

[foxyshadis]

There is no stable build.

If you look at this page (http://developers.videolan.org/x264.html) the developers make it quite clear that X264 is in "early development stage."

There really isn't a stable build yet. I don't believe there will be for quite awhile.

We just have to report the bugs to the developers and let them fix it until the program improves to the point where it can be considered stable.
Stable builds (not feature-stable) are builds that have undergone sufficient testing to be considered stable. The devs don't have extensive regression test suites or machines to handle them, so it'd probably be in everyone's best interest for someone to compile a suite that tests every feature, many combinations, some pathological samples, and put them up against a recent build that's been fairly reliable so far. Then you could have your stable build, as well as an automated bugtest suite.

The problem is finding someone with the time and computing power to do that.

[Chainmax]

Is this issue present in r291B?

[dbzgundam]

This problem sounds similar to mine.

I recently tried to encode an anime episode (and I plan to do the whole series, but right now that's pretty much at a stand still >>), through MeGUI X264 (292A) with MKV output... Using automated 2-Pass, I got some really weird results relating to duration (I tried ABR mode as well, but the same problem came up).

The video is about 23mins long in actuality, but when played back (Haali Splitter in MPC), it says 4:28... On top of this, if I position the video at about half way through or more, it will actually go more than half way through the episode (well past the half way point actually). Once the bar reaches 4:28, it attempts to speed through the rest of the video until it ultimately freezes.

I tried the suggestion posted earlier about using timecodes; but to no avail. All this does is "stabilize" the 4:28 of footage. In other words, it works as it should, with no navigation problems, but only up to 4:28.

[Revgen]

Stable builds (not feature-stable) are builds that have undergone sufficient testing to be considered stable. The devs don't have extensive regression test suites or machines to handle them, so it'd probably be in everyone's best interest for someone to compile a suite that tests every feature, many combinations, some pathological samples, and put them up against a recent build that's been fairly reliable so far. Then you could have your stable build, as well as an automated bugtest suite.

The problem is finding someone with the time and computing power to do that.

Okay, so you're thinking that we should have a "Doom9 Community Certified" stable build?

Would this involve Doom9 members using this software to test certain clips on their machines?

If so, then it's an interesting idea.

[Sharktooth]

BS. x264 is in EARLY DEVELOPMENT and cant be tagged as STABLE.
Consider it as an alpha software or maybe even pre-alpha.

[nm]

BS. x264 is in EARLY DEVELOPMENT and cant be tagget as STABLE.
Consider it as an alpha software or maybe even pre-alpha.
Well, developers are usually a bit reluctant to make stable releases at all. So-called stability is more about public image and marketing, which technical people are not very interested in. Just read the discussion about releases on ffmpeg developers mailing list ;) This point of view is understandable, as it is easy to say the software is just not yet stable, when people come complaining about their problems.

There are countless examples of commercial and free programs that are released as stable, full-featured software, but actually have much more problems and bugs than x264 for example. I think stability is a matter of opinion, and if some of the bugs that people have found recently in x264 or its output handling are fixed, it could easily be called stable even if the developers are not willing to do it themselves (not that I would encourage it without their consent). Foxyshadis' idea of a test suite is also very good.

[movax]

BS. x264 is in EARLY DEVELOPMENT and cant be tagged as STABLE.
Consider it as an alpha software or maybe even pre-alpha.

Exactly. ^_^ You could only make a stable alpha, which is basically an oxymoron. Of course, you can keep track of what builds/revs have the least quirks. :)