open-gop patch for x264 (committed)

[nm]

Blu-ray: 1-2 second GOPs, AFAIK, which means you should use something like "--keyint 24 --min-keyint 1" for 24 fps video.

[juGGaKNot]

Blu-ray: 1-2 second GOPs, AFAIK, which means you should use something like "--keyint 24 --min-keyint 1" for 24 fps video.

K, blu-ray has 1-2 second gops, my uncompressed avi ( made from picture streams ) has every frame as a keyframe so the gops are at every frame right ?

so --keyint fps --min-keyint 1 for me ?

[nm]

No, you are mixing things up again. Type of the input video has nothing to do with this as LoRd_MuldeR already said. Keyint is selected to accommodate target restrictions (for example Blu-ray authoring which I mentioned above) or to keep seek intervals sane (people usually like < 10 second skips so they set keyint=10*fps).

[G_M_C]

K, blu-ray has 1-2 second gops[...]
so --keyint fps --min-keyint 1 for me ?

OK, let's make it simple for you. When encoding for Blu-ray/AVCHD then --keyint fps (rounded to the nearest integer) --min-keyint 1 is correct.

And other then that; Forget the specifications of the source. They've got nothing to do with it. Open your source using AVISynth, and you're all set.

The only thing the source provides x264 is .... a sequence of frames.

[juGGaKNot]

No, you are mixing things up again. Type of the input video has nothing to do with this as LoRd_MuldeR already said. Keyint is selected to accommodate target restrictions (for example Blu-ray authoring which I mentioned above) or to keep seek intervals sane (people usually like < 10 second skips so they set keyint=10*fps).

Ahh, thnx, i see now.

I also see that high resolutions need leyint=fps ( 720 or just 1080 ? )

Most of the resolutions people use when encoding with my exe are under 1280x800 ( 800p is becoming standard in russia and other parts ) so 720p or less is most used

Will compressing suffer ( as stated in the wiki ) if i use low keyint for blu-ray compatibility and open gop ? ( from my first test with the only build average qp is higher by 0.20 at 1184x666 )

My settings :

--level 4.0 --sar 1:1 --aud --nal-hrd --vbv-bufsize 24000 --vbv-maxrate 24000 --ref 4 --mixed-refs --bframes 4 --b-adapt 2 --weightb --direct auto --subme 9 --trellis 2 --psy-rd 1.0:0.0 --partitions all --8x8dct --me tesa --merange 32 --fullrange on --qcomp 1 --threads auto --thread-input --aq-mode 1 --aq-strength 1 --progress --no-psnr --no-ssim --no-fast-pskip --no-dct-decimate

They may seem placebo but most of the movies encoded are in the 1-5 minute interval, 10% are in the 5-10 minutes, 1% are more than 10 minutes.

OK, let's make it simple for you. When encoding for Blu-ray/AVCHD then --keyint fps (rounded to the nearest integer) --min-keyint 1 is correct.

And other then that; Forget the specifications of the source. They've got nothing to do with it. Open your source using AVISynth, and you're all set.

The only thing the source provides x264 is .... a sequence of frames.

Yes, now i understand, as i asked nm "Will compressing suffer ( as stated in the wiki ) if i use low keyint for blu-ray compatibility and open gop ? ( from my first test with the only build average qp is higher by 0.20 at 1184x666 )"

thnx.

[Audionut]

if i use low keyint for blu-ray compatibility

Unless you're authoring blu-ray's, don't even bother with "blu-ray compatibility".

Keyint has nothing to do with resolution.

Keyint involves I-frame placement. As stated before, the defaults are used for a purpose.

min-keyint = fps of video. You generally do not want more than one I-frame in a second of video.

max-keyint = 10 x fps of video. This is based on tolerance. You could gain some compressibility by having a max-keyint of 100 x fps of video. But you wouldn't then be able to seek to any of those frames.

ie: 24fps video. max-keyint = 10 x 24 = 240. You can only seek to the first and last frames of those 240 frames. You cannot seek to any frames in between.

The best way to understand is to do some test encodes for yourself.

Use the same settings for both encodes. Set min-keyint to 25. Set scene change sensitivity to 0.
For one encode use max-keyint 250. For the other use max-keyint 2500.
Now playback both encodes and try to seek in each.


edit: and imo this discussion is way off topic.

[G_M_C]

Unless you're authoring blu-ray's, don't even bother with "blu-ray compatibility".

