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.

[neuron2]

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

[Trahald]

@me7
What format is it (.ts m2ts mp4 avi etc is it) and how did you mux it (x264 was the only tool you used, yamb(mp4box), tsmuxer, etc..) then we can now if its the muxer or the player.

[Dark Shikari]

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.That sounds more likely to be a muxer or demuxer issue.

[me7]

I encoded it with Lord_Mulder's GUI and selected mkv as output type (don't know which muxer it uses), played it with MPC-HC and Haali's Media Splitter.
x264 command line ("x264_x64" is the folder for Lord_Mulder's GUI): C:\Tools\x264_x64\pipebuf.exe C:\Tools\x264_x64\avs2yuv.exe C:\casino\video.avs - : C:\Tools\x264_x64\x264_x64.exe --preset veryslow --tune film --crf 18.0 --bframes 16 --open-gop display --output C:\casino\video.mkv --frames 256547 --demuxer y4m --stdin y4m - : 4

Here is a sample: http://forum.doom9.org/showthread.php?p=1412260#post1412260
The sample was created with mkvtoolnix 4.0, I chose to remux the mkv and told mkvtoolnix to split the output into 2 min chunks. One of them served as that sample.

[neuron2]

My testing indicates it has nothing to do with x264. It's not x264's fault if demuxers/decoders can't handle open GOPs properly.

[Atak_Snajpera]

Here is a sample: http://forum.doom9.org/showthread.ph...60#post1412260
I tested on my PC and I couldn't force that sample to show any corruption.
ffdshow r3474 + Haali Media Splitter + MPC-HC (internal filters disabled)

[me7]

I didn't mean to imply that x264 was to blame. I just wanted to add that Flash isn't the only decoder/demuxer that has problems.

[moviefan]

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.

What revision is your x264 binary? I've had the same issue a few weeks ago, but it seems that the patch had a typo accidentally introduced by rack04. My last encodes were all successful with a much more up to date revision of the patch.

[me7]

I used the "official" 1659 build, no patch ;)
It really seems to be related to CoreAVC, some other guy in the CoreAVC thread reproduced it but didn't have any issues with the DivX decoder.

[sneaker_ger]

I used the "official" 1659 build, no patch ;)
It really seems to be related to CoreAVC, some other guy in the CoreAVC thread reproduced it but didn't have any issues with the DivX decoder.

I think he was talking about the DivX Splitter and not the DivX Decoder.
/edit: my bad, he edited his post yet again. He is talking about the DivX decoder.

I tested with DiAVC: no problems.

[shon3i]

@Trahald let's back on jpsdr second problem which is related to Open-GOP. I don't know what you changed from rev 26 to rev 40 (or commited rev), but something not same i suppose that coded mode should be same as rev26 since display mode not pass muigenerator with GOP exceeding error.

Scenarist on mux create large number of warnings with message "Illegal EPMAP". This not happen if keyint 24 used or opengop is disabled, only with keyint 48, and not with your experimental buld which contain rev26 patch.

[jpsdr]

Unhappy for the unfortunate problem, but happy problem confirmed...

[Maccara]

I tested with DiAVC: no problems.

Surprisingly (after reading about all the trouble people have had with ATI), MPC-HC + Haali + ATI DXVA (internal filters) works perfectly with "display" mode too (with my limited tests).

[Trahald]

@Trahald let's back on jpsdr second problem which is related to Open-GOP. I don't know what you changed from rev 26 to rev 40 (or commited rev), but something not same i suppose that coded mode should be same as rev26 since display mode not pass muigenerator with GOP exceeding error.

Scenarist on mux create large number of warnings with message "Illegal EPMAP". This not happen if keyint 24 used or opengop is disabled, only with keyint 48, and not with your experimental buld which contain rev26 patch.

what settings get you the error (full command line). how small of a sample can be made that does it? (im up to 5000 frames unable to duplicate) my pc is slow so i need to narrow that down. meanwhile i'll keep trying

[shon3i]

what settings get you the error (full command line). how small of a sample can be made that does it? (im up to 5000 frames unable to duplicate) my pc is slow so i need to narrow that down. meanwhile i'll keep trying
--level 40 --qpmin 0 --vbv-maxrate 15000 --vbv-bufsize 15000 --keyint 48 --min-keyint 2 --ref 6 --bframe 3 --b-pyramid "strict" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --threads 0 --thread-input --open-gop "coded"

first source is jpsdr "problematic" sample 786 frames long.

second source is mine, some test clip from blu-ray, around 5000 frames long.

both reproduce same warnings.

btw this warnings are show on muxing stage. passes normaly muigenerator.

[jpsdr]

I've tested on another sample than my problematic, of around 1000 frames, it reproduce.

[Trahald]

