References & b-pyramid?

[HD MOVIE SOURCE]

Hey, just wanted to get an idea for references and how they interact when b-pyramid is turned on.

Right now, let's imagine the GOP / keyint length is 24 for the sake of simplicity.

If I set ref=5 with b-pyramid turned off, does that mean it will only use reference frames on pframes and one iframe (obviously)?
If this is true, would that require ref to be used with at least 4 pframes per GOP to make ref=5 true?

EXAMPLE
1 (IFRAME)
2 (BFRAME)
3 (BFRAME)
4 (BFRAME)
5 (BFRAME)
6 (PFRAME)
7 (BFRAME)
8 (BFRAME)
9 (BFRAME)
10 (BFRAME)
11 (PFRAME)
12 (BFRAME)
13 (BFRAME)
14 (BFRAME)
15 (BFRAME)
16 (PFRAME)
17 (BFRAME)
18 (BFRAME)
19 (BFRAME)
20 (BFRAME)
21 (PFRAME)
22 (BFRAME)
23 (BFRAME)
24 (BFRAME)

So, to allow ref=5 to truly work as best it can, would require 4 bframes per keyint=24? Again, assuming we don't use b-pyramid?



B-PYRAMID & REFERENCE FRAME QUALITY

Now what happens if we turn on b-pyramid? Can the encoder, (essentially) use bframes as reference frames, as if they were iframes or pframes? And, does this have any impact on the final quality? Meaning, is the quality of a reference bframe as high as a reference iframe?

If ipratio=1.00 and pbratio=1.00 is set, does that mean that references, regardless of where they're applied, I, P, or B frames, those frames are always the highest possible and essentially be equal?

ALL IFRAMES

The reason I ask is that I've been running some encoding tests using all iframes and the results on this one particular frame that I'm running quality tests with was better. So, this is why I'd like to know, are all reference frames created equal?


Thanks.

[microchip8]

b-pyramid increases refs by 1. So if you have ref=4 and b-pyramid turned on, in reality the encoder will use 5 refs.

[HD MOVIE SOURCE]

b-pyramid increases refs by 1. So if you have ref=4 and b-pyramid turned on, in reality the encoder will use 5 refs.

Oh I see, so it will only use b-pyramid (reference frame) on 1 bframe per keyint?

[benwaggoner]

