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/b...es___.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.

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]

Originally Posted by Sirber

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]

Originally Posted by Egh

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 . 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?

[Egh]

Originally Posted by Sirber

In case you never saw this, RealAnime uses CLI applications to do the job, and by CLI, I mean real manly CLI applications . 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.

[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.

[Egh]

Originally Posted by 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.

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

[SeeMoreDigital]

Originally Posted by Sirber

....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

[movax]

Originally Posted by SeeMoreDigital

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.

[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.

[Egh]

Originally Posted by 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.

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.