try using 48 - b-frames for your max key-int. So if you have b-frames = 3 then use 45. and see if you get the epmap warnings. (try a few different encodes)

[shon3i]

I confirm on 2 samples with Keyint 45 and 3 bframes, warnings are gone.

[Trahald]

With this particular warning, my inclination is not to code against it. If it were fatal, I'm sure scenarist would ERROR out and cancel the mux (as opposed to just a warning). So I'll leave it up to the user to truncate the gop length by b-frames value in order to avoid the warning. The reason the older patch wouldnt create the warning is because that patch limited both coded AND display length of gop. The current one only limits coded order when in coded mode. I need someone that knows for sure to clarify what bluray is looking for before I change it again. Unless of course a core developer demands it.

[kemuri-_9]

If it was really the bframes being a problem, then a gop size of 24 (for >15mbps material) should exhibit similar problems with --opengop coded.
But it was already stated to not.

So I'm inclined to say that something else is the problem and it's just being aggravated by the long gop.

[jpsdr]

Maybe should test with a GOP of 47 to see if there is still the warnings. Will try this evening to see, unless shon3i can test that before.

[Trahald]

If it was really the bframes being a problem, then a gop size of 24 (for >15mbps material) should exhibit similar problems with --opengop coded.
But it was already stated to not.

So I'm inclined to say that something else is the problem and it's just being aggravated by the long gop.

The thing is, i dont think scenarist checks for 1 second gop the way it checks for 2 seconds. I just muxed a video at 17/30 and 35 frames and it muxed no errors or warnings

[shon3i]

So I'll leave it up to the user to truncate the gop length by b-frames value in order to avoid the warning.It's ok for me, but i think is not good solution, since for example Blu-Code and Cinevision aslo reduce gop size according b-frames, ref frames, b-pyramid, open-gop combinations, for example GOP is 22 if all is options is used, in x264 i think like other things should automaticly corrected, at least on coded since is Blu-Ray specific.

If it was really the bframes being a problem, then a gop size of 24 (for >15mbps material) should exhibit similar problems with --opengop coded.Well not all combinations allowed, aslo you can use always GOP 24, totaly independent of max bitrate. I think that nothing has been violated with long gop, just exceeding because is 3 bframes used.

Maybe should test with a GOP of 47 to see if there is still the warnings. Will try this evening to see, unless shon3i can test that before. It still show warning but, with GOP 48 i get 3 warnings, with 47 i get one.

[jpsdr]

Ok, the solution is to use 45 GOP with open GOP and b-frame 3. Fine with me.

[shon3i]

@Trahald, can i send you blu-code stream that use OpenGOP together with LongGOP. I examine stream and i am suprised that stream contain few IDR frames, while x264 only first frame is IDR, other is non-IDR.

whether this could be explanation? or it's just one of implementation of open-gop?

btw when i selected max bitrate to 15mbps, encoder reccomend me to use gop 45 but max is 47. I will test that with blu-code, maybe is something with scenarist

[Trahald]

Ok.. this is what i gathered... the gop size is being determined by coded distance (leading b to leading b) in open gop. what the EP_MAP is is a guide for fast-forward/rewinding the disc. it contains whats called fine entries that point to the start of every GOP. These fine entries point to the IDR/i-frames not the leading b-frames. the time between these entries cannot exceed 2 seconds. since our display times exceed 2 seconds. You end up with a stream that will mux but the complaints of the spec violation. So.. that means .. i'll code a patch that limits coded mode to both display and coded limits and see if it gets in. i'll change options to none/display/both.

unless someone says otherwise and and honestly, comes up with a stream that proves otherwise (48 frames not 24) its the way i'll believe

[Trahald]

@shoni
sure pm me.

[shon3i]

Ok, after playing with Blu-Code, i have clear picture.

Encoder allow to set GOP to 47 after reduce bframes from 3 to 2, otherwise encoder don't allow to set nothing higher than 45. There is aslo one more parameter which explain IRD frames in OpenGOP, that is "IDR Interval Factor" which have default value of 4, and can't be lower. From their manual:

IDR (Instantaneous Decoder Refresh: Instantaneous refresh
of decoder recovery operation) Specify the picture interval.

[Trahald]

That encoder benefits from a GUI. I cant force someone to type in 45. ;) I think truncating for display and coded will do the trick. i'll make up my mind after seeing the stream

[Dark Shikari]

That encoder benefits from a GUI. I cant force someone to type in 45. ;) I think truncating for display and coded will do the trick. i'll make up my mind after seeing the streamIf we're going to truncate, why do we need display/coded?

[Trahald]

the display stream would have fewer i-frames (if the stream were long enough) as truncating both will make the effective average gop length shorter. honestly im ok with one mode, but i was ok with one mode before :)

[Dark Shikari]