Keyint has nothing to do with resolution.

Keyint involves I-frame placement. As stated before, the defaults are used for a purpose.

min-keyint = fps of video. You generally do not want more than one I-frame in a second of video.

max-keyint = 10 x fps of video. This is based on tolerance. You could gain some compressibility by having a max-keyint of 100 x fps of video. But you wouldn't then be able to seek to any of those frames.

ie: 24fps video. max-keyint = 10 x 24 = 240. You can only seek to the first and last frames of those 240 frames. You cannot seek to any frames in between.

That wont give a blu-ray compliant stream

Blu-ray's have strict specifications;

Resolutions are fixed at 1920x1080, 1440x1080 (anamorphic) or 1280 x 720. All resolutions can be interlaced or not.

Framerates are guided by rules too 1080 resolutions can be either 23,976 ("24p") or 25 for progressive video or 29,97 ("60i") for interlaced & pull-down or 50i. 720p can have same rates, but also has 60p.

Encoding for blu-ray has very strict rules. The minimum keyframe rate is defined in the specification as 1. Meaning it is simply always one, and not equal to the fps as you say.

The max keyint is also defined through the max GOP length.

The max GOP length is defined as 1 second long for streams with a bitrate > 15mbps (or 2 seconds long for streams < 15 mpbs rate). Since any good blu-ray encode has a bitrates > 15 mpbs, at least in peaks, it comes down to the fact that the max key-int is always equal to the framerate (rounded to the nearest integer).

GOP==1 sec ==>
place a keyframe every 1 second ==>
--max-keyint set as fps.

[juGGaKNot]

edit: and imo this discussion is way off topic.

The end result of my questions would be uncompressed > blu-ray using open gop so i do not think i am off-topic but you are the moderator and it is your decision.

That wont give a blu-ray compliant stream

Blu-ray's have strict specifications;

Resolutions are fixed at 1920x1080, 1440x1080 (anamorphic) or 1280 x 720. All resolutions can be interlaced or not.

Framerates are guided by rules too 1080 resolutions can be either 23,976 ("24p") or 25 for progressive video or 29,97 ("60i") for interlaced & pull-down or 50i. 720p can have same rates, but also has 60p.

Encoding for blu-ray has very strict rules. The minimum keyframe rate is defined in the specification as 1. Meaning it is simply always one, and not equal to the fps as you say.

The max keyint is also defined through the max GOP length.

The max GOP length is defined as 1 second long for streams with a bitrate > 15mbps (or 2 seconds long for streams < 15 mpbs rate). Since any good blu-ray encode has a bitrates > 15 mpbs, at least in peaks, it comes down to the fact that the max key-int is always equal to the framerate (rounded to the nearest integer).

GOP==1 sec ==>
place a keyframe every 1 second ==>
--max-keyint set as fps.

Great, just what i needed.

With this i think i am done so no more off-topic.

Waiting for the next patch.

[Audionut]

That wont give a blu-ray compliant stream

Thanks Captain Obvious.


should i use --keyint 500 ? seek time is not that important.

uncompressed, open gop, --open-gop --keyint 50 --min-keyint 1 is optimal for me no ?

K, blu-ray has 1-2 second gops, my uncompressed avi ( made from picture streams ) has every frame as a keyframe so the gops are at every frame right ?

so --keyint fps --min-keyint 1 for me ?

Unless you're authoring blu-ray's, don't even bother with "blu-ray compatibility".

Personally I think you guys have talked him into thinking he needs blu-ray compatibility. Which will increase bitrate/lower quality, than if you just advised to use defaults!!!!!!!!!!!!

[juGGaKNot]

Personally I think you guys have talked him into thinking he needs blu-ray compatibility. Which will increase bitrate/lower quality, than if you just advised to use defaults!!!!!!!!!!!!

:D

I want to add a blu-ray output choice ( encode to MP4 or blu-ray[y/n] ) to the normal encode exe ( using autocrop for the resolution ) and i just wanted to know the right settings.

I use the defaults for the "non blu-ray" one.

[Trahald]

I Think he's got it now. And please gentlemen, lets keep this civil.

BTW. this thread can slide (somewhat) into bluray talk as that will be the majority of the times to use short-gop&&open-gop.

[rack04]

BTW. this thread can slide (somewhat) into bluray talk as that will be the majority of the times to use short-gop&&open-gop.

