open-gop patch for x264 (committed)

[jpsdr]

OK, HRD rewrite/modifications finished, try this build (http://www.mediafire.com/?m0yntzkbxdz). It should pass mux.

Ok, thanks. I get it, start the encode this evening, and should be able to test results tomorrow evening.

[Stacey Spears]

OK, HRD rewrite/modifications finished, try this build. It should pass mux.

I was able to mux with Sonic.

[jpsdr]

Buffer underflow exactly on the same place....:(

[Dark Shikari]

Buffer underflow exactly on the same place....:(OK, come on, your muxer has to be broken or you're just making this up.

We just changed HRD. HRD is giving different results, as is VBV. This was a test: that executable I posted includes other changes to ratecontrol which make it staggeringly unlikely that the underflow will just happen to occur on the same frame.

And it occurs in the same place.

The only possibilities I can think of are:

a) You forgot to replace your x264.exe and inadvertently used an old one.
b) Lightning just struck 8 times in the same place and x264 buffer-underflowed in the exact same place as before, despite an odds of thousands to one against.
c) Your muxer is broken.
d) You're lying.

I have checked multiple full-length test inputs with a buffer analyzer and found no problems. You, by comparison, keep complaining about underflows, but never post any actual detail about it -- where's your screenshots? Where's your muxer logs? How much does it underflow by, in bits, on which frame? Why does your muxer report an underflow, but everyone else's doesn't, even on the same file?

[jpsdr]

Good news in bad news : I can reproduce it on a very small sample (<200MB).
I'm preparing links, for you to check. Wait a little.
a) No.
b) No.
c) Can't deny the possibility at 100%...
d) Well, can't prouve to you i'm not.

[kieranrk]

Good news in bad news : I can reproduce it on a very small sample (<200MB).
I'm preparing links, for you to check. Wait a little.
a) No.
b) No.
c) Can't deny the possibility at 100%...
d) Well, can't prouve to you i'm not.

Please don't send rapidshare links. They are annoying to download. Use the FTP I sent you.

[jpsdr]

@kieranrk
Uploads done.
You have : The original source file in one file.
In the other, you have :
- The x264 version used
- The logs and stats files
- The batch files used to encode
- ScreenShoots
- 2 results file : One NOk -> create underflow error (encoded with Test-1.bat), and another Ok, don't create underflow, (encoded with Test-2.bat), BUT... create the warnings you can see in ScreenShoot 4.
It've made very few Blu-Ray until now, but, it's the first time i've got this warning. Until now, all my muxes allways finished fine.
- The .mts file wich failled mux (at least, one part...)
Problem occurs around frame 414.
I've just made a test without opengop, no effect, still underflow.

[shon3i]

Ok, i comfirm that i get underflow with jpsdr sample, even without open-gop.

I test with Scenarist, Blu-Print, DVD Author, all fail at same position.

More to come later.

[kieranrk]

Ok, i comfirm that i get underflow with jpsdr sample, even without open-gop.

I test with Scenarist, Blu-Print, DVD Author, all fail at same position.

More to come later.

All these tools use the same muxer afaik so it would be useful to show that muxing doesn't work on a different application.

Someone who works on Scenarist has told us that it could possibly be a bug.

[shon3i]

All these tools use the same muxer afaik so it would be useful to show that muxing doesn't work on a different application.

Someone who works on Scenarist has told us that it could possibly be a bug.
Yes i am aware of that, i am currently work on another encode, with Mainconcept encoder with possible similar settings, just for reference.

[Dark Shikari]

Yes i am aware of that, i am currently work on another encode, with Mainconcept encoder with possible similar settings, just for reference."Another encode" tests nothing -- it will almost surely not exercise the failure mode that breaks the muxer.

We need another muxer.

[mp3dom]

The only others professional authoring tools that use different muxer is DoStudio Authoring which uses the Corel muxer. Maybe someone who have it could try to compile.

[jpsdr]

@shon3i :
Can you pass the tools you have to check the compliancy on the stream labelled Ok, but wich still produce warning during mux, to see if the source of these warnings can be identified ?

Edit : Can muxing with TS muxer and check the Blu-Ray compliancy on the stream wich fail mux on Scenarist be considered an answer to the "We need another muxer" of DS ? ... Trying to find solution to point where problem belongs...
DS/Kieranrk : Has precise analysis of samples provided given anything ? Does the warnings of the stream wich mux (but still produce the warnings) also give any hints ?

