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

[Sirber]

Builds change everyday, and experimental / testing code is added. Nothing is stable, and it has never been...

[nm]

Builds change everyday, and experimental / testing code is added. Nothing is stable, and it has never been...
New and even experimental features are constantly added to the Linux kernel 2.6 series, and still every once in a while a "stable" release has been made. Some releases have even contained very serious bugs, but then people have just waited for the next release where the problem has been fixed. What I am saying is that it is not impossible to tag an x264 release as a stable one even in a short timeframe. It would just require some commitment to fix the most pressing problems. Perhaps it would not make any significant difference to people who constantly use bleeding edge stuff, but others would be comforted if they were told that the code is not expected to destroy the machine any moment ;)

[Sirber]

Before 2.6 was 2.5 which was "dev", testing, whatever. x264 is more near 0.1 ;)

[nm]

Before 2.6 was 2.5 which was "dev", testing, whatever. x264 is more near 0.1 ;)
Yes, but nowadays all kernel development happens in the stable 2.6 series with a release tagged now and then. Of course there are preparations for a release so that there are no known problems -- at least big ones. Every developer has their own taste on version numbering and if x264 was a commercial program combined with some fancy GUI, it could already be considered 1.0 beta by the marketing department.

Btw, if you are interested in a good discussion about similar release issues, see this thread: http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/002978.html

[foxyshadis]

Calling x264 unstable pre-alpha is disingenuous; we've all used and tested it extensively, if not especially thoroughly, especially the newest and most demanding options. Very little has changed since springtime, mostly optimizations, point additions, and minor bugfixes - not the sweeping changes unstable alphas imply. The core has been very stable, the latest additions rarely causing much angst when people don't use them.

While individual builds may be unstable, there've been a number recently that have been stable with relatively minor bugs (like blue-sky blocking) in between new feature additions, that have been hammered on by all the people slowly coming from xvid/divx. When was the last critical bug like this that x264 had? I can't remember any since its CQM code stabilized.

I think that's one of the reasons why "Will x264 encodes still be compatible in the future" questions keep popping up. If a .5 version was out there well-tested and assured to be "fully compatible with mpeg4 avc hardware and software" it would also get a lot more exposure from people who think it'll just crash or corrupt stuff if they encode or play with it, compared to xvid, recode, or qt. (That was my impression before I spent the time to research and test a build.) That's why vorbis still turns out a well-tested 1.1.1 even though the aotuv tunings are ongoing and potentially disruptive.

[Sharktooth]

What dont you understand about the words "EARLY" and "DEVELOPMENT"?
x264 IS NOT stable. Tagging as STABLE a software that is in heavy development, feature incomplete, subject to everyday and big changes in the code, that doesnt yet comply with some specs (for example the mod 16 resolution thing), that needs libs from other beta softwares (GPAC), has bugs, etc... is not possible unless you (the devs) want to make fool of yourself.
Stop this "stable here, stable there" discussion. I repeat myself x264 IS NOT STABLE and the most appropriate tagging would be ALPHA or even PRE-ALPHA.
You should thank all the devs (expecially pengvado) that are working on the project coz they do it for free.
Asking for "the impossible" is one way to kill the entusiasm of developing an open source software.

However, this discussion is completely off topic. A thread splitting is needed.

EDIT: "Daily builds service" is over. Thanks.

[pgb]

@Sharktooth - thanks for your efforts in providing daily builds up till now, they have been much appreciated by those of us interested in the development of this exciting new codec. I'm sorry you've felt unappreciated or misunderstood - I hope that you'll continue to contribute: your efforts are valued.

[Doom9]