How does short-gop and open-gop benefit Blu-ray backups and playback on standalone Blu-ray players? What is the benefit of this patch for Blu-ray encoding?

[nurbs]

Read the first post. :cool:

[rack04]

Read the first post. :cool:

All I see is data supporting smaller filesizes. How will this benefit me if I'm selecting a bitrate to reach a specific filesize?

[nurbs]

Better quality at the same filesize when using short gops.

[Trahald]

Ok.. here is version 5. its redone. i cut and pasted the sei and command line stuff and recoded the rest for the most part. i set tabs to spaces in notepad++ so i didnt have to change my editing style to get good resulting diff. (why didnt anyone tell me about this ;) ) .

the patch now doesnt lie to ratecontrol, introduces MMCO to x264 to deal with p references to b frames that wouldnt be in the buffer during random access, code is cleaner.

there are a couple things i want to do with it but its nearly where i want it.
here is a diff if anyone wants to play in the interim. it will patch to latest x264. I still consider this experimental so please dont compile into anything that will get automatically downloaded.

[MatMaul]

the patch now doesnt lie to ratecontrol, introduces MMCO to x264 to deal with p references to b frames that wouldnt be in the buffer during random access, code is cleaner.

I don't understand what is MMCO but DS said it is needed in order to fix the b-pyramid/DPB problem. Does your patch can help in any way to fix this issue ?

[Trahald]

I don't understand what is MMCO but DS said it is needed in order to fix the b-pyramid/DPB problem. Does your patch can help in any way to fix this issue ?

Uhm.. I dont know what that issue is. my patch only uses mmco to protect from corrupted output in a random seek. In the context i use mmco it really is a small thing (only 1 type of command is used). mmco can be more complicated. i guess id need to hear what the problem is. If its a similar issue (b-ref needing to get killed from the dpb but maybe more often) then it would be trivial to add.

[MatMaul]

some technical infos :
http://forum.doom9.org/showthread.php?t=140223
http://forum.doom9.org/showthread.php?t=142758

[Dark Shikari]

the patch now doesnt lie to ratecontrol, introduces MMCO to x264 to deal with p references to b frames that wouldnt be in the buffer during random access, code is cleaner.I'll check the rest of your patch when I get to work today, but have you tried using MMCO simply to throw away all B-references after coding them so they don't end up in the reference list?

I suspect this will improve encoding quality.

[Trahald]

I'll check the rest of your patch when I get to work today, but have you tried using MMCO simply to throw away all B-references after coding them so they don't end up in the reference list?

I suspect this will improve encoding quality.

i can. just remove the if( opengop && first p after i) part allowing it to run after every p frame (checking to see if there are any bref in the last frame and then removing them all.) if i am understanding you correctly that would be the end of p-frames referring to b-refs. only b frames would refer to them.

And just to clarify (to anyone that cant understand the code). what it currently does is mark any b-refs in the dpb (after the i-frame) as unused for reference. This is because the patch removes the bref from the x264's reference list but the decoder would never know without mmco. That way the decoder doesnt push the i-frame out for a b-ref that wont be referred to in any future frames.

[Dark Shikari]

i can. just remove the if( opengop && first p after i) part allowing it to run after every p frame (checking to see if there are any bref in the last frame and then removing them all.) if i am understanding you correctly that would be the end of p-frames referring to b-refs. only b frames would refer to them.

And just to clarify (to anyone that cant understand the code). what it currently does is mark any b-refs in the dpb (after the i-frame) as unused for reference. This is because the patch removes the bref from the x264's reference list but the decoder would never know without mmco. That way the decoder doesnt push the i-frame out for a b-ref that wont be referred to in any future frames.Can you get on #x264dev IRC on Freenode so we can do a live patch review?

[Dark Shikari]

OK, it doesn't seem to be working at all.

With --b-adapt 0 --bframes 3 --keyint 12 --open-gop, it gives the following frame pattern:

IBBBPBBBPBBBPBBPI

Additionally, with the following qpfile:

0 I -1
1 b -1
2 b -1
3 b -1
4 i -1
5 b -1
6 b -1
7 b -1
8 i -1
9 b -1
10 b -1
11 b -1
12 i -1
13 b -1
14 b -1
15 b -1
16 i -1
17 b -1
18 b -1
19 b -1
20 i -1
21 b -1
22 b -1
23 b -1
24 i -1
25 b -1
26 b -1
27 b -1
28 i -1
29 b -1
30 b -1