[kieranrk]

DS/Kieranrk : Has precise analysis of samples provided given anything ? Does the warnings of the stream wich mux (but still produce the warnings) also give any hints ?

It happens because there's a very difficult scene to code and x264 uses as many bits as possible. The stream gets very close to being out of spec (at least by my understanding of HRD) and there could possibly be a rounding error on their side just like the rounding issues we had.

EDIT:
Muxing works in works in DoStudio authoring.

[Emulgator]

jpsdr, if you would like to send your files to my ftp, leave a PM.
I may check muxing on Sony DVD-A 5.0b

[shon3i]

Muxing works in It works in DoStudio authoring. Well that still means nothing, tsmuxer aslo mux, but fail at verification process.

btw i little played with Mainconcept encoder, and i sucessfully reproduce same error at same place, after tweaking codec a little.

I redice Inital HRD buffer fullness from default 10 to 0.

EDIT: Elecard fail at same place. Sony Blu-Code passes.

[jpsdr]

Ok, what's finaly the meaning of all of this ? tsmux mux but fail at verification, others encoders fail, others pass...
Does it mean that this specific scene trigs a problem on the muxer or on the encoders ?
If verification process fail on muxed stream (tsmux or either others), does it mean that problem is more likely in the stream than in the muxer ?
If muxer in Scenarist was broken, and stream fine, shouldn't the stream pass verification muxed with tsmuxer ? Or is the muxer in tsmuxer also broken ? Or not reliable ? If not, can we consider problem is on the stream ?

[Dark Shikari]

Ok, what's finaly the meaning of all of this ? tsmux mux but fail at verification, others encoders fail, others pass...
Does it mean that this specific scene trigs a problem on the muxer or on the encoders ?
If verification process fail on muxed stream (tsmux or either others), does it mean that problem is more likely in the stream than in the muxer ?
If muxer in Scenarist was broken, and stream fine, shouldn't the stream pass verification muxed with tsmuxer ? Or is the muxer in tsmuxer also broken ? Or not reliable ? If not, can we consider problem is on the stream ?The scene triggers a difficult situation which causes encoders to get very very close the limits. If they have a rounding bug, this would cause their muxer to break in this situation.

[jpsdr]

I don't follow... You said that if encoders have a rounding bug, their muxer (so, the muxer of the encoders), break.
So, encoders are at fault, not the muxer of Scenarist ? Wich means when shon3i said verification fails, it's the h264 stream ?
Does it mean there is still something in x264 which this scene trigs ?

[Dark Shikari]

I don't follow... You said that if encoders have a rounding bug, their muxer (so, the muxer of the encoders), break.
So, encoders are at fault, not the muxer of Scenarist ? Wich means when shon3i said verification fails, it's the h264 stream ?
Does it mean there is still something in x264 which this scene trigs ?By "their", I meant "the muxer".

If Scenarist has a rounding bug, Scenarist might fail in this case.

[jpsdr]

So, if tsmuxer have also a rounding bug, it will mux, but creating a problem wich was not present on original state, and which finaly create a non compliant stream wich fail the pass ?
Have you seen something on the other stream, the one Ok, wich pass mux, but still generate warnings on Scenarist ?

@shon3i : Same question ? If fail, on what spec it fails verification ?

Now, pratical : How can this be fixed ????? => How can i do my Blu-Ray ?
I only see 2 options :
a) Waiting for response from Scenarist, wich may take a while....
b) Add a margin in x264 wich consider the possibility of rounding error, and so adjust calcul considering the fact ?
If i have had the problem, someone else can have also too.
You may realy not like it, but can you consider the implementation of the b) solution ?
I think, in the process of trying to make x264 usable in Blu-Ray authoring, even if i agree on a perfect world it should be the opposite, as x264 has a quick response time, it's for now the fastest way to solve the problem. Maybe add some command line option like --tweak-muxer or anything.
I'll finished, with something i've read i don't remember were :
Someone who worked on a company wich was doing a software PC Blu-Ray player, said that they were obliged to tweak or adjust their player to be able to play overspecs of the standard. Someone said that it shouldn't be them to adjust, but the encoder to be corrected. The guy agreed, but said that when someone has bought a Blu-Ray, and it doesn't play properly because it wasn't done 100% properly, you can't ask to the editor to redo it.
(Philosophical point is that for now, it'll be easier and faster to adjust x264 than fixing Scenarist...).
What do you think ? (I had to know if i'm s*** for my project or not...:()

[kieranrk]

b) Add a margin in x264 wich consider the possibility of rounding error, and so adjust calcul considering the fact ?
If i have had the problem, someone else can have also too.
You may realy not like it, but can you consider the implementation of the b) solution ?
I