what's so wrong with keeping releases you download.. if you go up one revision and something doesn't work out, you can go back. At least the mp4 output relies on external libraries and unless prove it's the x264 developer's fault, bitching is extremely rude. I know from personal experience with MeGUI that it is the exact opposite of motivating if someobdy calls your app buggy (there's no bug until you can reproduce reliably on different setups and put the finger on the option that cause it - before that it's a problem and that could just as well be the user's fault) when in fact the problem lies elsewhere (many times it's quite apparent that your app is not to blame, but negative reports shed a bad light on your work and may discourage potential users from using it.. and all that not because there's anything wrong with your work, but because somebody else tries to blame you for their own problems).

[nm]

I sense some misunderstandings in this thread. Yes, at first there were some posts with a bad attitude, but I think the suggestions made by other people were completely constructive and encouraging. Nobody is demanding anything. Just read the posts without your deflector shields up ;)
As I see it, people would just like to have a release with a proper version number that reflects the state of x264. Fact is that for me and many others it works perfectly, and we would be delighted to see new people come and discover it too. Maybe it should not be called "stable" if that word causes too much headache, but like foxyshadis said, a number like 0.5 would tell that x264 can already be used productively.
And as to what Doom9 said about keeping a few downloaded releases in storage ourselves,
again, it works for us (personally I'm completely satisfied with the SVN repository), but not for new people who don't have the enthusiasm to test software in "early development".

[Doom9]

well.. if you want something stable, user Recode. Forget version numbers, they don't matter at all. Interesting link you posted about ffdshow but on one account I have to disagree: it shouldn't be about version numbers but about APIs. Open source's biggest headache is ever changing APIs, and that's the strongest plus when you develp for Windows or MacOS - they offer stable and slowly changing APIs.. no patch will break the API, and SP2 was the first time Microsoft (iirc) changed APIs (and only a few) in between new Windows releases. If you keep APIs stable and just change the underlying code, a lot of third party developer headaches go away - it does make the life a bit harder for the developers at the core, but that's where good design comes in.. the more you sat down and did some proper design before implementation, the less need there is to change the API mid-stream. And then there's the interface abstraction where you can use versioning for the interfaces, so you can keep the old ones around for apps that still require them, and expose new features in an updated interface.

I recall the entire stable / unstable discussion for XviD, and to this day, there is but one stable version, yet does that stop people from using anything else? Is anything in x264 broken at this point? I sincerely doubt so. I have never been able to reproduce the container problems people keep bitching about, so that does make me very sucpisious that the problem is between the screen and the chair and not in the software. More so that to this day, nobody has been able to produce a method to reliably reproduce this behavior. I realize this is not always possible, but all I'm seeing here is "it doesn't work, fix it" and no "I tried this, that turned a switch here, tested on different machines, etc, etc".. and I'm afraid that's part of things as well.. and not only for free software. I often find myself experimenting in the lab at work trying to reproduce a certain problem as my employer has to pay when I start filing cases that turn out not to be the manufacturers fault.

[Sirber]

Is anything in x264 broken at this point? I sincerely doubt so.If you look page 1 and 2, you will read that MP4 and MKV can fail for 23.976FPS and 29.97FPS source.

[nm]

well.. if you want something stable, user Recode. Forget version numbers, they don't matter at all.They don't matter to people like us, but I know they matter to others: people who would just like to encode their home videos, their all-knowing friends, journalists, etc.

Interesting link you posted about ffdshow but on one account I have to disagree: it shouldn't be about version numbers but about APIs.True. I gave the link because I recall that further down the thread there was discussion about non-core-developers doing the releases. Some nice and perhaps even working suggestions if someone wants to come up and do it for x264.

I recall the entire stable / unstable discussion for XviD, and to this day, there is but one stable version, yet does that stop people from using anything else? Is anything in x264 broken at this point? I sincerely doubt so.Exactly. That's the point I tried to make calling x264 "stable" and ready for wide usage, even though formally there is no stable release. I also think it is perfectly possible to make one.

[Doom9]

can fail for 23.976FPS and 29.97FPS source.keyword being can.. it works fine here, always has. And since neither you or anybody else can provide a reproducible scenario (has anybody ever tested on another machine?), I'm tending towards the chair problem.. Sharktooth has also never been able to figure out any problems with his builds. So, the proper course of action here is to find a reproducible scenario.. it takes no wizard for that, just patience and the will to make lots of experiments. This should be part of the equation with free software.. your part is to fail, figure out why it fails and tell the developer so they can fix it. You, writing software on your own, should be very familiar and I'm sure you treat "it doesn't work, fix it" reports with as enthusiasm as every other developer.

[Sharktooth]

The problem seems to be in some sources (and i havent them to test it). However if my builds do not work for you, try celtic druid's or bobor's builds and see if they fix it.
I'm pretty convinced that they wont though... and however encoding to raw stream seems to fix it.
So, whatever it is, it does not depend on the x264 core.

[Sirber]

My thread was a fellow up of my older thread where I found that bug to confirm the latest GPAC changes didn't resolve the problem.

My source: http://www.detritus.qc.ca/files/x264_fails_mp4.avi (143MB)
Please download only if you wanna test, not for fun.

[Doom9]

I encoded a full 2+ h movie at 23.976 and a simpsons episode at 29.97fps using Sharktooth's latest build, with no problems whatsoever.
@sirber: is this THE one that causes problems, or one of many?

[Sirber]

one of the many I tested recently.

[Doom9]

well.. at the speeds your server offers, and since it's unable to resume, I suggest you cut away a bit ;)

[Sirber]

Apache is supposed to offer resume :confused:. About the speed, I'm hosting myself in the confort of my living room :)

[Doom9]

well..I'm not getting anywhere with this so I'm afraid I can't test

[stephanV]

eerrr... maybe you could consider uploading about 50 MB to savefile.com or something. (if it happens with such a part)

I don't feel like downloading 134 MB at 3 kB/s and i had to restart 2 times already too since it just hung :(

[Sirber]

Hum... where could I save it? fully?

[foxyshadis]

I'm sorry, sharktooth, I didn't mean to imply that x264 was stable in the sense of needing a trunk/branch system, or that its APIs or command line should be frozen. Stable's too loaded, maybe just "safe". Using it you're sure it won't crash or give bad output on known tested configs, but it's not safe to consider api or command or feature stable in any way. Maybe it is too early for that just because bug reports are coming in.

Although I suspect that whatever version is bundled with gordian knot will be the most popular by far, regardless of its safety or lack thereof.

[SeeMoreDigital]

Apache is supposed to offer resume :confused:. About the speed, I'm hosting myself in the confort of my living room :)I host my web site and some of its smaller files on a PC at my home, using Apache.

As a matter of interest, what's the up-link speed of your ISP connection?


Cheers

[stephanV]

Hum... where could I save it? fully?
Uhm, maybe you could shorten the sample?

Otherwise, make it a split archive of 3 parts and upload those 3 files seperately (e.g. RAR and 7z support making split archives)

www.savefilecom.com (60 MB per file, no registering, etc, etc, pretty handy)

[Sirber]

around 600kbps.

[SeeMoreDigital]

That's quite high...

In the UK British Telecom (BT) offer 256Kb up-link speeds for ADSL and NTL offer around 200Kb...


Cheers

[Sirber]

It's maybe high, but it's highly in use :D

[stephanV]

Ok, I finally managed to download the file.

I used this avs script
avisource("e:\downloads\x264_fails_mp4.avi")
I used x264 292 from Sharktooth with this command line:
x264 -B 500 -b 3 --b-pyramid -r 3 --me dia --subme 3 --progress -o test.mp4 x264_fails_mp4.avs
(--me dia --subme 3 to speed things up a bit)

BUT

no crash: file plays fine, seeks fine, muxes fine to mkv, which again plays fine and seeks fine...

There was however one oddity though (which ive seen and mentioned before), and that is x264 output
avis [info]: 512x384 @ 29.97 fps (41294 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 200 (scale 2997)
x264 [info]: slice I:376 Avg QP:22.25 Avg size: 15006 PSNR Mean Y:46.21 U:47.23 V:48.22 Avg:46.60 Global:45.76
x264 [info]: slice P:22980 Avg QP:24.80 Avg size: 3053 PSNR Mean Y:42.41 U:43.38 V:44.51 Avg:42.82 Global:42.10
x264 [info]: slice B:17938 Avg QP:25.62 Avg size: 532 PSNR Mean Y:43.56 U:44.24 V:45.42 Avg:43.89 Global:43.13
x264 [info]: slice I Avg I4x4:52.3% I8x8:0.0% I16x16:47.7%
x264 [info]: slice P Avg I4x4:3.3% I8x8:0.0% I16x16:6.2% P:38.8% P8x8:2.1% PSKIP:49.6%
x264 [info]: slice B Avg I4x4:0.2% I8x8:0.0% I16x16:0.2% P:15.9% B:2.0% B8x8:0.5% DIRECT:2.7% BSKIP:78.6%
x264 [info]: PSNR Mean Y:42.95 U:43.79 V:44.94 Avg:43.32 Global:42.54 kb/s:495.5

encoded 41294 frames, 17.70 fps, -12360.73 kb/s
That is about the only thing I can find that is odd.

I'm awaiting for different settings to try, but will check the mkv output right away now anyway.

[Sirber]

I removed the file, my bandwith left me :(

Maybe my splitter doesn't like it. I'll double check my versions.

[SeeMoreDigital]

I removed the file, my bandwith left me :(

Maybe my splitter doesn't like it. I'll double check my versions.Yep... just as I reached 51% :eek:


Cheers

[stephanV]

I can upload it as splitted archive at savefile.com if anyone is interested

[Sirber]

sorry, I will make a small version soon.

[stephanV]

Some more results:

for mkv output:
x264 -B 500 -b 3 --b-pyramid -r 3 --me dia --subme 3 --progress -o test.mkv x264_fails_mp4.avs

avis [info]: 512x384 @ 29.97 fps (41294 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:376 Avg QP:22.25 Avg size: 15006 PSNR Mean Y:46.21 U:47.23 V:48.22 Avg:46.60 Global:45.76
x264 [info]: slice P:22980 Avg QP:24.80 Avg size: 3053 PSNR Mean Y:42.41 U:43.38 V:44.51 Avg:42.82 Global:42.10
x264 [info]: slice B:17938 Avg QP:25.62 Avg size: 532 PSNR Mean Y:43.56 U:44.24 V:45.42 Avg:43.89 Global:43.13
x264 [info]: slice I Avg I4x4:52.3% I8x8:0.0% I16x16:47.7%
x264 [info]: slice P Avg I4x4:3.3% I8x8:0.0% I16x16:6.2% P:38.8% P8x8:2.1% PSKIP:49.6%
x264 [info]: slice B Avg I4x4:0.2% I8x8:0.0% I16x16:0.2% P:15.9% B:2.0% B8x8:0.5% DIRECT:2.7% BSKIP:78.6%
x264 [info]: PSNR Mean Y:42.95 U:43.79 V:44.94 Avg:43.32 Global:42.54 kb/s:495.5

encoded 41294 frames, 17.59 fps, -12360.73 kb/s

Again, plays fine.

for raw output:
x264 -B 500 -b 3 --b-pyramid -r 3 --me dia --subme 3 --progress -o test.264 x264_fails_mp4.avs

avis [info]: 512x384 @ 29.97 fps (41294 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:376 Avg QP:22.25 Avg size: 15006 PSNR Mean Y:46.21 U:47.23 V:48.22 Avg:46.60 Global:45.76
x264 [info]: slice P:22980 Avg QP:24.80 Avg size: 3053 PSNR Mean Y:42.41 U:43.38 V:44.51 Avg:42.82 Global:42.10
x264 [info]: slice B:17938 Avg QP:25.62 Avg size: 532 PSNR Mean Y:43.56 U:44.24 V:45.42 Avg:43.89 Global:43.13
x264 [info]: slice I Avg I4x4:52.3% I8x8:0.0% I16x16:47.7%
x264 [info]: slice P Avg I4x4:3.3% I8x8:0.0% I16x16:6.2% P:38.8% P8x8:2.1% PSKIP:49.6%
x264 [info]: slice B Avg I4x4:0.2% I8x8:0.0% I16x16:0.2% P:15.9% B:2.0% B8x8:0.5% DIRECT:2.7% BSKIP:78.6%
x264 [info]: PSNR Mean Y:42.95 U:43.79 V:44.94 Avg:43.32 Global:42.54 kb/s:495.5

encoded 41294 frames, 17.49 fps, -12360.73 kb/s

And this plays fine too.

So the only odd thing is the reported bit rate, but this happens for all three outputs so it would go a bit far to blame that on MP4 or MKV output right away.

[Sirber]

can I have your file? I'll check if it works down here :)

[stephanV]

mp4, mkv or 264?

[Sirber]

mp4. 264 always worked for me (for later muxing).

[stephanV]

split archive part 1 --> http://rapidshare.de/files/5176138/test_x264_mp4.7z.001.html
split archive part 2 --> http://rapidshare.de/files/5176466/test_x264_mp4.7z.002.html

[SeeMoreDigital]

Unfortunately "RapidShare" is no good for me as they always want me to sign up for their Premium account: -

http://img289.imageshack.us/img289/7081/rapidshare9dx.png


Cheers

[stephanV]

Just click free and wait for the counter to reach 0... thats all i can say.

[Sirber]

getting them...

[edit]

I have Haali splitter jun 15 2005.

[edit 2]

You (66.36.133.150) have requested 47185 KB in one hour. Want to download more?
Get your PREMIUM-Account now! Many advantages! Instant access!

:(

[stephanV]

mirror for part1 --> http://savefile.com/files.php?fid=4288999
mirror for part2 --> http://savefile.com/files.php?fid=8663147

@sirber, thats too old... update it... ffdshow possibly too while your at it.

[IgorC]

Use anonyme surf http://www.anonymsurfen.com/surfen.htm :p

[Sirber]

I reinstalled Haali with MP4 support. I made a test from 500 frames from the source and it playback fine. I will try with realanime. MKV play ok too. Was it a "code 18" from the start? :devil:

[Sirber]

seems to work #1 now. I'm lost.

[Sirber]

Seems the producer MKV cannot be remerged:
mkvmerge v1.5.6 ('Breathe me') built on Sep 7 2005 18:18:02
'C:\Program Files\RealAnime\temp\0.mkv': Using the Matroska demultiplexer.
'C:\Program Files\RealAnime\temp\out_aud.1.rm': Using the RealMedia demultiplexer.
'C:\Program Files\RealAnime\temp\0.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
'C:\Program Files\RealAnime\temp\out_aud.1.rm' track 0: Using the AAC output module (FourCC: racp).
The file 'C:\Program Files\RealAnime\temp\02.mkv' has been opened for writing.
'die' called: bref_packet == NULL. Wanted bref: 7714800. Contents of the queue:
Packet 0, timecode -492364800, bref -659364800, fref -1
Packet 1, timecode -576364800, bref -492364800, fref -1
Packet 2, timecode -618364800, bref -492364800, fref -1
Packet 3, timecode -534364800, bref -492364800, fref -1
Packet 4, timecode -474364800, bref -1, fref -1
Packet 5, timecode -428364800, bref -1, fref -1
Packet 6, timecode -381364800, bref -1, fref -1
Packet 7, timecode -335364800, bref -1, fref -1
Packet 8, timecode -326364800, bref -492364800, fref -1
Packet 9, timecode -409364800, bref -326364800, fref -1
Packet 10, timecode -451364800, bref -326364800, fref -1
Packet 11, timecode -367364800, bref -326364800, fref -1
Packet 12, timecode -288364800, bref -1, fref -1
Packet 13, timecode -242364800, bref -1, fref -1
Packet 14, timecode -196364800, bref -1, fref -1
Packet 15, timecode -159364800, bref -326364800, fref -1
Packet 16, timecode -242364800, bref -159364800, fref -1
Packet 17, timecode -284364800, bref -159364800, fref -1
Packet 18, timecode -201364800, bref -159364800, fref -1
Packet 19, timecode -149364800, bref -1, fref -1
Packet 20, timecode -103364800, bref -1, fref -1
Packet 21, timecode -75364800, bref 7714800, fref -1
Packet 22, timecode -117364800, bref -75364800, fref -1
Packet 23, timecode -56364800, bref -1, fref -1
Packet 24, timecode -34364800, bref -75364800, fref -1
Packet 25, timecode 99000000, bref -109750000, fref -1
Packet 26, timecode 15000000, bref 99000000, fref -1
Packet 27, timecode 57000000, bref -26350000, fref -1
Packet 28, timecode 266000000, bref 57000000, fref -1
Packet 29, timecode 182000000, bref 266000000, fref -1
Packet 30, timecode 140000000, bref 266000000, fref -1
Packet 31, timecode 224000000, bref 266000000, fref -1
Packet 32, timecode 432000000, bref 266000000, fref -1
Packet 33, timecode 349000000, bref 432000000, fref -1
Packet 34, timecode 307000000, bref 432000000, fref -1
Packet 35, timecode 391000000, bref 432000000, fref -1
Packet 36, timecode 599000000, bref 432000000, fref -1
Packet 37, timecode 516000000, bref 599000000, fref -1
Packet 38, timecode 474000000, bref 599000000, fref -1
Packet 39, timecode 558000000, bref 599000000, fref -1
Packet 40, timecode 766000000, bref 599000000, fref -1
Packet 41, timecode 683000000, bref 766000000, fref -1
Packet 42, timecode 641000000, bref 766000000, fref -1
Packet 43, timecode 724000000, bref 766000000, fref -1
Packet 44, timecode 933000000, bref 766000000, fref -1
Packet 45, timecode 850000000, bref 933000000, fref -1
Packet 46, timecode 808000000, bref 933000000, fref -1
Packet 47, timecode 891000000, bref 933000000, fref -1
Packet 48, timecode 1100000000, bref 933000000, fref -1
Packet 49, timecode 1016000000, bref 1100000000, fref -1
Packet 50, timecode 975000000, bref 1100000000, fref -1
Packet 51, timecode 1058000000, bref 1100000000, fref -1
Packet 52, timecode 1267000000, bref 1100000000, fref -1
Packet 53, timecode 1183000000, bref 1267000000, fref -1
Packet 54, timecode 1141000000, bref 1267000000, fref -1
Packet 55, timecode 1225000000, bref 1267000000, fref -1
Packet 56, timecode 1392000000, bref 1267000000, fref -1
Packet 57, timecode 1350000000, bref 1392000000, fref -1
Packet 58, timecode 1308000000, bref 1392000000, fref -1
Packet 59, timecode 1475000000, bref 1392000000, fref -1
Packet 60, timecode 1433000000, bref 1475000000, fref -1
Packet 61, timecode 1559000000, bref 1475000000, fref -1
Packet 62, timecode 1517000000, bref 1559000000, fref -1
Packet 63, timecode 1600000000, bref 1559000000, fref -1
Packet 64, timecode 1725000000, bref 1600000000, fref -1
Packet 65, timecode 1684000000, bref 1725000000, fref -1
Packet 66, timecode 1642000000, bref 1725000000, fref -1
Packet 67, timecode 1892000000, bref 1725000000, fref -1
Packet 68, timecode 1809000000, bref 1892000000, fref -1
Packet 69, timecode 1767000000, bref 1892000000, fref -1
Packet 70, timecode 1851000000, bref 1892000000, fref -1
Packet 71, timecode 2017000000, bref 1892000000, fref -1
Packet 72, timecode 1976000000, bref 2017000000, fref -1
Packet 73, timecode 1934000000, bref 2017000000, fref -1
Packet 74, timecode 2101000000, bref 2017000000, fref -1
Packet 75, timecode 2059000000, bref 2101000000, fref -1
Packet 76, timecode -2068967296, bref 2101000000, fref -1
Packet 77, timecode -2110967296, bref -2068967296, fref -1
Packet 78, timecode 2142000000, bref -2068967296, fref -1
Packet 79, timecode -1943967296, bref -2068967296, fref -1
Packet 80, timecode -1985967296, bref -1943967296, fref -1
Packet 81, timecode -2026967296, bref -1943967296, fref -1
Packet 82, timecode -1776967296, bref -1943967296, fref -1
Packet 83, timecode -1860967296, bref -1776967296, fref -1
Packet 84, timecode -1901967296, bref -1776967296, fref -1
Packet 85, timecode -1818967296, bref -1776967296, fref -1
Packet 86, timecode -1609967296, bref -1776967296, fref -1
Packet 87, timecode -1693967296, bref -1609967296, fref -1
Packet 88, timecode -1734967296, bref -1609967296, fref -1
Packet 89, timecode -1651967296, bref -1609967296, fref -1
Packet 90, timecode -1442967296, bref -1609967296, fref -1
Packet 91, timecode -1526967296, bref -1442967296, fref -1
Packet 92, timecode -1568967296, bref -1442967296, fref -1
Packet 93, timecode -1484967296, bref -1442967296, fref -1
Packet 94, timecode -1317967296, bref -1442967296, fref -1
Packet 95, timecode -1359967296, bref -1317967296, fref -1
Packet 96, timecode -1401967296, bref -1317967296, fref -1
Packet 97, timecode -1276967296, bref -1, fref -1
Packet 98, timecode -1109967296, bref -1276967296, fref -1
Packet 99, timecode -1192967296, bref -1109967296, fref -1
Packet 100, timecode -1234967296, bref -1109967296, fref -1
Packet 101, timecode -1151967296, bref -1109967296, fref -1
Packet 102, timecode -942967296, bref -1109967296, fref -1
Packet 103, timecode -1025967296, bref -942967296, fref -1
Packet 104, timecode -1067967296, bref -942967296, fref -1
Packet 105, timecode -984967296, bref -942967296, fref -1
Packet 106, timecode -775967296, bref -942967296, fref -1
Packet 107, timecode -859967296, bref -775967296, fref -1
Packet 108, timecode -900967296, bref -775967296, fref -1
Packet 109, timecode -817967296, bref -775967296, fref -1
Packet 110, timecode -608967296, bref -775967296, fref -1
Packet 111, timecode -692967296, bref -608967296, fref -1
Packet 112, timecode -733967296, bref -608967296, fref -1
Packet 113, timecode -650967296, bref -608967296, fref -1
Packet 114, timecode -441967296, bref -608967296, fref -1
Packet 115, timecode -525967296, bref -441967296, fref -1
Packet 116, timecode -567967296, bref -441967296, fref -1
Packet 117, timecode -483967296, bref -441967296, fref -1
Packet 118, timecode -316967296, bref -441967296, fref -1
Packet 119, timecode -358967296, bref -316967296, fref -1
Packet 120, timecode -400967296, bref -316967296, fref -1
Packet 121, timecode -275967296, bref -316967296, fref -1
Packet 122, timecode -150967296, bref -275967296, fref -1
Packet 123, timecode -191967296, bref -150967296, fref -1
Packet 124, timecode -233967296, bref -150967296, fref -1
Packet 125, timecode -108967296, bref -150967296, fref -1
Packet 126, timecode -66967296, bref -108967296, fref -1
Packet 127, timecode -24967296, bref -66967296, fref -1
Packet 128, timecode 100032704, bref -24967296, fref -1
Packet 129, timecode 58032704, bref 100032704, fref -1
Packet 130, timecode 16032704, bref 100032704, fref -1
Packet 131, timecode 141032704, bref 100032704, fref -1
Packet 132, timecode 183032704, bref 141032704, fref -1
Packet 133, timecode 225032704, bref 183032704, fref -1
Packet 134, timecode 267032704, bref 225032704, fref -1
Packet 135, timecode 308032704, bref 267032704, fref -1
Packet 136, timecode 350032704, bref 308032704, fref -1
Packet 137, timecode 392032704, bref 350032704, fref -1
Packet 138, timecode 433032704, bref 392032704, fref -1
Packet 139, timecode 517032704, bref 433032704, fref -1
Packet 140, timecode 475032704, bref 517032704, fref -1
Packet 141, timecode 559032704, bref 517032704, fref -1
Packet 142, timecode 600032704, bref 559032704, fref -1
Packet 143, timecode 642032704, bref 600032704, fref -1
Packet 144, timecode 767032704, bref 642032704, fref -1
Packet 145, timecode 725032704, bref 767032704, fref -1
Packet 146, timecode 684032704, bref 767032704, fref -1
Packet 147, timecode 809032704, bref 767032704, fref -1
Packet 148, timecode 850032704, bref 809032704, fref -1
Packet 149, timecode 892032704, bref 850032704, fref -1
Packet 150, timecode 934032704, bref 892032704, fref -1
Packet 151, timecode 976032704, bref 934032704, fref -1
Packet 152, timecode 1142032704, bref 976032704, fref -1
Packet 153, timecode 1059032704, bref 1142032704, fref -1
Packet 154, timecode 1017032704, bref 1142032704, fref -1
Packet 155, timecode 1101032704, bref 1142032704, fref -1
Packet 156, timecode 1309032704, bref 1142032704, fref -1
Packet 157, timecode 1226032704, bref 1309032704, fref -1
Packet 158, timecode 1184032704, bref 1309032704, fref -1
Packet 159, timecode 1268032704, bref 1309032704, fref -1
Packet 160, timecode 1434032704, bref 1309032704, fref -1
Packet 161, timecode 1393032704, bref 1434032704, fref -1
Packet 162, timecode 1351032704, bref 1434032704, fref -1
Packet 163, timecode 1476032704, bref 1434032704, fref -1
Packet 164, timecode 1560032704, bref 1476032704, fref -1
Packet 165, timecode 1518032704, bref 1560032704, fref -1
Packet 166, timecode 1685032704, bref 1560032704, fref -1
Packet 167, timecode 1643032704, bref 1685032704, fref -1
Packet 168, timecode 1601032704, bref 1685032704, fref -1
Packet 169, timecode 1726032704, bref 1685032704, fref -1
Packet 170, timecode 1768032704, bref 1726032704, fref -1
Packet 171, timecode 1810032704, bref 1768032704, fref -1
Packet 172, timecode 1851032704, bref 1810032704, fref -1
Packet 173, timecode 1893032704, bref 1851032704, fref -1
Packet 174, timecode 1935032704, bref 1893032704, fref -1
Packet 175, timecode 1977032704, bref 1935032704, fref -1
Packet 176, timecode 2018032704, bref 1977032704, fref -1
Packet 177, timecode 2060032704, bref 2018032704, fref -1
Packet 178, timecode 2102032704, bref 2060032704, fref -1
Packet 179, timecode 2143032704, bref 2102032704, fref -1
Packet 180, timecode -2025934592, bref 2143032704, fref -1
Packet 181, timecode -2067934592, bref -2025934592, fref -1
Packet 182, timecode -2109934592, bref -2025934592, fref -1
Packet 183, timecode -1859934592, bref -2025934592, fref -1
Packet 184, timecode -1942934592, bref -1859934592, fref -1
Packet 185, timecode -1984934592, bref -1859934592, fref -1
...
Packet 499, timecode -1731836480, bref -1689836480, fref -1
Packet 500, timecode -1647836480, bref -1689836480, fref -1
Packet 501, timecode -1606836480, bref -1647836480, fref -1
Packet 502, timecode -1522836480, bref -1606836480, fref -1P

[MeteorRain]

hey, do you guys need a x264-in-mp4 broken file?

it can't play on my computer!

===================================

http://webhd.xuite.net/

at left, logon with
user: msg7086
pass: 3.1415926

and you'll see the filelist

click the file [POPGO][hikaru_no_go][DVDRIP][15].part1.rar and part2 and fill in the verify code, you can download them easily.

[Sirber]

Output MKV merged to MKV fails
Output MP4 merged to MP4 works but crash on playback

[stephanV]

@Sirber: what are you talking about? You really have to be more clear on what you are doing...

[Sirber]

(x264 --> raw) --> avi --> mkv = success
(x264 --> mkv) --> mkv = fail
(x264 --> mp4) --> mkv = fail

(x264 --> mkv) = play #1
(x264 --> mp4) = unknown

I merge to mkv at end to add audio streams.

[stephanV]

No problems with that here...

[Doom9]

(x264 --> mp4) --> mkv = failThis works like a charm over here, using Sharktooth's 292a build and mkvtoolnix 1.5.6. It sounds more and more like a problem at your end with each test somebody else makes ;)

[MeteorRain]

Hey, did anyone test my sample?

and i met more problems now:

i compressed a lot of avi files, simply using avisource. x264 just compressed about half of the file, and stopped and said successfully compressed but the result file is obviously completely broken.

all jobs failed except only one works.......

see attachment for avs&log

[Sirber]

This works like a charm over here, using Sharktooth's 292a build and mkvtoolnix 1.5.6. It sounds more and more like a problem at your end with each test somebody else makes ;)Well, I don't get it. I'm using all latest builds and it fails. MPC dies on me.

+ EBML head
+ Segment, size 108949416
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4027)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v0.7.5 + libmatroska v0.7.7
| + Writing application: mkvmerge v1.5.6 ('Breathe me') built on Sep 7 2005 18:18:22
| + Duration: 1731.512s (00:28:51.512000000)
| + Date: Sat Sep 17 10:39:14 2005 UTC
| + Segment UID: 0xa2 0xd9 0x45 0x6c 0xef 0x5e 0xe8 0x01 0xbb 0x3a 0x2c 0xa9 0xd
9 0xef 0x62 0xc9
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 905473676
| + Track type: video
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 0
| + MinCache: 1
| + Timecode scale: 1.000000
| + Max BlockAddition ID: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 38
| + Default duration: 10.347ms (96.646 fps for a video track)
| + Language: und
| + Video track
| + Pixel width: 704
| + Pixel height: 400
| + Display width: 704
| + Display height: 400
| + A track
| + Track number: 2
| + Track UID: 3167492503
| + Track type: audio
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 1
| + MinCache: 0
| + Timecode scale: 1.000000
| + Max BlockAddition ID: 0
| + Codec ID: A_AAC/MPEG4/LC/SBR
| + Default duration: 46.440ms (21.533 fps for a video track)
| + Language: und
| + Audio track
| + Sampling frequency: 22050.000000
| + Channels: 2
| + Output sampling frequency: 44100.000000
|+ EbmlVoid (size: 1024)
|+ Cluster

[Sirber]

MP4 in MKV, it seems that it's libavcodec.dll that crash.

[stephanV]

@Meteorain:

Yes, it crashes here too in both mplayer (latest CVS) and DirectShow. So it is either a bug in x264 or libav. Of course this raises the question: what settings did you use?(AVS scipt and commandline)

(Don't post them as attachment please)

[movax]

We had reports of borked libavcodec_dec.dll with similar troubles in the last CCCP, solved my going to the latest CVS non-dec version.

@Sirber, I think it has to be something at your end...I just used 292A to complete your (x264 --> mp4) --> mkv test as well.

[Sirber]

Where could I get such a build?

[MeteorRain]

@stephanV

let me just post the avs and log for another sample (meet exact the same problem i bet)

avisource("[raw]DearS 01 (DVD 640x480 DivX5.11 QB95 24fps).avi",false)Next job job1 is a video job. encoder commandline:
"H:\mp4\x264.exe" --qp 23 --ref 4 --bframes 10 --b-pyramid --nf --weightb --analyse all --8x8dct --ipratio 1.0 --pbratio 1.0 --me umh --progress --no-psnr --output "I:\hd200\disk2\subgroup\DearS\1.mp4" "I:\hd200\disk2\subgroup\DearS\1.avs"
successfully set up video encoder and callbacks for job job1
----------------------------------------------------------------------------------------------------------

Log for job job1

avis [info]: 640x480 @ 23.98 fps (34049 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 2000000 (scale 23976023)
This is a CQ job so there's no desired bitrate. Obtained video bitrate: 179.386766222332 kbit/s
----------------------------------------------------------------------------------------------------------The above is the corrupt sample.



And an OK sample:
avisource("[raw]DearS 10 (DVD 640x480 DivX5.11 QB95 24fps).avi",false)Next job job10 is a video job. encoder commandline:
"H:\mp4\x264.exe" --qp 23 --ref 4 --bframes 10 --b-pyramid --nf --weightb --analyse all --8x8dct --ipratio 1.0 --pbratio 1.0 --me umh --progress --no-psnr --output "I:\hd200\disk2\subgroup\DearS\10.mp4" "I:\hd200\disk2\subgroup\DearS\10.avs"
successfully set up video encoder and callbacks for job job10
----------------------------------------------------------------------------------------------------------

Log for job job10

avis [info]: 640x480 @ 23.98 fps (34046 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 250 (scale 2997)
x264 [info]: slice I:314 Avg QP:23.00 Avg size: 25089
x264 [info]: slice P:15512 Avg QP:23.00 Avg size: 8242
x264 [info]: slice B:18220 Avg QP:23.00 Avg size: 2028
x264 [info]: slice I Avg I4x4:39.8% I8x8:31.4% I16x16:28.7%
x264 [info]: slice P Avg I4x4:3.4% I8x8:3.8% I16x16:4.2% P:32.0% P8x8:6.1% PSKIP:50.4%
x264 [info]: slice B Avg I4x4:0.4% I8x8:0.3% I16x16:0.3% P:10.5% B:2.7% B8x8:1.2% DIRECT:3.6% BSKIP:81.0%
x264 [info]: 8x8 transform intra:32.6% inter:33.4%
x264 [info]: kb/s:972.8

Actual bitrate after encoding without container overhead: -105575.16
This is a CQ job so there's no desired bitrate. Obtained video bitrate: 974.550695947835 kbit/s
----------------------------------------------------------------------------------------------------------

[stephanV]

Well... you're settings are a bit ackward, but that should never cause a crash of course...

Maybe its the combination of many b-frames and b-pyramid that libav doesnt like... do you have the Nero decoder to test? (I guess not)

[Haali]

Looks like the problem is in integer overflow when AVI dwScale is too high (>23 millions in this case).

[stephanV]

Haali is obviously better at guessing than me :)

http://savefile.com/files/2005757 <--- test file

AVS script:
Avisource("test.avi")
assumefps(3.142)
x264 commandline:
x264 -o test.mp4 test.avs

Resultant mp4 will crash. Resultant mkv will play, but can't be remuxed with MKVmerge and remuxes weird with AMG.

You probably can use any weird non-integer frame rate to emulate the problem (just make sure you use enough frames too).

[movax]

Non-integer framerate...so 23,967 and the other standard rates will bork that test file? /me wonders what went into that file

[stephanV]

it doesnt b0rk the test file, it will probably b0rk any file, the file itself is nothing special.

[movax]

Ahkay, I think I see what you're getting at, x264 output to mp4 borks as a result of AssumeFPS(non-integer) in the input AVS.

[Sirber]

All my files are use "non-integer fps" and are "b0rked", unless I use RAW. I think we are on the path of bug killing :D

[Doom9]

when AVI dwScale is too high (>23 millions in this case).but which integer would overflow? the framerate is a double (uint dwRate / uint dwScale). However, a dwScale of 23 million is unusual.. a proper 23.976 fps file has a dwRate of 23976 and a dwScale of 1000, a 29.97 fps one would have 29970 and 1000 respectively.

So it's not so much about non integer FPS streams, but possibly those that have weird dwScale (and dwRate?) values. Here's what I get if I add assumefps(3.142) to a perfectly working 23.976 fps script: dwRate = 13178503, dwScale = 4194304. I'm encoding now to see what the results are (I used that same script without assumefps and successfully created a properly working mp4 and mkv (that can be remuxed) from it))

Those that can debug MeGUI.. open a script, set a breakpoint in AviReader.cs at the line
framerate = (double)streamInfo.dwRate/(double)streamInfo.dwScale;
and check out dwRate and dwScale for clips that don't work.

[stephanV]

but which integer would overflow? the framerate is a double (uint dwRate / uint dwScale). However, a dwScale of 23 million is unusual.. a proper 23.976 fps file has a dwRate of 23976 and a dwScale of 1000, a 29.97 fps one would have 29970 and 1000 respectively.
Not exactly since the right frame rates for NTSC are 30000/1001 and 24000/1001 IIRC. But that doesn't change that it shouldn't use such a weird number if it is using dwScale as scaling factor, but it seems to me it isn't doing that at all.

[Haali]

but which integer would overflow?
x264 calculates frame_number*dwScale in one place

[Doom9]

1001 is used on DVD (probably stems from the fact that film is 24fps and if you do 3:2 pulldown you have to use drop frames so it'll be 29.97) VFW seems to be using the more straightforward values.

Either way, not surprisingly my mp4 ended up being corrupt as well and mkvmerge complained upon importing:
mkvmerge v1.5.6 ('Breathe me') built on Sep 7 2005 18:18:02
'D:\DVDs\KILL_BILL_VOL2\VIDEO_TS\chapter1.mp4': Using the Quicktime/MP4 demultiplexer.
Warning: 'D:\DVDs\KILL_BILL_VOL2\VIDEO_TS\chapter1.mp4' track 1: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

[Sirber]

I made a little test and the (x264 --> mp4) doesn't work, it crash. if I sue MKV instead, output work but is unmergable in another mkv.

[edit]

Source FPS: 23.976

[MeteorRain]

well, i should mention, the log that i post yesterday indicated that the encoding process stoped unexpectly. that means, the x264 crashed on encoding.

i'm thinking of: source fps 23.976 maybe 23.976023. but we usually see a %.3f result, so we can't figure out the difference between 23.976 or 23.976023

23.976 = 23976 / 1000 = 2997 / 125
23.976023 ~=~ 24000 / 1001

(IMHO) the avi should have a fps value 24000 / 1001 but had a value 23976023 / 1000000, which makes it overflow again and again.

[Doom9]

before anyone posts here again saying something doesn't work, make damned sure you post your dwRate and dwScale values.

(IMHO) the avi should have a fps value 24000 / 1001I doubt AVIFile would round, that's why it uses those big values.

[Sirber]

how can I find it (whitout MeGUI :))?

[MeteorRain]

before anyone posts here again saying something doesn't work, make damned sure you post your dwRate and dwScale values. how to get the 2 values?
btw, i tried adding assumefps(23.976), how can i write the 2 values? and the result file corrupt too!

I doubt AVIFile would round, that's why it uses those big values.
how to resolve it? >_<

[bob0r]

For Siber's problem, could gpac 0.3.x or 0.4.x make any difference?
Or was that already tested? Sharktooth uses 0.4.x, i use whatever the latest x264 svn supports, which for these builds is 0.3.x.

[Sirber]

My problems started with 0.3x and continued with 0.4x. I can't find the old thread about that :(

[Doom9]

how to get the 2 values?debug megui the way I wrote.. or extract the code to a separate app. I could provide one if necessary, but it'll still be .NET of course.

whitout MeGUIOpen an AVI File in Delphi and read those values?

[Sirber]

I think I can get them both. Gonna try tonight.

[Doom9]

r295 | robux4 | 2005-09-20 18:18:23 +0200 (Tue, 20 Sep 2005) | 1 line

fps patch by HaaliMight have something to do with it but looking at the source changes I'm not so sure. Still, those AVIs with these values are pretty darned weird.

[Sirber]

So, if I get it correctly, some borked tools produced those AVI which bork x264?

[Sirber]

old: pic.i_pts = i_frame * param->i_fps_den;
new: pic.i_pts = (int64_t)i_frame * param->i_fps_den;
From the changelog using 64bit integer should fix the problem for most case. I will do some tests tonight.

[stephanV]

Nope, that didnt fix it. :(

[Haali]

This may be not enough to make mp4 output work, but matroska should be fine now.

[stephanV]

Aaaah yes. Very good. :)

[Sirber]

I'm not asking more :D
Testing...

[Sirber]

@Haali

Problem fixed for MKV. Many thanks!!!!!! :D

Produced MKV is 100% valid.

[MeteorRain]

@Haali

Problem fixed for MKV. Many thanks!!!!!! :D

Produced MKV is 100% valid.
is it still ok when you remux the mkv with audio using mmg?

[Sirber]

yep, all #1. :D I waited for this for months! :D :D :D

I'll be able to continu my work on RealAnime LE. :D

[bob0r]

Now for .mp4, does x264 need to change code, or does gpac need to change code?

[leowai]

Now for .mp4, does x264 need to change code, or does gpac need to change code?
@Haali

Problem fixed for MKV. Many thanks!!!!!! :D

Produced MKV is 100% valid.
From my point of view, since x264 raw-> mp4 works using MP4Box, it's more to the bug in porting x264 with gpac's mp4 output support.

Correct me if I'm wrong. Thanks.

Just curious about this: What's the different between x264 encoder and MP4Box when creating a *.mp4 output? If they are same (using same function), does it means that's the problem in x264 using gpac's mp4 output function?

[Sirber]

For (x264 raw-> mp4), you need to know the FPS, which cound have been altered by user avisynth script, and bork the result MP4. It's best to have it handeled by x264 directly.

[bob0r]

For (x264 raw-> mp4), you need to know the FPS, which cound have been altered by user avisynth script, and bork the result MP4. It's best to have it handeled by x264 directly.

Hmm yes ofcourse.

psp.avs:

LoadPlugin("i:\cap\_x264\_dgdecode.dll")
LoadPlugin("i:\cap\_x264\_decomb521.dll")
LoadPlugin("i:\cap\_x264\_mpasource.dll")
v=mpeg2Source("i:\cap\_x264\cap.d2v")
a=mpasource("i:\cap\_x264\cap.mpa")
audiodub(v,a)
fielddeinterlace()
crop(4,2,712,574)
LanczosResize(368,208)
ChangeFPS(29.97)


psp.bat:

start /belownormal /b /w x264 --progress --pass 1 --me dia --ref 1 --subme 1 --analyse none --output NUL psp.avs
start /belownormal /b /w x264 --progress --pass 2 --bitrate 512 --ref 1 --subme 6 --analyse all --output video.264 psp.avs
start /belownormal /b /w MP4Box.exe -fps 29.97 -add video.264 output.mp4
start /belownormal /b /w MP4Box.exe -fps 29.97 -add audio.aac output.mp4
start /belownormal /b /w ATOMChanger.exe output.mp4 MAQ00264.MP4 AtomAVC.ini


I'll try setting the FPS in the x264.exe line too; --fps <float|rational> Specify framerate

--fps 29.97, and then maybe it "fixes" the .mp4 file, ill try

Note the _detected_ fps here:

start /belownormal /b /w x264 --progress --pass 1 --me dia --ref 1 --subme 1 --analyse none --output NUL psp.avs
avis [info]: 368x208 @ 29.97 fps (9539 frames)



If i remove ChangeFPS(29.97) from the .avs and --fps 29.97 via x264.exe, will x264 then convert the 25FPS PAL to 29.97?

[movax]

I think both will certainly convert the framerate, but the telecining/assorted processes that have been done to the PAL video can't be easily fixed by a simple framerate change. (e.g., a 24fps source to 25fps PAL is just speeded up, this is common, but then converting that to 29,97 would be akin to telecining 24fps video, I'm kind of sure.)

[bob0r]

@movax
Ah yes, well the videos are for Sony PSP, and they work fine with MP4Box, its purely about a working .mp4 now, converting the right way may come later (unless it influences the .mp4 output)

I see i have made a small mistake; avis [info]: 368x208 @ 25.00 fps (7957 frames) is just how many FPS the .avs file is outputting.
I am now trying --fps via x264.exe and ill send the files to my friend to test on his PSP.

avs change 29.97 FPS > .mp4 PSP does not work
avs change 29.97 FPS + x264.exe --fps 29.97 = Needs to be tested
avs 25 FPS (original source) + x264.exe --fps 29.97 = Needs to be tested
... will let you know. (If all fails on PSP, ill remux the audio/video with MP4Box)
Thanks.

Edit:
It seems x264.exe --fps 29.97 does NOT change the video fps, i wonder what it does do :)
Or is it the same as MP4box, just to set the .mp4 FPS?
In that case, .avs changefps 29.97 + x264.exe .mp4 output --fps 29.97, should create a valid file?

[Sirber]

PSP encoding is kinda OT...

[bob0r]

PSP encoding is kinda OT...

Not really, it can be used perfectly for .mp4 output testing.

I just encoded:
.avs ChangeFPS(29.97) and x264.exe --fps 29.97, and indeed the .mp4 output file is fucked, so adding --fps 29.97 is indeed b0rked.

Atomchanger.exe goes besoik on this output.mp4!

[bond]

seems jeanlf fixed this framerate problem with gpac:
I just fixed 64-bit ts support in isomedia and other parts of GPAC. You should now be able to import with pretty much any kind of timescales and dts - just checked it with a file lasting 4 days with only 31 frames.can sharktooth or celtic_druid plz make a new compile with latest gpac and anyone who had a crashing sample file test whether it is now fixed?

[Kurtnoise]

You can grab my last compile here (http://kurtnoise.free.fr/mp4tools/MP4Box_20051203.zip)...

[Sharktooth]

that should fix the problems in x264 too...

EDIT: i've just updated gpac and i get tons of undefined references... and obviously it doesnt compile.

[bond]

that should fix the problems in x264 too...

EDIT: i've just updated gpac and i get tons of undefined references... and obviously it doesnt compile.the last cvs before the change compiles fine?

[Sharktooth]

yeah.

EDIT: i checked out the CVS in during a series of updates... i will let you know if there are news.

EDIT2: There are syntax errors during the compilation... the results is undefined references...
For example:
commands.c: In function `gf_sg_command_apply':
commands.c:432: error: `SVGElement' undeclared (first use in this function)
commands.c:432: error: (Each undeclared identifier is reported only once
commands.c:432: error: for each function it appears in.)
commands.c:432: error: syntax error before ')' token
commands.c:438: error: syntax error before ')' token
commands.c:457: error: syntax error before ')' token
commands.c:465: error: syntax error before ')' token
commands.c:484: warning: implicit declaration of function `svg_attributes_copy'
commands.c:486: warning: implicit declaration of function `svg_attributes_add'
make[2]: *** [commands.o] Error 1

[Kurtnoise]

Indeed...nevertheless the static library is built.

http://kurtnoise.free.fr/x264_r381.zip

[bond]

Indeed...nevertheless the static library is built.

http://kurtnoise.free.fr/x264_r381.zipthx kurtnoise

now can anyone reporting problems about this framerate issue check whether its fixed?

[Sirber]

C:\Projets\RealAnimeLE\output\bin>xvid_encraw.exe -i test.avs -o test.m4v -type
2
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
Avisynth input is based on Avs2YUV by Loren Merritt

test.avs: 640x480, 10000000/417083 fps, 573 frames
converting YUY2 -> YV12

376 Frames encoded - 65.62%

Isn't it AVISynth giving odd FPS numbers?

[Sharktooth]

Ok, my 384/384A builds use the latest gpac.