and --keyint 4 --bframes 3 --b-adapt 0 --frames 30, every other pair of B-frames is corrupt.

[Trahald]

I really didnt throw much at it yet. And i tried to make it clear, its not ready for a final review. (or even a preliminary one i guess ;) ) There are some things i knew had to be fixed (relatively simple stuff like second i's coming before p's) but once i figured out some of the harder stuff i get paranoid I'll get hit by a bus before i posted the work i had so far. When its closer to being really done, I'll ping you on irc in a day or 2 for a review.

[Trahald]

Here is another one. I ran many more (short) scenarios at it. Heading off to work. will visit irc tonight or maybe in the am. again. really i'd like to see it get tested real world a bit before even considering it for commit. (coding faux pas *sp*) aside.

[Dark Shikari]

Looking good:

$ for x in "x264 --open-gop" x264_old;do ./$x --bframes 3 --keyint 12 --b-adapt 0 --qp 25 SOCCER_352x288_30_orig_02.yuv -o NUL --tune psnr --psnr;done
x264 [info]: 352x288 (given by file name) @ 25.00 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: slice I:26 Avg QP:22.00 size: 17182 PSNR Mean Y:41.97 U:46.06 V:47.76 Avg:43.06 Global:42.99
x264 [info]: slice P:50 Avg QP:25.00 size: 6702 PSNR Mean Y:39.47 U:44.53 V:46.42 Avg:40.69 Global:40.57
x264 [info]: slice B:224 Avg QP:27.00 size: 2624 PSNR Mean Y:38.85 U:44.04 V:45.91 Avg:40.09 Global:40.00
x264 [info]: consecutive B-frames: 0.0% 0.0% 0.0% 100.0%
x264 [info]: mb I I16..4: 6.6% 72.2% 21.2%
x264 [info]: mb P I16..4: 3.7% 19.8% 10.5% P16..4: 25.0% 11.5% 12.2% 0.0% 0 .0% skip:17.3%
x264 [info]: mb B I16..4: 0.4% 1.7% 2.1% B16..8: 31.7% 7.9% 9.2% direct: 4.1% skip:43.0% L0:37.3% L1:41.1% BI:21.5%
x264 [info]: 8x8 transform intra:62.2% inter:52.1%
x264 [info]: coded y,uvDC,uvAC intra:94.2% 65.8% 48.0% inter:21.1% 6.5% 1.5%
x264 [info]: ref P L0 82.3% 17.7%
x264 [info]: ref B L0 93.6% 6.4%
x264 [info]: PSNR Mean Y:39.223 U:44.299 V:46.156 Avg:40.444 Global:40.286 kb/s: 913.00

encoded 300 frames, 59.27 fps, 914.11 kb/s
x264 [info]: 352x288 (given by file name) @ 25.00 fps
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: slice I:25 Avg QP:22.00 size: 17215 PSNR Mean Y:41.99 U:46.05 V:47.74 Avg:43.07 Global:43.00
x264 [info]: slice P:75 Avg QP:25.00 size: 6515 PSNR Mean Y:39.37 U:44.44 V:46.35 Avg:40.59 Global:40.48
x264 [info]: slice B:200 Avg QP:27.00 size: 2576 PSNR Mean Y:38.65 U:43.91 V:45.80 Avg:39.89 Global:39.81
x264 [info]: consecutive B-frames: 0.0% 0.0% 27.3% 72.7%
x264 [info]: mb I I16..4: 6.2% 72.8% 21.1%
x264 [info]: mb P I16..4: 3.3% 18.3% 9.6% P16..4: 28.3% 12.0% 13.1% 0.0% 0 .0% skip:15.4%
x264 [info]: mb B I16..4: 0.3% 1.6% 1.9% B16..8: 32.4% 7.7% 9.0% direct: 4.0% skip:43.1% L0:39.6% L1:39.2% BI:21.2%
x264 [info]: 8x8 transform intra:62.6% inter:53.6%
x264 [info]: coded y,uvDC,uvAC intra:94.1% 65.3% 47.7% inter:22.9% 7.3% 1.7%
x264 [info]: ref P L0 77.2% 14.1% 8.7%
x264 [info]: ref B L0 94.1% 5.9%
x264 [info]: PSNR Mean Y:39.108 U:44.225 V:46.099 Avg:40.333 Global:40.165 kb/s: 956.07

encoded 300 frames, 59.44 fps, 957.00 kb/s

[Trahald]