From the documentation (https://x265.readthedocs.io/en/master/cli.html#slice-decision-options):
--b-pyramid, --no-b-pyramid
Use B-frames as references, when possible. Default enabled

Thus --b-pyramid allows the use of reference B-frames, and thus non-reference b frames that can reference any of I, P, or B frames.

So instead of being limited to:
IbbbPbbb

It's possible to do:
IbBbPbBb

That puts the farthest b-frames a lot closer to a reference frame, reducing the residual to encode. And a B-frame can provide smaller size for the same quality than a P-frame as it can predict backwards and forwards.

Reference B-frames via --b-pyramid with --b-adapt 2 can boost compression efficiency a lot, with one of the best quality/performance tradeoffs available in x265.

[HD MOVIE SOURCE]

From the documentation (https://x265.readthedocs.io/en/master/cli.html#slice-decision-options):


Thus --b-pyramid allows the use of reference B-frames, and thus non-reference b frames that can reference any of I, P, or B frames.

So instead of being limited to:
IbbbPbbb

It's possible to do:
IbBbPbBb

That puts the farthest b-frames a lot closer to a reference frame, reducing the residual to encode. And a B-frame can provide smaller size for the same quality than a P-frame as it can predict backwards and forwards.

Reference B-frames via --b-pyramid with --b-adapt 2 can boost compression efficiency a lot, with one of the best quality/performance tradeoffs available in x265.

I noticed in your examples, B is always in between a bframe to the left and a bframe to the right. Do reference frames always require a previous bframe and an after bframe to work properly?

Though not directly responding to your post is this line of thought accurate in the example below using ref=5, and for the sake of simplicity no b-adapt.

Frame 1: I-frame, reference frame
Frame 2: B-frame, references frames 1 and 6
Frame 3: B-frame, references frames 1 and 6
Frame 4: B-frame, references frames 1 and 6
Frame 5: B-frame, references frames 1 and 6
Frame 6: P-frame, references frames 1, 2, 3, 4, and 5
Frame 7: B-frame, references frames 2 and 6
Frame 8: B-frame, references frames 2 and 6
Frame 9: B-frame, references frames 2 and 6
Frame 10: B-frame, references frames 2 and 6
Frame 11: P-frame, references frames 6, 7, 8, 9, and 10
Frame 12: B-frame, references frames 6 and 11
Frame 13: B-frame, references frames 6 and 11
Frame 14: B-frame, references frames 6 and 11
Frame 15: B-frame, references frames 6 and 11
Frame 16: P-frame, references frames 11, 12, 13, 14, and 15
Frame 17: B-frame, references frames 11 and 16
Frame 18: B-frame, references frames 11 and 16
Frame 19: B-frame, references frames 11 and 16
Frame 20: B-frame, references frames 11 and 16
Frame 21: P-frame, references frames 16, 17, 18, 19, and 20
Frame 22: B-frame, references frames 16 and 21
Frame 23: B-frame, references frames 16 and 21
Frame 24: B-frame, references frames 16 and 21

[Selur]

B is always in between a bframe to the left and a bframe to the right.
that doesn't make sense. (since that would imply you only have b-frames or you have no b-frames)
Did you mean: "P is always in between a bframe to the left and a bframe to the right." ?

[Asmodian]

Do reference frames always require a previous bframe and an after bframe to work properly?

No.


Frame 2: B-frame, references frames 1 and 6


That line of thought is not accurate. Why do you have all the B-frames only referencing two frames?

P-frames do not use B-frames as references, only other B-frames do.

[benwaggoner]

I noticed in your examples, B is always in between a bframe to the left and a bframe to the right. Do reference frames always require a previous bframe and an after bframe to work properly?
It is not a requirement, and with --b-pyramid --b-adapt 2 you'll see other patterns when they produce better efficiency.

Though not directly responding to your post is this line of thought accurate in the example below using ref=5, and for the sake of simplicity no b-adapt.

Frame 1: I-frame, reference frame
Frame 2: B-frame, references frames 1 and 6
Frame 3: B-frame, references frames 1 and 6
Frame 4: B-frame, references frames 1 and 6
Frame 5: B-frame, references frames 1 and 6
Frame 6: P-frame, references frames 1, 2, 3, 4, and 5
Frame 7: B-frame, references frames 2 and 6
Frame 8: B-frame, references frames 2 and 6
Frame 9: B-frame, references frames 2 and 6
Frame 10: B-frame, references frames 2 and 6
Frame 11: P-frame, references frames 6, 7, 8, 9, and 10
Frame 12: B-frame, references frames 6 and 11
Frame 13: B-frame, references frames 6 and 11
Frame 14: B-frame, references frames 6 and 11
Frame 15: B-frame, references frames 6 and 11
Frame 16: P-frame, references frames 11, 12, 13, 14, and 15
Frame 17: B-frame, references frames 11 and 16
Frame 18: B-frame, references frames 11 and 16
Frame 19: B-frame, references frames 11 and 16
Frame 20: B-frame, references frames 11 and 16
Frame 21: P-frame, references frames 16, 17, 18, 19, and 20
Frame 22: B-frame, references frames 16 and 21
Frame 23: B-frame, references frames 16 and 21
Frame 24: B-frame, references frames 16 and 21
This appears to not have --b-pyramid on, as then we'd see some lower-case b-frames in there. Looks like it's only --bframes 4. Using --bframes 8 or higher will improve compression efficiency and give you more interesting B/b-frame patterns.

[HD MOVIE SOURCE]

It is not a requirement, and with --b-pyramid --b-adapt 2 you'll see other patterns when they produce better efficiency.


This appears to not have --b-pyramid on, as then we'd see some lower-case b-frames in there. Looks like it's only --bframes 4. Using --bframes 8 or higher will improve compression efficiency and give you more interesting B/b-frame patterns.

Okay, I see, thanks.

[benwaggoner]

--b-adapt 2 also yield more dynamic and optimized b-frame placement.

Using --preset slower turns on all that stuff.

[HD MOVIE SOURCE]

--b-adapt 2 also yield more dynamic and optimized b-frame placement.

Using --preset slower turns on all that stuff.

So does b-adapt work with b-pyramid too? Or does b-adapt only work with picking a pframe vs picking a bframe?
If this is the case, you could just pick 8 bframes, and let b-adapt take care of it? Or maybe even more bframes, and it should also pick the correct amount to use based on quality right?

So, does it chose a p, b or pyramid B based on QP quality? Basically, it will always use the one that uses the lowest QP, which would be the highest quality? Is that how it's choosing when to use b-adapt?

The reason I'm asking about b-adapt is that I've typically used b-adapt=0 because I've wanted to control the bframes better. If b-adapt has an interaction with b-pyramid too, then I've probably been missing out.

You have to directly answer this, but do most streaming services use b-adapt=2 do you think? Is this how they're able to get more from less bit-rates?

[benwaggoner]

So does b-adapt work with b-pyramid too? Or does b-adapt only work with picking a pframe vs picking a bframe?
Yes, the absolutely work together to provide additive benefits.

If this is the case, you could just pick 8 bframes, and let b-adapt take care of it? Or maybe even more bframes, and it should also pick the correct amount to use based on quality right?
Correct. With b-adapt, --bframes specifies the maximum sequential b-frames; it will pick less in many cases.

So, does it chose a p, b or pyramid B based on QP quality? Basically, it will always use the one that uses the lowest QP, which would be the highest quality? Is that how it's choosing when to use b-adapt?
It's more complex than that, with lots of rate control factors, impact from cu-tree, etc. It picks the optimal frame type sequences that yields the best net results.

The reason I'm asking about b-adapt is that I've typically used b-adapt=0 because I've wanted to control the bframes better. If b-adapt has an interaction with b-pyramid too, then I've probably been missing out.
Indeed you are! Having more control than b-adapt means manually writing a qpfile to specify the frame types you want. Turning b-adapt off means there's no adaptation happening at all, which results in worse encoding without any upside.

You have to directly answer this, but do most streaming services use b-adapt=2 do you think? Is this how they're able to get more from less bit-rates?
Some might use --b-adapt 1. But any premium streaming serveice is going to be using some sort of adaptive frame type selection. The benefits are way too big to ignore. Not using b-adapt would be like turning off in-loop deblocking.

[HD MOVIE SOURCE]

Yes, the absolutely work together to provide additive benefits.


Correct. With b-adapt, --bframes specifies the maximum sequential b-frames; it will pick less in many cases.


It's more complex than that, with lots of rate control factors, impact from cu-tree, etc. It picks the optimal frame type sequences that yields the best net results.


Indeed you are! Having more control than b-adapt means manually writing a qpfile to specify the frame types you want. Turning b-adapt off means there's no adaptation happening at all, which results in worse encoding without any upside.


Some might use --b-adapt 1. But any premium streaming serveice is going to be using some sort of adaptive frame type selection. The benefits are way too big to ignore. Not using b-adapt would be like turning off in-loop deblocking.

I really appreciate the feedback, it's very interesting.

Let's imagine we had a 24-frame GOP and we used 8 frames. if I used b-pyramid with b-adapt=0. Would it place the B reference frames randomly if I used ref=5?

i BBbbbbbb p bbbbbbbb p bbbbb

Would an encode ever choose to use back-to-back B references like this? I would assume not, but with b-adapt=0, I wonder what it does.

So the whole point of b-adapt is to make sure that the B reference frames go the correct parts for higher quality?

Is b-adapt=2 simply always better at doing this or can it be content based? Does b-adapt=1 also choose where to place B-references?

Here's an interesting question, would a B reference frame ever be chosen for a scene cut instead of an Iframe to save bandwidth? Or would that always be an Iframe?

Thanks.

[Boulder]

I've only seen the combinations "IPBbb.." or "..bbPBbb.." with b-adapt 2.

[benwaggoner]

So the whole point of b-adapt is to make sure that the B reference frames go the correct parts for higher quality?
Precisely. With b-adapt zero is uses a fixed pattern per --bframes irrespective of what would be a better match with the content.

Is b-adapt=2 simply always better at doing this or can it be content based? Does b-adapt=1 also choose where to place B-references?[QUOTE]
Yes, b-adapt 1 and 2 are both adaptive b-frame algorithms. b-adapt 2 is somewhat better and quite a bit slower, especially as --bframes goes up.

[QUOTE]Here's an interesting question, would a B reference frame ever be chosen for a scene cut instead of an Iframe to save bandwidth? Or would that always be an Iframe?
I suppose it would be possible if the before or after shots were efficiently references from that frame. Places where a B-frame's ability to reference a future frame makes a big difference.

but 99.9% of the time it'll be an IDR or I. And most of the time it's not, it'd be a P-frame. the kind of scene change example is extremely rare if not purely hypothetical.

[HD MOVIE SOURCE]

Precisely. With b-adapt zero is uses a fixed pattern per --bframes irrespective of what would be a better match with the content.

[QUOTE]Is b-adapt=2 simply always better at doing this or can it be content based? Does b-adapt=1 also choose where to place B-references?[QUOTE]
Yes, b-adapt 1 and 2 are both adaptive b-frame algorithms. b-adapt 2 is somewhat better and quite a bit slower, especially as --bframes goes up.


I suppose it would be possible if the before or after shots were efficiently references from that frame. Places where a B-frame's ability to reference a future frame makes a big difference.

but 99.9% of the time it'll be an IDR or I. And most of the time it's not, it'd be a P-frame. the kind of scene change example is extremely rare if not purely hypothetical.

Interesting, do you know the fixed pattern per --bframe?
To keep it simple use a 24-frame keyint, and 8 bframes, how would b-pyramid distribute B frames in that situation with ref=5? Is there a logical pattern that it uses?

[benwaggoner]

Interesting, do you know the fixed pattern per --bframe?
To keep it simple use a 24-frame keyint, and 8 bframes, how would b-pyramid distribute B frames in that situation with ref=5? Is there a logical pattern that it uses?
I'm not sure what it is, but you can figure it out yourself easily enough.

Probably something like IbbBbbBbbP or IbbbBbbbbP?

[HD MOVIE SOURCE]

I'm not sure what it is, but you can figure it out yourself easily enough.

Probably something like IbbBbbBbbP or IbbbBbbbbP?

Thanks.

[HD MOVIE SOURCE]

I'm not sure what it is, but you can figure it out yourself easily enough.

Probably something like IbbBbbBbbP or IbbbBbbbbP?

When b-adapt and b-pyramid are being used, does that make it so the encoder would choose to place a pframe in place of a bframe if the quality would be higher? But, thinking about it, pframes cost more. Is this something to ever think about, or is it figured into your bit-rate settings? And the goal is the highest quality within whatever bit-rate restrictions are being used?

So basically, does using b-adapt actually make you use more bit-rate? That is my question.

On the flipside of that question, does using b-pyramid actually help save bit-rate? So instead of using a pframe as reference it will use a Bframe and save data?

Just some thoughts I've been having.

[benwaggoner]

When b-adapt and b-pyramid are being used, does that make it so the encoder would choose to place a pframe in place of a bframe if the quality would be higher? But, thinking about it, pframes cost more. Is this something to ever think about, or is it figured into your bit-rate settings? And the goal is the highest quality within whatever bit-rate restrictions are being used?

So basically, does using b-adapt actually make you use more bit-rate? That is my question.

On the flipside of that question, does using b-pyramid actually help save bit-rate? So instead of using a pframe as reference it will use a Bframe and save data?
Using --b-adapt and --b-pyramid both improve compression efficiency, so improving quality at a given bitrate and reducing file size when using --crf.

Both allow more flexibility in picking optimum frame types, so the encoder has better options.They're mainly a quality/speed tradeoff thing. You can see this by which are turned in the different presets (https://x265.readthedocs.io/en/master/presets.html#presets).

[HD MOVIE SOURCE]

Using --b-adapt and --b-pyramid both improve compression efficiency, so improving quality at a given bitrate and reducing file size when using --crf.

Both allow more flexibility in picking optimum frame types, so the encoder has better options.They're mainly a quality/speed tradeoff thing. You can see this by which are turned in the different presets (https://x265.readthedocs.io/en/master/presets.html#presets).

Thanks.

So I've been fine-tuning Sol Levante from Netflix using 4K uhd-bd restrictions (for fun), and I've finally been able to get rid of some artifacts using this method. I think it was a combination of --b-adapt, --b-pyramid, --aq-mode, --psy-rd, --psy-rdoq, and --rdoq-level=2. Optimizing all of these made it completely artifact-free.

You could never see the artifacts when watching normally, so this optimization was completely over-the-top, but it felt good getting it to look as good as I could. I captured 1 screenshot that previously had artifacts and breakdown. I zoomed in to the new encode and the artifacts were completely gone.

I inspected the file using Avidemux, and it's interesting how it distributes bframes and pframes. Basically, under fast-moving scenes it would sometimes use back-to-back pframes, and only a couple of bframes. If, at any point scenes repeated for a while or were slow it would use more bframes, and fewer pframes. I have seen it where it used 3 pframes, 2 bframes, and right back to a pframe under a crazy high movement scene.

Having adaptive bframes is incredibly good, it really has picked up the quality, and I couldn't see the difference between the prores file vs the encode even when zooming into shots with this method.

I picked some scenes that repeat more, and sometimes it can use around 7 bframes, but rarely uses the full 8 bframes that I set. But, on slower content where frames repeat a lot, I can see that this really would get more quality out of animation. Maybe on animations like The Boxtrolls where backgrounds constantly repeat and the only thing that changes is the characters animating, it would be incredible for that too.


Some extra info
HB x265 [info]: frame I: 288, Avg QP:8.38 kb/s: 85705.13
HB x265 [info]: frame P: 1524, Avg QP:7.27 kb/s: 85089.15
HB x265 [info]: frame B: 4502, Avg QP:7.99 kb/s: 64369.76
HB x265 [info]: Weighted P-Frames: Y:6.7% UV:5.8%
HB x265 [info]: Weighted B-Frames: Y:10.9% UV:9.6%

70343.93 kb/s, Avg QP:7.84

That's the lowest average QP I've ever gotten with this encode using a maxrate of 98 Mbps.

[benwaggoner]

I'd love to see the command line you'd used.

[HD MOVIE SOURCE]

I'd love to see the command line you'd used.

I use Vidcoder so the code is written this way.

uhd-bd=1:no-open-gop:min-keyint=1:keyint=24:rc-lookahead=24:lookahead-slices=0:vbv-maxrate=98000:vbv-bufsize=99000:no-fast-intra:ref=5:limit-refs=0:limit-modes=0:aq-mode=3:aq-strength=1.7:bframes=8:b-adapt=2:b-intra:b-pyramid:weightb:weightp:ipratio=1.00:pbratio=1.00:subme=7:no-deblock:no-sao:no-strong-intra-smoothing:psy-rd=0.00:psy-rdoq=0.04:rdoq-level=2:no-cutree:rect:amp:hme:tskip:rskip=0:no-early-skip:rd=6:limit-tu=0:no-info

Placebo with a CRF=0.
Bit-rates are still controlled with vbv-maxrate=98000:vbv-bufsize=99000

My final encode is linked here: https://archive.org/details/sol-levante-2020-4k-hdr-10-netflix-short-x265

Mine is the MKV file, it's 2.2GB, let me know what you think please.

This is the best settings for grainless animation that I could find, and the lowest Avg QP was 7.84. So, this type of quality could be achieved on 4K Ultra HD Blu-ray. You just intense compute levels, LOL. I think it's time for me to upgrade to a workstation or something.

[benwaggoner]

CRF 0 is insanely beyond visually lossless. I've never seen a difference between --crf 12 and anything lower.

[HD MOVIE SOURCE]

CRF 0 is insanely beyond visually lossless. I've never seen a difference between --crf 12 and anything lower.

I've never tried going higher. I just let my bandwidth cap take care of going too high in bit-rate, and that only happens on scenecuts, and high-motion scenes. Believe it or not though, CRF doesn't really waste bits. Like, end credits, for example, will only use 3 to 5 Mbps there. I've seen instances where bit-rates go as low as 40 Mbps. So, it will only use as much as it needs, which is why I like it.

I tested using no-scenecut and actually got better results on another encode. Think this is because I'm allowing p and b frames to be used as reference? So, typically an iframe is used for a scenecut, but now I see it's using a p or b frame. I'm using Avidemux to see where p and b frames are placed, but I'm not able to see if they were used as reference frames. My assumption is that they are, and that's why there was a quality increase.

Oddly enough I found this method due to testing an encode on very fast and saw that it didn't use a scenecut. Tested it again with normal settings and using no-scenecut was better. It's actually a bit-rate saver too because Im not using as many iframes which is really nice. I wonder if streaming services do this so they can avoid as many iframes as possible but retain good picture quality. In reality, streaming services could set their keyint to the maximum, use as many reference frames as possible, use b-adapt, b-pyramid, and as many bframes as possible, and you save massive amounts of data, and you should be able to retain very good picture quality with that method I think.

[benwaggoner]

I wonder if streaming services do this so they can avoid as many iframes as possible but retain good picture quality. In reality, streaming services could set their keyint to the maximum, use as many reference frames as possible, use b-adapt, b-pyramid, and as many bframes as possible, and you save massive amounts of data, and you should be able to retain very good picture quality with that method I think.
In premium streaming scenarios I've looked at, a fixed GOP duration is only used to simplify adaptive streaming segments. What that's not a requirement, aligning IDRs with edits improves compression efficiency quite a lot. The behavior you describe is unusual.

[HD MOVIE SOURCE]

In premium streaming scenarios I've looked at, a fixed GOP duration is only used to simplify adaptive streaming segments. What that's not a requirement, aligning IDRs with edits improves compression efficiency quite a lot. The behavior you describe is unusual.

Yeah, I'm going to test some more with this. I've been mostly encoding trailers, and trailers have tons of scenecuts. The issue with this is that x265 is constantly using iframes because of this. My attempt of using no-scenecut was to alleviate this, and because reference frames can be used as b and p frames, it looks to have worked.

Again, this is under a uhb-bd=1 restriction, so there would be a keyint every 24 frames anyway. I think this is why it has actually helped achieve lower QP values because fewer iframes are being used, that's less data, and the quality of P frames and b frames are so good still. b-adapt=2, b-intra, b-pyramid, weightb, and weightp make p and b frames exceptionally good quality.

Hey, that's the thought anyway, LOL. Seems to be working with a restricted keyint.

[benwaggoner]

Yeah, I'm going to test some more with this. I've been mostly encoding trailers, and trailers have tons of scenecuts. The issue with this is that x265 is constantly using iframes because of this. My attempt of using no-scenecut was to alleviate this, and because reference frames can be used as b and p frames, it looks to have worked.
There's no real downside to using an iframe instead of an IDR from a compression efficiency perspective, and sometimes there are slight benefits.

Again, this is under a uhb-bd=1 restriction, so there would be a keyint every 24 frames anyway. I think this is why it has actually helped achieve lower QP values because fewer iframes are being used, that's less data, and the quality of P frames and b frames are so good still. b-adapt=2, b-intra, b-pyramid, weightb, and weightp make p and b frames exceptionally good quality.
At super high bitrates lots of things matter less. Still, I wouldn't expect fixed GOP to ever improve quality. Maybe your keyint sensitivity needs some tuning?

[HD MOVIE SOURCE]

There's no real downside to using an iframe instead of an IDR from a compression efficiency perspective, and sometimes there are slight benefits.


At super high bitrates lots of things matter less. Still, I wouldn't expect fixed GOP to ever improve quality. Maybe your keyint sensitivity needs some tuning?

It's possible yes.

Just to clear some things up that I potentially might have misunderstood. By using --ref=5, does that mean a reference frame can be used with a B or P frame? If so, is the quality of a B reference frame ever as good as a true reference iframe? If reference frame quality differs when using a B or P frame then I've thought about a way to counter this.

Even though I've now switched to b-adapt, one other method I've been thinking about is using a locked bframe method with my thoughts about ref=5.
Like this...

24 frames long...
i
bbb
p
bbb
p
bbb
p
bbb
p
bbb
p
bbb

With this method, you'd turn off b-pyramid, and that would mean all P frames would be used as reference frames. That would then offer enough information to pretty much every bframe and possibly keep the quality higher?

This is considering that reference frame quality is not equal over I, P, and B frames, and why it's potentially better on 4K Blu-ray for instance, to do it this way. Just something I've been thinking about recently after seeing how many bframes companies like Sony use on their 4Ks, which is relatively low. I've seen them use 4 bframes on a transfer and it looked absolutely incredible. Thats kinda where this idea came from. Basically, you control where all your reference frames will go if you get the bframe count exactly right.

I think this is certainly interesting. Especially being locked to 24 frame GOPs. If the first b frame references the iframe, it will look great. If the last bframe reference the pframe it will look great, and the bframe in the middle can reference the previous bframe and the bframe in front of it, which are coming from 2 reference points. In my head it sounds right, but is it? LOL

Thanks.

[benwaggoner]

Just to clear some things up that I potentially might have misunderstood. By using --ref=5, does that mean a reference frame can be used with a B or P frame?[QUOTE]
--ref 5 means there can be a maximum of 5 decoded pictures buffered for frames to reference. All you need is --ref 2 to get B-frames, and --ref 1 for P-frames. IDR-only would be "--ref 0" as no frames reference each other.

[QUOTE]If so, is the quality of a B reference frame ever as good as a true reference iframe? If reference frame quality differs when using a B or P frame then I've thought about a way to counter this.
Sure they can be every bit as good. There was some interesting research about using ONLY B-frames a while back. "Generalized B-frames" IIRC. In older codecs there were things that B-frames couldn't do, like being intra-coded, but I don't recall any material limitations to B-frames in HEVC.

Even though I've now switched to b-adapt, one other method I've been thinking about is using a locked bframe method with my thoughts about ref=5.
Like this...

24 frames long...
i
bbb
p
bbb
p
bbb
p
bbb
p
bbb
p
bbb

With this method, you'd turn off b-pyramid, and that would mean all P frames would be used as reference frames. That would then offer enough information to pretty much every bframe and possibly keep the quality higher?
This would provide worse results at a given bitrate than using --b-adapt. For content where your fixed pattern would be optimal, --b-adapt 2 should pick that anyway.

This is considering that reference frame quality is not equal over I, P, and B frames, and why it's potentially better on 4K Blu-ray for instance, to do it this way. Just something I've been thinking about recently after seeing how many bframes companies like Sony use on their 4Ks, which is relatively low. I've seen them use 4 bframes on a transfer and it looked absolutely incredible. Thats kinda where this idea came from. Basically, you control where all your reference frames will go if you get the bframe count exactly right.
Ah! The bframe count is the maximum, and shorter values will be used if optimal. . If the content is best encoded as PbP, it will be. If it is better PbBbbbbbP, it will be.

I think this is certainly interesting. Especially being locked to 24 frame GOPs. If the first b frame references the iframe, it will look great. If the last bframe reference the pframe it will look great, and the bframe in the middle can reference the previous bframe and the bframe in front of it, which are coming from 2 reference points. In my head it sounds right, but is it? LOL
The encoder's job is to make sure all frames look great, and to optimize quality between different reference levels to provide that consistent quality.
If you find a better algorithm to pick which frames should be what type, and what QP, that can be done with a qpfile.

[HD MOVIE SOURCE]

[QUOTE=HD MOVIE SOURCE;1987287]Just to clear some things up that I potentially might have misunderstood. By using --ref=5, does that mean a reference frame can be used with a B or P frame?[QUOTE]
--ref 5 means there can be a maximum of 5 decoded pictures buffered for frames to reference. All you need is --ref 2 to get B-frames, and --ref 1 for P-frames. IDR-only would be "--ref 0" as no frames reference each other.


Sure they can be every bit as good. There was some interesting research about using ONLY B-frames a while back. "Generalized B-frames" IIRC. In older codecs there were things that B-frames couldn't do, like being intra-coded, but I don't recall any material limitations to B-frames in HEVC.


This would provide worse results at a given bitrate than using --b-adapt. For content where your fixed pattern would be optimal, --b-adapt 2 should pick that anyway.


Ah! The bframe count is the maximum, and shorter values will be used if optimal. . If the content is best encoded as PbP, it will be. If it is better PbBbbbbbP, it will be.


The encoder's job is to make sure all frames look great, and to optimize quality between different reference levels to provide that consistent quality.
If you find a better algorithm to pick which frames should be what type, and what QP, that can be done with a qpfile.


When using b-adapt, is there a way to control how to use bframes? I mean the quality of the frames. Is there a way to set it up to where bframes will only be chosen if the pframe is of lower quality?
I think it's called frame bias, I've never used it, but like I've said. Is there an absolute way where it will only use a bframe if the quality is better?

Example.
bframe quality = 10.0 QP
pframe quality = 9.99 QP

I know the quality is tiny. but what bframe bias setting would allow this type of decision to be made?

One of the reasons I'm asking is that I've been thinking about quality thresholds. Does the default bframe bias allow more bframes to be used under a certain level of loss? If the bframe quality was only say 5% less quality than the pframe, would it still use the bframe because it's cheaper, from a bandwidth perspective?

Is the bframe bias setting the same in x264, because this is where I noticed this? In x264 if you use b-adapt with 3 bframes, the quality is slightly worse than simply using 1 bframe. So, the algorithm by default is favoring bframes at the expense of absolute quality. I'd like to fix this if possible by only using a bframe if it is higher quality than using a pframe.

[benwaggoner]

When using b-adapt, is there a way to control how to use bframes? I mean the quality of the frames. Is there a way to set it up to where bframes will only be chosen if the pframe is of lower quality?
I think it's called frame bias, I've never used it, but like I've said. Is there an absolute way where it will only use a bframe if the quality is better?

Example.
bframe quality = 10.0 QP
pframe quality = 9.99 QP
Note that quality~QP at best. Don't look at the frame QP logs and assume you can extrapolate visual quality from just that! An encoder is trying to get an optimum consistent overall perceptual quality. It's typically optimal to shift bits from b to B, B to P, and P to I to get better references, and thus better overall quality. A non-ref b doesn't need to be a good reference but just look good, while a P needs to be a good reference AND look good. If you set --pbratio to 1.0, you'll get the same QP from both frame types, but the overall visual quality will be worse at moderate bitrates.

You can always set the frame type and QP via a qpfile.

[microchip8]

[QUOTE=benwaggoner;1987348][QUOTE=HD MOVIE SOURCE;1987287]Just to clear some things up that I potentially might have misunderstood. By using --ref=5, does that mean a reference frame can be used with a B or P frame?


When using b-adapt, is there a way to control how to use bframes? I mean the quality of the frames. Is there a way to set it up to where bframes will only be chosen if the pframe is of lower quality?
I think it's called frame bias, I've never used it, but like I've said. Is there an absolute way where it will only use a bframe if the quality is better?

Example.
bframe quality = 10.0 QP
pframe quality = 9.99 QP

I know the quality is tiny. but what bframe bias setting would allow this type of decision to be made?

One of the reasons I'm asking is that I've been thinking about quality thresholds. Does the default bframe bias allow more bframes to be used under a certain level of loss? If the bframe quality was only say 5% less quality than the pframe, would it still use the bframe because it's cheaper, from a bandwidth perspective?

Is the bframe bias setting the same in x264, because this is where I noticed this? In x264 if you use b-adapt with 3 bframes, the quality is slightly worse than simply using 1 bframe. So, the algorithm by default is favoring bframes at the expense of absolute quality. I'd like to fix this if possible by only using a bframe if it is higher quality than using a pframe.

Seriously, get your ass out of quality metrics and QP values and try to understand what the options do and how they affect perceived visual quality! Ask questions about that, not some metric or QP-value!

[HD MOVIE SOURCE]

Seriously, get your ass out of quality metrics and QP values and try to understand what the options do and how they affect perceived visual quality! Ask questions about that, not some metric or QP-value!

I have asked about that in other threads, and now I'm asking about this. I'm trying to understand how all the pieces of the puzzle fit together. Please don't tell me what I should and shouldn't ask, this is the point of a forum, to try and gain knowledge and have a conversation.

[HD MOVIE SOURCE]

Note that quality~QP at best. Don't look at the frame QP logs and assume you can extrapolate visual quality from just that! An encoder is trying to get an optimum consistent overall perceptual quality. It's typically optimal to shift bits from b to B, B to P, and P to I to get better references, and thus better overall quality. A non-ref b doesn't need to be a good reference but just look good, while a P needs to be a good reference AND look good. If you set --pbratio to 1.0, you'll get the same QP from both frame types, but the overall visual quality will be worse at moderate bitrates.

You can always set the frame type and QP via a qpfile.

Been thinking some more about references and influences. When a frame gets chosen to become a Bframe, does that mean that the quality of that frame will be higher than a typical bframe? Or, it simply means it will be used as a reference frame for other frames to reference to?

Even though bframes can be used as reference frames, are there scenarios where it will still only choose pframes?

Is it possible for pframes to be better references than bframes? How does that work?

Also, if my GOP is 24 frames long, and my lookahead is 24 frames long, can the encoder use the lookahead and reference the lookahead? Or in other words, use the lookahead to gather even more information than the currently available references?
I ask this, because, I've seen pframes used where scenecuts could typically be used, but it used a pframe instead of an iframe.
I'm just wondering how it could accurately create that frame without using the lookahead?

Just to be 100% clear, when thinking about the lookahead, does it only lookahead 24 frames past the current iframe? So if there were a scenecut, the lookahead has to rebuilt, so to speak?

[benwaggoner]

Been thinking some more about references and influences. When a frame gets chosen to become a Bframe, does that mean that the quality of that frame will be higher than a typical bframe? Or, it simply means it will be used as a reference frame for other frames to reference to?
A lot of this gets into encoder-specific implementations and parameter tweaks. A reference B-frame doesn't intrinsically "know" it's a reference, and may be encoded before that decision is made. It becomes a reference frame if later frames reference it. It's possible for a P or I frame to not be referenced as well, for example a flash frame.

In x265, --cutree tracks how sections of frames get used as later references, and improves the quality of blocks that are highly referenced later in the GOP, so that will naturally improve quality of any reference frame.

Even though bframes can be used as reference frames, are there scenarios where it will still only choose pframes?
B=bidirectional. If the only good references are previous frames, not future frames, might as well be a P-frame.

Is it possible for pframes to be better references than bframes? How does that work?
If being bidirectional improves compression efficiency, than you get higher quality, and thus a better reference by being a B-frame.

Also, if my GOP is 24 frames long, and my lookahead is 24 frames long, can the encoder use the lookahead and reference the lookahead? Or in other words, use the lookahead to gather even more information than the currently available references?
I ask this, because, I've seen pframes used where scenecuts could typically be used, but it used a pframe instead of an iframe.
I'm just wondering how it could accurately create that frame without using the lookahead?
Lookahead is absolutely important to figuring out optimal frame order. Without any lookahead, you couldn't use B-frames, as you wouldn't have future frames to reference! The longer the lookahead, the better the encoder knows what's happening in the future, and the better it can make frame type and VBV-aware decisions. With two otherwise identical command lines, the one with the longer lookahead will have more consistent quality and better overall quality. Note that 24 is pretty low for both GOP duration and Lookahead. Using --keyint 120 and comparing --rc-lookahead 20 and --rc-lookahead 120 you'll see some big differences with content of variable complexity. And a lot more memory usage.

Just to be 100% clear, when thinking about the lookahead, does it only lookahead 24 frames past the current iframe? So if there were a scenecut, the lookahead has to rebuilt, so to speak?
There's no fundamental reason why an encoder can't look ahead multiple GOPs. x265 doesn't, nor did x264. IIRC, that's so it doesn't look beyond the end of the forthcoming GOP, but it absolutely is looking into the next GOP. As IDR frame are so big, rate control that reflects the frames after the IDR can offer big improvements in consistency.

[HD MOVIE SOURCE]

A lot of this gets into encoder-specific implementations and parameter tweaks. A reference B-frame doesn't intrinsically "know" it's a reference, and may be encoded before that decision is made. It becomes a reference frame if later frames reference it. It's possible for a P or I frame to not be referenced as well, for example a flash frame.

In x265, --cutree tracks how sections of frames get used as later references, and improves the quality of blocks that are highly referenced later in the GOP, so that will naturally improve quality of any reference frame.


B=bidirectional. If the only good references are previous frames, not future frames, might as well be a P-frame.


If being bidirectional improves compression efficiency, than you get higher quality, and thus a better reference by being a B-frame.


Lookahead is absolutely important to figuring out optimal frame order. Without any lookahead, you couldn't use B-frames, as you wouldn't have future frames to reference! The longer the lookahead, the better the encoder knows what's happening in the future, and the better it can make frame type and VBV-aware decisions. With two otherwise identical command lines, the one with the longer lookahead will have more consistent quality and better overall quality. Note that 24 is pretty low for both GOP duration and Lookahead. Using --keyint 120 and comparing --rc-lookahead 20 and --rc-lookahead 120 you'll see some big differences with content of variable complexity. And a lot more memory usage.


There's no fundamental reason why an encoder can't look ahead multiple GOPs. x265 doesn't, nor did x264. IIRC, that's so it doesn't look beyond the end of the forthcoming GOP, but it absolutely is looking into the next GOP. As IDR frame are so big, rate control that reflects the frames after the IDR can offer big improvements in consistency.

Great responses, thank you. Its interesting that what you have said has happened on a few encodes that's Ive just finished. Bframes are actually being picked in a scenecut where I chose to turn off scenecuts just to check things out. So, as you said, pframes will be used if it can reference previous frames, but if it can't then a bframe will be used, and I assume it will reference images in the lookahead.

Somebody mentioned this is one of my other posts using x264, and that's using an open-gop and still remaining compatible with Blu-ray standards. This has me thinking, if I use a keyint=24 with open-gop, if I use rc-lookahead=48, or something like that. Can Bframes reference images outside of the current GOP?
Because if you can only reference the 24 frames inside the GOP then at frame 24 the only choice would be to use a pframe because pframes can only reference what comes before it. I see this all the time from my encodes, and didn't realize why it was choosing pframes on frame 24.
But, I can't imagine not being able to reference frames outside the GOP even with a 24 frame keyint. If it can't do it, then why give the option to use open-gop?

If it can, you could in theory use a 5-second lookahead=120 much like the streamers, and gather quite a bit more information about future frames. Vs being locked into a 24 frame keyint and lookahead like Im doing right now, right?

However, I use ref=5, so does that mean I can only reference 5 frames in front of the current frame? If so, then You'd only need a 29 frame lookahead. Then you could get to frame 24 and still reference 5 frames ahead. Is that how it works?

[benwaggoner]

Great responses, thank you. It's interesting that what you have said has happened on a few encodes that's Ive just finished. Bframes are actually being picked in a scenecut where I chose to turn off scenecuts just to check things out. So, as you said, pframes will be used if it can reference previous frames, but if it can't then a bframe will be used, and I assume it will reference images in the lookahead.
It's more than a P-frame is used if there aren't good forward references, and a B-frame if there are. In HEVC, B-frames are pretty much a superset of P-frames, excepting that a P-frame is required at least every 16 frames in a GOP. A B-frame at a scene cut makes sense because the following frames are a good reference as being in the same shot.

Somebody mentioned this is one of my other posts using x264, and that's using an open-gop and still remaining compatible with Blu-ray standards. This has me thinking, if I use a keyint=24 with open-gop, if I use rc-lookahead=48, or something like that.
--rc-lookahead is limited to --keyint, alas.

Can Bframes reference images outside of the current GOP?
Because if you can only reference the 24 frames inside the GOP then at frame 24 the only choice would be to use a pframe because pframes can only reference what comes before it. I see this all the time from my encodes, and didn't realize why it was choosing pframes on frame 24.
Excepting the minor exceptions in Open GOP or --radl, no, frames can't reference frames in other GOPs. That's really the defining characteristic of a Group Of Pictures.

But, I can't imagine not being able to reference frames outside the GOP even with a 24 frame keyint. If it can't do it, then why give the option to use open-gop?
Open GOP allows the last B-frames of a GOP reference the first IDR of the next GOP. That helps reduce keyframe strobing. With --radl, the GOP can start with B-frames that reference an IDR a few frames into the GOP. Other than those, all frames can only reference frames in a GOP.

This is a big reason why we want to use higher --keyint values. DVD having a max --keyint of 14 was a serious limitation!

If it can, you could in theory use a 5-second lookahead=120 much like the streamers, and gather quite a bit more information about future frames. Vs being locked into a 24 frame keyint and lookahead like Im doing right now, right?
Not in x265. Certainly a theoretical encoder could have lookahead>>keying in a single pass, although I don't know of any that do; it really pushes up memory requirements. 2-pass encoding pretty much is lookahead=frames as the whole file is considered in rate control.

However, I use ref=5, so does that mean I can only reference 5 frames in front of the current frame? If so, then You'd only need a 29 frame lookahead. Then you could get to frame 24 and still reference 5 frames ahead. Is that how it works?
No, --ref 5 means you can have a maximum of five decoded frames retained in your decoded picture buffer at any given time. Those frames can be from much earlier in the GOP, and can include the IDR if it's pretty static content. The encoder picks the optimal 5 reference frames to preserve, and when to purge one to make room for a newer, better one.

[HD MOVIE SOURCE]

It's more than a P-frame is used if there aren't good forward references, and a B-frame if there are. In HEVC, B-frames are pretty much a superset of P-frames, excepting that a P-frame is required at least every 16 frames in a GOP. A B-frame at a scene cut makes sense because the following frames are a good reference as being in the same shot.


--rc-lookahead is limited to --keyint, alas.


Excepting the minor exceptions in Open GOP or --radl, no, frames can't reference frames in other GOPs. That's really the defining characteristic of a Group Of Pictures.


Open GOP allows the last B-frames of a GOP reference the first IDR of the next GOP. That helps reduce keyframe strobing. With --radl, the GOP can start with B-frames that reference an IDR a few frames into the GOP. Other than those, all frames can only reference frames in a GOP.

This is a big reason why we want to use higher --keyint values. DVD having a max --keyint of 14 was a serious limitation!


Not in x265. Certainly a theoretical encoder could have lookahead>>keying in a single pass, although I don't know of any that do; it really pushes up memory requirements. 2-pass encoding pretty much is lookahead=frames as the whole file is considered in rate control.


No, --ref 5 means you can have a maximum of five decoded frames retained in your decoded picture buffer at any given time. Those frames can be from much earlier in the GOP, and can include the IDR if it's pretty static content. The encoder picks the optimal 5 reference frames to preserve, and when to purge one to make room for a newer, better one.

Very interesting. DVD had 14 keyint? wow. I had no idea. Why not 12? Why not half the 24 frames? I don't really get that. Think one day they will find a workaround for being able to fast forward onto p and b frames, or must it always be on a iframe? Would it just take long if a system, or software if it had to piece together p or b frames while fast-forwarding?

If there ever was a future Physical Media Player released for 8k (which I know there won't be) it should be up to the encoder to state what keyint to use. Because being able to use a 120 keyint on disc would significantly lower bit-rates. I can dream right? LOL.

The only thing that would potentially fall is the reference quality when using a keyint that long. But, that's where scenecut comes in, so, think it would look nice. Never actually tested higher keyint values over 24. I probably should.

I will test --radl Thanks.

[benwaggoner]

Very interesting. DVD had 14 keyint? wow. I had no idea. Why not 12? Why not half the 24 frames? I don't really get that. Think one day they will find a workaround for being able to fast forward onto p and b frames, or must it always be on a iframe? Would it just take long if a system, or software if it had to piece together p or b frames while fast-forwarding?
I believe 12 was the default, but the DVD and HD-DVD specs specified a maximum GOP duration of 0.6 seconds. Those extra two frames did help reduce ABR. And it was Open GOP, thank goodness, to reduce keyframe strobing.
Only IDR frames are independently decodable, so are the best ones for random access. Some decoders do random access by following the reference hierarchy and only decoding the frames needed to decode a given frame. Decoding just P-frames is a lot lighter weight intermediate.

If there ever was a future Physical Media Player released for 8k (which I know there won't be) it should be up to the encoder to state what keyint to use. Because being able to use a 120 keyint on disc would significantly lower bit-rates. I can dream right? LOL.
On Blu-ray you can use a single-slice 2 second GOP if encoding to Level 2.0 15 Mbps peak. That said, it's not like commercial Blu-rays are hurting for space. The 50 GB was designed around MPEG-2, and no one had a clear idea of how GOOD/efficient H.264 would get over the years.
The shorter GOPs were important for optical media to make random access less painful. The latency of a random access read of an optical desk makes even a 5400 rmp HD seem incredibly spritely.

The only thing that would potentially fall is the reference quality when using a keyint that long. But, that's where scenecut comes in, so, think it would look nice. Never actually tested higher keyint values over 24. I probably should.
MPEG-2 had a serious fall off in reference quality, which is why such short GOPs were used. A big part of that is MPEG-2 used straight up floating-point DCT, not an integer iDCT which was standard by VC-1/H.264. Different decoders would do the DCT in different precision, so the longer the GOP, the bigger the gap between how different devices would decode the same frame! 14 frames of IbbP kept the max P-frames per GOP very low.

I will test --radl Thanks.
Please report your results!

[rwill]

MPEG-2 had a serious fall off in reference quality, which is why such short GOPs were used. A big part of that is MPEG-2 used straight up floating-point DCT, not an integer iDCT which was standard by VC-1/H.264. Different decoders would do the DCT in different precision, so the longer the GOP, the bigger the gap between how different devices would decode the same frame! 14 frames of IbbP kept the max P-frames per GOP very low.


Well, IEEE 1180-1990 specified the precision requirements for the IDCT. Its just that no one really cared as can be seen on older DVDs. The inaccuracies creeping in were also not really visible on CRTs, but are quite noticeable on flat monitors. There is even a test stream in the official (?) Mpeg-2 conformance package that tests IDCT accuracy over around 200 inter pictures. Mpeg-2 is fine really, its just that some people screwed up.

Oh and I think its 15 frames keyint, not 14.

[benwaggoner]

Well, IEEE 1180-1990 specified the precision requirements for the IDCT. It's just that no one really cared as can be seen on older DVDs. The inaccuracies creeping in were also not really visible on CRTs, but are quite noticeable on flat monitors. There is even a test stream in the official (?) Mpeg-2 conformance package that tests IDCT accuracy over around 200 inter pictures. Mpeg-2 is fine really, it's just that some people screwed up.
Yeah, if everyone had followed the IEEE spec it would have been fine. But once there's an installed base with an incompatibility, it's really hard to roll back from there. Like with AV1's Film Grain Synthesis. Most devices do it well know, but some early ones don't so I don't think anyone is actually using FGS. To use it one would need a way to filter out nonconformist devices and send them something else instead.

Oh and I think it's 15 frames keyint, not 14.
It was 14 relative to 24p, which was "fake" 24p with field repeat tags for DVD. HD-DVD was, IIRC, 24p with frame repeat tags to pad it out to 29.976, which was easily reversible.

[HD MOVIE SOURCE]

I believe 12 was the default, but the DVD and HD-DVD specs specified a maximum GOP duration of 0.6 seconds. Those extra two frames did help reduce ABR. And it was Open GOP, thank goodness, to reduce keyframe strobing.
Only IDR frames are independently decodable, so are the best ones for random access. Some decoders do random access by following the reference hierarchy and only decoding the frames needed to decode a given frame. Decoding just P-frames is a lot lighter weight intermediate.


On Blu-ray you can use a single-slice 2 second GOP if encoding to Level 2.0 15 Mbps peak. That said, it's not like commercial Blu-rays are hurting for space. The 50 GB was designed around MPEG-2, and no one had a clear idea of how GOOD/efficient H.264 would get over the years.
The shorter GOPs were important for optical media to make random access less painful. The latency of a random access read of an optical desk makes even a 5400 rmp HD seem incredibly spritely.


MPEG-2 had a serious fall off in reference quality, which is why such short GOPs were used. A big part of that is MPEG-2 used straight up floating-point DCT, not an integer iDCT which was standard by VC-1/H.264. Different decoders would do the DCT in different precision, so the longer the GOP, the bigger the gap between how different devices would decode the same frame! 14 frames of IbbP kept the max P-frames per GOP very low.


Please report your results!

--radl=? What value do you set it to? Can you set it to the same value as the number of bframes? I will try what is suggested in x265 documentation of 3 with an open-gop, which I believe you can use together with this setting.
If it can reference outside of the GOP, should I also increase my rc-lookahead value to 25? Because this makes it so you can look into the first frame of the next GOP right?

I wonder if --radl is compatible with 4K Disc? I believe open-gop is, so it would be interesting if this could work.

[HD MOVIE SOURCE]

Tested --radl=3 last night, and now instead of having every GOP ending with a pframe, they now end with bframes. I think every single GOP ended with a frame. This means that it had to have looked into the next GOP to gather information right?

I didn't haven to change the rc-lookahead either, I kept it at 24, but I may check to see if a further lookahead can now improve things.

[benwaggoner]

Tested --radl=3 last night, and now instead of having every GOP ending with a pframe, they now end with bframes. I think every single GOP ended with a frame. This means that it had to have looked into the next GOP to gather information right?

I didn't haven to change the rc-lookahead either, I kept it at 24, but I may check to see if a further lookahead can now improve things.
--radl 2 or 3 is generally good. Ideally it would be adaptive, but it isn't.
It's not that the GOP is ending with a B-frame, but that GOPs are starting with B-frames that are only forward references.

[jpsdr]

--radl=? I will try what is suggested in x265 documentation of 3 with an open-gop
Where did you read that ? The documentation says it requires glosed gop...:confused:

[benwaggoner]

Where did you read that ? The documentation says it requires glosed gop...:confused:
Yeah. --radl is essentially the replacement for Open GOP when Closed GOP is required for adaptive streaming.