Not a snowball's chance of it ever getting in but I guess there could be a separate patch that reduces the actual buffer fill rate by a few percent or so to make a situation like this impossible.

[jpsdr]

Not a snowball's chance of it ever getting in but I guess there could be a separate patch that reduces the actual buffer fill rate by a few percent or so to make a situation like this impossible.
... I thought it was what i've suggest, some kind of option wich if activated, will do what you've suggested.
I can, if it's the solution choosen, make several test to find out wich smallest percent make the problem disappeared.
An option like --adjust-buffer x where x is a float wich tell how percent reduce the buffer fill rate (0 mean full/no reduce, etc...). When correct value found, the final option will not have a parameter.
What do you think ?
In fact, writing this, i'm realy interested to try this...

[Emulgator]

Sony DVD-A5.0b Build 180 as well won't mux jpsdr's encode.
Scheduled for transcoding, because bitrate exceeds the DVD-A built-in 28 Mbps limit.
Konran's BitrateViewer shows ugly peaks where the noise burst sets in.
GOP mode (per frame):36600 kbps
GOP enhanced mode (per GOP): 24895 kbps
Second based mode: 22109 kbps
For an average bitrate goal of 4500 kbps this comes out too high, I see a hairy time here for any buffer model.
(BTW, I see 1280x720x23.976p, 6 refs, mixed_ref=1, GOP M=4, N=22. Maybe this combination breaks it.)

Of course, to encode noise will eat up bitrate to the max,
but here the noise of the source is not as sharp that it should trigger the encoder to such excess.
And the active picture area is only 960x720 (4:3 pillarboxed in 16:9)
and the framerate is only 23.976p.
So 960x720x23.976 = 16.572.211 pixels/s. With 4500kbps ->~0.271 bpp. (MediaInfo says 0.254 bpp)

IMHO it should be possible to encode the whole active picture area within the 1280x720 frame
with a sharp white noise source, eg. containing all frequencies to the max,
not necessarily preserving high-frequency parts of the signal, but staying within bitrate/buffer limits.

Hard, but possible. 0.1 bpp and in tests even 0.03 bpp were sufficient for large parts of BigBucksBunny,
which is a completely different thing to encode of course, rather pleasant.

What do we have if we use the limits of AVCHDLite or FullHD @ L4.0?
16000 kbps for 720p:
1280x720x59.94p = 55.268.352 pixels/s ->~0.289 bpp
24000 kbps for 1080i
1920x1080x29.97i = 62.145.792 pixels/s ->~0.386 bpp

Late Edit: To avoid misunderstanding:
The following was meant as a suggestion

This may not be sufficient to encode white noise, but what about the following:

If encoder is sensing bitrate excess, then encoder may introduce lowpassing (first spatial, then temporal)
and filter the highest frequency parts off to save a bit
to still be within bitrate and buffer limits.

End of suggestion

I guess CCE does something like that in MPEG-2 already for years.
While in earlier years Mainconcept MPEG-2 seemed to throw out
only a few arbitrarily found and randomized coefficients for encoding noise...
BTW, even the Largarith source had blocks. Frames 380-387 and some more...

[jpsdr]

Original source is DVD i've denoised, so, don't expect high quality, and that's why there is the blocks you mention... And, it's just a small part to see/trig the problem. I agree that for this small part, 4507 average may be low, but, in reality, it's a whole around 160000 frames video wich is encoded with an average bitrate of 4507, with this only a part of it.

[shon3i]

Ok here is my results,

First jpsdr your OK sample passes verification normally, i realy don't know what this warnings means but seem that is not releated to video.

Second kieranrk, your sample show several warnings about exceedeng tolerated bitrate, theoretically passes (is not failure), but probably can introduce problem on standalones. I suppose should not be a problem since max bitrate is 15000, thats why probably passes.

