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

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