the display stream would have fewer i-frames (if the stream were long enough) as truncating both will make the effective average gop length shorter. honestly im ok with one mode, but i was ok with one mode before :)But I thought the whole point of "coded" mode to begin with was that it didn't need truncation? :rolleyes:

i.e. previously we had two options for Blu-ray:

Coded without truncation
Display with truncation

Now you're saying we need Coded with truncation? That's worse than both!

[shon3i]

That encoder benefits from a GUI. I cant force someone to type in 45No but you can use typed value and subtract by number of bframes :)

But truncating display and coded is better solution, since working in previous revisions.

Please check when is qpfile used aslo.

[Trahald]

http://pastebin.org/364480 Can someone make a binary for testing. The option on this patch is --open-GOP "bluray"

[Trahald]

http://www.mediafire.com/?mny22nymrim is a test binary.. please test against anything bluray you have. its a very basic build.

[shon3i]

It's ok now. Muxing passes without "Illegal EPMAP" warnings, verification is passed. On all sources.

x264.exe --tune film --bitrate 4507 --pass 2 --stats Output.264.x264-stats --level 4.1 --ref 4 --bframes 3 --aud --nal-hrd vbr --b-pyramid strict --open-gop bluray --keyint 48 --vbv-maxrate 15000 --vbv-bufsize 30000 --sar 1:1 --slices 4 --output Output.264 Input.avs

[Emulgator]

Good work !

[sneaker_ger]

I have a few questions concerning open-gop. Apparently CoreAVC has problems seeking on streams created with the new --open-gop option. Neuron2 said that it would probably have to request the preceding gop, but I do not understand why. Here's what I thought was true (until now):
1.) x264 has been using non-IDR-i-frames for quite some time now but I see no reports of CoreAVC having seeking problems on those streams. But aren't information of preceding gops necessary for those? Probably not only a single gop but also multiple gops when the gops are very short? (at least in theory?)
2.) the new open-gop option deletes the reference list after the last b-frame, so shouldn't it be unnecessary to have access to the preceding gop? I thought that was the reason the i frames are flagged as recovery point to begin with?

[LoRd_MuldeR]

With OpenGOP you have B-Frames right before the I(DR) Frame. In display order that looks like:
IBBBPBBBPBBBIBBBPBBBP...

But in decoding order, which is how the frames are stored in the file, that would look like this:
IPBBBPBBBIBBBPBBBPBBB...

So those B-Frames that are located after the I-Frame (in decoding order), but they make reference to the I-Frame and to the P-Frame from the previous GOP.

What I don't understand is:
In display order those B-Frames are before the I-Frame. Hence if we start playback at the I-Frame, they are "obsolete" already. Why not skip them entirely?

[sneaker_ger]

Ok, if he meant previous gop in coded order it totally makes sense. Totally overlooked that. But on such a sequence:
PPPPPiPPPPP ("i" as non-IDR-i-frame)
wouldn't it also be necessary to decode frames from the previous gop first? Aren't such streams created even without open-gop?

As to the "obsolete" question: that's also what I am thinking and I guess we are correct. That's why they get flagged as recovery points.

[LoRd_MuldeR]

Ok, if he meant previous gop in coded order it totally makes sense. Totally overlooked that. But on such a sequence:
PPPPPiPPPPP ("i" as non-IDR-i-frame)
wouldn't it also be necessary to decode frames from the previous gop first? Aren't such streams created even without open-gop?

Well, if the I-Frame is a Non-IDR I-Frame, then we have to decode the frames before the I-Frame, as the None-IDR I-Frame doesn't flush the reference buffer and thus frames after the I-Frame (in display order) may reference to frames before the I-Frame. But that's nothing specific to OpenGOP. The same applies to all Non-IDR I-Frames, even when OpenGOP is not used. Also, in my understanding, a GOP goes from an IDR-Frame to an IDR-Frame, i.e. None-IDR I-Frames are not GOP delimiters. Not sure what the "official" definition is here.

BTW: As far as I know, x264 always used to put a Non-IDR when a scene-cut is detected, but the minimum key-frame interval isn't reached yet...

[sneaker_ger]

Well, if the I-Frame is a Non-IDR I-Frame, then we have to decode the frames before the I-Frame, as the None-IDR I-Frame doesn't flush the reference buffer and thus frames after the I-Frame (in display order) may reference to frames before the I-Frame. But that's nothing specific to OpenGOP. The same applies to all Non-IDR I-Frames, even when OpenGOP is not used.

That's why it was bugging me that some devs were talking about reading the previous gop as something special why from my understanding it was necessary all along.

Also, in my understanding, a GOP goes from an IDR-Frame to an IDR-Frame, i.e. None-IDR I-Frames are not GOP delimiters. Not sure what the "official" definition is here.