Here is the next revision. Adds code to tighten up max frame_num/lsb calc DS wrote. addressed mp4/mkv as output formats (flagging keyframes) when opengop is used. Since the formats dont really support RP (well i should say players that play the files ) you will get a couple of corrupted frames when you seek. this is not a bug.
Now an issue.. i get issues with mpchc w/dxva. powerdvd using hardware acceleration works fine, and every other player i tried the streams on, including my xbox 360. all worked ok. Im not sure if its a bug in mpchc or the patch. please test on standalones too.

[Dark Shikari]

p_mp4->p_sample->IsRAP = p_picture->i_type == X264_TYPE_IDR
+ || ( p_picture->i_type == X264_TYPE_I && p_mp4->b_open_gop ) ? 1 : 0;This is broken.

Not all I-frames are seekable, even with opengop. You need to add an extra entry to x264_picture_t named "b_keyframe" and use that instead, as I told you on IRC.

It should be:p_mp4->p_sample->IsRAP = p_picture->b_keyframe;

Also, if your patch does break the ability to place non-key I-frames, it will be instantly rejected.

[Old Timer]

Just an observation. With the following parameters in the command line: --keyint 24 --min-keyint 2 I can see in the resulting stats files that an i and an I frames can still be placed next to each other. Perhaps, the definition of min-keyint could be reviewed? Thanks.

Edit: added some stats data:

in:310 out:310 type:P q:25.00 tex:0 mv:0 misc:488 imb:0 pmb:0 smb:8160 d:s;
in:311 out:311 type:P q:24.99 tex:0 mv:0 misc:488 imb:0 pmb:0 smb:8160 d:s;
in:312 out:312 type:i q:20.00 tex:74105 mv:20571 misc:732 imb:8160 pmb:0 smb:0 d:s;
in:313 out:313 type:I q:16.00 tex:311354 mv:62126 misc:824 imb:8160 pmb:0 smb:0 d:s;
in:314 out:314 type:P q:20.98 tex:439703 mv:72472 misc:2473 imb:5247 pmb:724 smb:2189 d:s;
in:315 out:315 type:P q:16.98 tex:1131392 mv:106473 misc:663 imb:7887 pmb:273 smb:0 d:s;

[Trahald]

As default x264 goes, a small i is just another frame. Only IDRS are considered key frames. The patch, keeping with that, considers only IDRS and RPs key frames. So you might get IDR i i(rp) i i(rp) with the patch. (recovery points only being written on the 3rd and 5th frame.) Muxers should only factor in the i(RP) that way also, well muxers that even bother to check for recovery points.

[Old Timer]

This seemed to be an intersting feature, just curious - what happened to it? Has it ever been commited into the main dev branch? Thanks.

[Trahald]

I have a patch that works with 1198. but i think something new broke it again (. once everything mbtree wise settles down, weight-p is done, open gop will go into testing / DS scrutiny soon. i'll post binaries here. When all is well hopefully its commited. Like all my patches i make stuff for myself that i want, but i like to share :).

[moviefan]

Will open-gop be Blu-ray compliant?

[Trahald]

Open GOP is allowed in bluray.

[moviefan]

Very nice!

[Old Timer]

Thanks Trahald. I have been using the build you provided in this post (http://forum.doom9.org/showthread.php?p=1299552#post1299552) to test qute a few encodes on some hardware (blu-ray player, networked media-tank, DXVA capable video-card) and they all look great. Again, thanks for the nice feature.

[klinika]

This is a patch I've been waiting for too. Can't wait to finally have some medication for the keyframe pulsing that's been making bluray compatible SD backups not very attractive. A huge thanks Trahald :)

[Trahald]

Here is a test version of the open gop patch. Its compiled with nal-hrd (with small adjustments for open gop.) i just want it to get a quick public test before i represent it to #x264dev.

x264_x86_r1373_gcc_wewk.zip (http://www.mediafire.com/?ywnzjnkz2wn)
built on Dec 12 2009, gcc: 4.4.2 (x86.generic.Komisar)

patches used
x264_hrd_pd_interlace.16_r1369.diff
x264_open_gop_11.diff

[Daemon404]

Here is a test version of the open gop patch. Its compiled with nal-hrd (with small adjustments for open gop.) i just want it to get a quick public test before i represent it to #x264dev.

x264_x86_r1373_gcc_wewk.zip (http://www.mediafire.com/?ywnzjnkz2wn)
built on Dec 12 2009, gcc: 4.4.2 (x86.generic.Komisar)

patches used
x264_hrd_pd_interlace.16_r1369.diff
x264_open_gop_11.diff

In case you missed it:

[17:34] < Daemon404> wewk: when you get back, ive foudn a bug in opengop. opengop + bframes > 0 + flv = x264 doesnt write it's header (the one with all the used params)
[17:38] < Daemon404> (apparently if the nal-hrd patch is also applied this goes away?)

[shon3i]

@Trahald, thanks, testing right now :) I hope we finaly get this into git :)

[moviefan]

Two questions:
1) What is this issue with Blu-rays and keyframe pulsing? Can someone explain this a little more in detail please?
2) Concerning Daemon404's quote: Does this issue only apply to flv encodings? If I have an AVS-script as input and output raw .264, are there any known issues or should it work?