DoStudio seem know how to handle this situation (I wonder what would have been if VBV's are set at max 30/40), while tsmuxer completly make stream overflowed. And scenarist/blu-print reject to mux.


I encode same sample using other encoders and i get following results

Mainconcept: pass mux, pass verification (0 warnings)
Elecard: fail mux
Blu-Code: pass mux, pass verification (0 warnings)
Ateme: pass mux, pass verification (0 warnings)
Mainconcept different HRD decisions: fail mux

[jpsdr]

First jpsdr your OK sample passes verification normally, i realy don't know what this warnings means but seem that is not releated to video.

Have-you got the warning when muxing with Scenarist ?
(If you've used Scenarist).
As several encoders don't reproduce the problem, i don't know how to interpret your results... I'm not qualified enough...

[shon3i]

Have-you got the warning when muxing with Scenarist ?Yes. But they are seem just warnings which not affect on playback.

It seems that Scenarist/Blu-Print engine realy have bug or it's more restrictive in this cases. And other encoders are adapted to this since is scenarist/blu-print is common in BD Authoring

[jpsdr]

Problem with these warnings, it's that only with this small video, mux finished, but with my whole Blu-Ray, mux doesn't finished, and i've hundred of them.
Well, the TS finished, but not the following. I think nevertheless it's something in the video wich trig this warning....
Well, i hope some kind of fix/adapt can be made, at leat kieranrk seems to have an idea...

[Emulgator]

Frankly, a 720p upsized DVD source should be easily encodable and muxable on a Blu-ray.
This is what I intend to do as well once the thing is safe to use:
Restore old SD Sources, TGMC-bob to 50/59.94p and upscale to 1280x720 for universal BD on BD/AVCHD on DVD+SD+HDD use.
Your anime source should be easily compressible, the noise isn't too high frequency
(remember:it came from a DVD)
and I don't think x264 should exceed the average specified bitrate by factor 6 for the duration of a full GOP,

let alone that more than 24000kbps seem to exceed L4.0 as well.
I guess this can be easily fixed on x264 side.

Edit: I was wrong, of course this can happen and still is within specs,
only wondering what in that low-passed-noise made x264 bark and muxers choke.

[jpsdr]

Personnaly, i don't mind if the bitrate on a GOP is 6 times the average, even more, i find this is a good thing, meaning x264 know very well where to put high bitrage when necessary, and where to reduce when possible. I higly prefer an average 4500 file with peak at 25000 and lower at 0 than an average at 4500 with peak at 6000 and lower at 2000.
According what they said, you can have peak at 24000 (even if you've asked for a max at 15000) if buffer can recover... From my (non expert) point of view, there is nothing to fix, i even said "wonderfull, it's the way i want the things done". Now, out of spec results are another story, but it doesn't seem to be the case here.

[Trahald]

Frankly, a 720p upsized DVD source should be easily encodable and muxable on a Blu-ray.
This is what I intend to do as well once the thing is safe to use:
Restore old SD Sources, TGMC-bob to 50/59.94p and upscale to 1280x720 for universal BD on BD/AVCHD on DVD+SD+HDD use.
Your anime source should be easily compressible, the noise isn't too high frequency
(remember:it came from a DVD)
and I don't think x264 should exceed the average specified bitrate by factor 6 for the duration of a full GOP,
let alone that more than 24000kbps seem to exceed L4.0 as well.
I guess this can be easily fixed on x264 side.

So are you saying that a stream that has the settings bitrate: 1000 max_bitrate 20000 and a buffer of 30000 should not maintain 20000 for a full length of a gop? (that would be a factor of 20 bitrate)

And understand... x264 is freely available for anyone that would like to use it. Having said that, it will hurt no ones feelings if you do not.

[jpsdr]

@shon3i :
About the warnings : I've re-encoded the sample in "mode Ok" (buffer=15000 instead of 30000) and without opengop : Result is that there is no warnings. Can you confirm this from your side ?

Edit
Ok, i've made some tests on a small and nice other sample, and Scenarist doesn't like the opengop, it's the cause of the warnings. Can this be confirmed ?

But, it should be interested to test this "coded" option. Is it possible to have a build with v40 opengop to test this ?

[Emulgator]

I am thankful for all the work that goes into x264, yours included, Trahald.
I was just uttering my thoughts about possible improvements, meaning to help.
Sorry if this came out wrong, I apologize.

[Trahald]

@shon3i :
About the warnings : I've re-encoded the sample in "mode Ok" (buffer=15000 instead of 30000) and without opengop : Result is that there is no warnings. Can you confirm this from your side ?

Edit
Ok, i've made some tests on a small and nice other sample, and Scenarist doesn't like the opengop, it's the cause of the warnings. Can this be confirmed ?

But, it should be interested to test this "coded" option. Is it possible to have a build with v40 opengop to test this ?

'coded' is what recent versions of open-gop did by default (--open-gop)

[jpsdr]

Ah.... Well, there is something Scenarist doesn't like. Problem is that a 1000 frames video generate around 5-6 warnings. Warnings are displayed at a speed of 2 by second, and block/hold mux during that time. So, when you've 12 videos stream of 160000 frames...
Warnings said something about 'Illegal EPMAP'. Does it ring a bell ?

[Blue_MiSfit]

I saw that Open-GOP was finally committed to GIT, congratulations guys!

Derek

[Midzuki]

http://x264.nl/x264/changelog.txt says:

commit 40c8c4926a78a705c263e042a780d63ca24687f4 r1657
Author: Lamont Alston <wewk584@gmail.com>
Date: Wed Jun 16 10:05:17 2010 -0700

Open-GOP support
Allows B-frames immediately prior to keyframes (in display order).
This helps reduce keyframe popping and improve compression with short keyframe intervals.
Due to a staggering display of braindamage in the Blu-ray spec, two open-GOP modes are available.
The two modes calculate keyframe interval differently: one based on coded distance and one based on display distance.
The latter is superior compression-wise, but for no comprehensible reason, Blu-ray requires the former if open-GOP is used.

Downloading it now...

[shon3i]

Amazing!.

Can you confirm this from your side ?
Last time when i checked (with rev20-22) i never saw this warning (scenarist 0 errors/warnings, passed sony verifier). Later i will check with official x264. I don't know how much Trahald changed from rev 22 to 40, but is looks like cosmetics changes only.

Maybe that crazy sample violates something more :D

[kieranrk]

*bitrate viewer screenshots*

Bitrate Viewer doesn't measure the bitrate as defined by VBV and HRD so are not relevant.

[me7]

Are there tests on the usefulness for normal keyint settings like 250?
I understand that the benefit for low settings is great, but should I expect any improvement with keyint 250?

[jpsdr]

Maybe that crazy sample violates something more :D
No, as i've said, i've made a test on a "nice" sample.

[Trahald]

Are there tests on the usefulness for normal keyint settings like 250?
I understand that the benefit for low settings is great, but should I expect any improvement with keyint 250?

I haven't tested but there would be only slight improvement over closed GOP. As long as the player you intend to use supports open GOP , there is no downside. So I'd say it's still worth using.

[LoRd_MuldeR]

As long as the player you intend to use supports open GOP , there is no downside. So I'd say it's still worth using.

Why isn't Open GOP enabled by default then, at least the "BluRay conform" mode of it? Any example of a player/decoder that chokes on Open GOP?

[Dark Shikari]

Why isn't Open GOP enabled by default then, at least the "BluRay conform" mode of it? Any example of a player/decoder that chokes on Open GOP?Flash, AFAIK? It won't seek.

[jpsdr]

Bitrate Viewer doesn't measure the bitrate as defined by VBV and HRD so are not relevant.
Just curious, real question, why, in that case, when i've used it to test on 12 video stream, each time the average bitrate was exactly the same that the one in the result log file ?

[Dark Shikari]

Just curious, real question, why, in that case, when i've used it to test on 12 video stream, each time the average bitrate was exactly the same that the one in the result log file ?Because average bitrate has no relation to VBV.

[LoRd_MuldeR]

Flash, AFAIK? It won't seek.

Argh :mad:

Still, Weight-P is enabled by default too, although there are known players/decoders that are broken with respect to Weight-P...

[me7]

CoreAVC with CUDA doesn't seem to like it too, picture is sometimes messed up after seeking. When I skip back a few seconds and watched the previously corrupted part again (without seeking into the trouble area), everything is fine.

[Guest]

Can you post a sample please? I'd like to test it with my tools.