Then open-gop wouldn't really be open gop, would it? But ok, the term might just be a "tradition" coming from older standards.

[neuron2]

There are cases other than IDR where you do not have to go back a GOP. E.g.:

Recovery point SEI
non-IDR I picture
...

The sample posted earlier in the thread places recovery points before the non-IDR I pictures as above. In fact, in the very first post Trahald states that is what the "open GOP" patch does. I do not consider those to be open GOPs! For me a GOP is open if you have to go back a GOP to decode without errors.

The decision whether to go back is quite tricky. I see it like this (coding order):

IDR starts closed GOP.
RPS+I starts closed GOP.
I P B starts closed GOP. (This is the controversial one. Theoretically not so, but practically yes.)
I B P starts open GOP.

For me a GOP is just a sequence of pictures starting with IDR/I and it is seekable without going back if it is closed.

[sneaker_ger]

The decision whether to go back is quite tricky. I see it like this (coding order):

RPS+I starts closed GOP.

But the open-gop option of x264 uses recovery points on the open gops, so if you seek to a b-frame in a gop that starts with RPS+I we will still need information from the previous gop.

This hole debate is a real mess when we do not have a common opinion on the definition of a gop (and/or forget to mention whether we're talking coded or display order). Is there any definition in the h.264 standard?

[neuron2]

But the open-gop option of x264 uses recovery points on the open gops, so if you seek to a b-frame in a gop that starts with RPS+I we will still need information from the previous gop. The RPS declares that you do not need previous information.

[Trahald]

blurays definition of open-gop says this
1. the first frame in decode order must be a non-idr i frame and the frames that proceed it in display order are allowed to reference forward and backward. these frames cannot be correctly decoded during a random seek and are skipped.
2. frames after the non idr i-frame in display order must NOT reference frames prior to the i-frame in display order.

recovery points are not mentioned. (and there is plenty of room for a 'shall not' if that were the intent)

the frames in 1. are always b frames in x264. p frames that preceed the i-frame in display order (yet follow in coded order) are allowed but x264 doesnt generate p-frames in this condition. if b-frame decision decides that b-frames arent needed following the iframe in display order, that gop will essentially be closed (again based on blurays definition). The command open gop is ignored when --bframes == none.



blurays definition of open gop is the only one i know of. I modeled its behavior after AVC blurays.

[RBO]

I'm going to go way out on a unfounded claim, and say it's an open-gop related issue.
FYI, h264 open-GOPs feature withing MP4 (MPEG4 part 12 spec) is not specified enough. There have been propositions at MPEG in 2010 to provide a solution. The problem comes from the collusion between RAP and sync points.

The compliant solution is implemented in GPAC. However it is not usable as seeking big files takes a lot of time. x264 (with GPAC MP4 support) marks all key frames as sync points, which is less compliant but practically allows you to seek within the file flawlessly.

Practically, I would advise you to create your MP4 files using x264, and then adding your audio with:
mp4box -add my_audio.xxx my_h264_muxed_with_x264.mp4

We are waiting the normalization decision from MPEG.

Romain

[kypec]

Practically, I would advise you to create your MP4 files using x264, and then adding your audio with:
mp4box -add my_audio.xxx my_h264_muxed_with_x264.mp4

Are you suggesting to create raw H264 streams in x264? :confused:Because that's what I was doing since I started to work with x264 CLI.

[kieranrk]

The compliant solution is implemented in GPAC. However it is not usable as seeking big files takes a lot of time. x264 (with GPAC MP4 support) marks all key frames as sync points, which is less compliant but practically allows you to seek within the file flawlessly.


Why should the container care about the underlying gop structure? Surely it's a job for the decoder to ignore b-frames from the previous gop.

[VFR maniac]

According to 14496-15, sync samples are just IDR-pictures, so treating a I-picture as a sync sample is out-of-spec.
(Current x264's mp4 muxer module sets key-frame (IDR or I) as sync sample.)
I think it is the better solution using sdtp box (Independent and Disposable Samples Box) for marking random access point when Open-GOP is available.

[Selur]

Are you suggesting to create raw H264 streams in x264?
No, he suggested to:
1st use x264s internal muxer to pack the videostream into a .mp4 file
2nd use mp4box to add additional streams

----

*snip*

Cu Selur

[jethro]

Practically, I would advise you to create your MP4 files using x264, and then adding your audio with:
mp4box -add my_audio.xxx my_h264_muxed_with_x264.mp4

Romain

But it does not work, unless I'm doing something wrong.


>mp4box -add The Best of Science Fiction
Movies_audio.mp4 The Best of Science Fiction Movies_video.mp4


Error - 2 input names specified, please check usage



EDIT:
SOLVED
DOH, it needed quotes around filenames...