[shon3i]

something is wrong here, MUI Generator reject stream with OpenGOP's. without specific error, just "ERROR"

[moviefan]

And what does Scenarist say?

[shon3i]

And what does Scenarist say?
"ERROR" and then MUI Generation End. as usual when stream is broken/out-of-specs

cmd i used.

"x264.exe" --tune film --bitrate 5000 --pass 2 --stats x264.stats --level 4.1 --slices 4 --vbv-bufsize 30000 --vbv-maxrate 30000 --keyint 24 --min-keyint 2 --aud --nal-hrd --open-gop --output rundown1.264 rd.avs

[moviefan]

That's really ashame... I hope it's only a minor bug. By the way: The build you probably used (the one posted in http://forum.doom9.org/showthread.php?p=1352134#post1352134) is patched with x264_hrd_pd_interlace.16_r1369.diff, not x264_hrd_pd_interlace.16_r1369_fix.diff (fixed by komisar, http://doom10.org/index.php?PHPSESSID=g4jadmsigauq1t7e08j89k4od1&topic=7.msg344#msg344). Could this be a problem?

[shon3i]

I think not becuase i encode without --open-gop with same build, and passes fine.

[moviefan]

Okay, in that case that's probably not the problem. By the way: patching x264_hrd_pd_interlace.16_r1369_fix.diff and x264_open_gop_11.diff doesn't work for some reason. Whatever patching order I choose, there is always a error. If I patch open-gop first, nal-hrd fails at hunk #8 (at 2260).

Edit:
There is a conflict with


x264_open_gop_11.diff

+static inline void bs_align_10( bs_t *s )
+{
+ if( s->i_left&7 )
+ bs_write( s, s->i_left&7, 1 << ( (s->i_left&7) - 1 ) );
+}


and


x264_hrd_pd_interlace.16_r1369_fix.diff

+static inline void bs_align_10( bs_t *s )
+{
+ if( s->i_left&7 )
+ bs_write1( s, 1 );
+ bs_flush( s );
+}
+


I just removed the open-gop version, but I don't know if that is correct. At least it compiles... Someone with insight should check it.

Edit #2:
Removing the open-gop version of the code posted above is probably not such a good idea since x264 terminates because of nal-hrd problems. (although I don't know why they occurred since I kept the nal-hrd version of the code above) Now I'm trying to encode with the open-gop code part, but I suspect this won't work either...

Edit #3:
OK, none of this works. Someone has to investigate. If I encode a patched build without --open-gop, things work.

[Sharc]

Two questions:
1) What is this issue with Blu-rays and keyframe pulsing? Can someone explain this a little more in detail please?

Blu-Ray specifies GOPs of no longer than 1 second (you will find more detailed info on this in the forum). The insertion of keyframes every 1 second may produce a 'pulsing' of the picture every second which becomes more visible for low bitrate encodes (strong compression). The pulsing can be somewhat reduced by setting --ipratio 1.1 and --pbratio 1.1 instead of the x264 default values of 1.3 and 1.4 respectively.

Added:
IIRC the --pbratio setting is overruled by mb-tree, means --pbratio is only relevant when mb-tree is disabled.

[moviefan]

OK, and what can open-gop do to improve this pulsing? By the way, I've noticed such pulsing myself because of Blu-ray restrictions, but I wasn't sure if you meant the same.

[Daemon404]

Two questions:
2) Concerning Daemon404's quote: Does this issue only apply to flv encodings? If I have an AVS-script as input and output raw .264, are there any known issues or should it work?

I've only seen it with flv output + bframes > 0 + open-gop.