References & b-pyramid?

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

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.

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]

Originally Posted by benwaggoner

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-leva...lix-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]

Originally Posted by benwaggoner

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]

Originally Posted by HD MOVIE SOURCE

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]

Originally Posted by benwaggoner

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]

Originally Posted by HD MOVIE SOURCE

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]

Originally Posted by benwaggoner

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]

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

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=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?

--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]

Originally Posted by HD MOVIE SOURCE

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=HD MOVIE SOURCE;1987733][QUOTE=benwaggoner;1987348]

Originally Posted by HD MOVIE SOURCE

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]

Originally Posted by Microchip8

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]

Originally Posted by benwaggoner

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]

Originally Posted by HD MOVIE SOURCE

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]

Originally Posted by benwaggoner

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]

Originally Posted by HD MOVIE SOURCE

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]

Originally Posted by benwaggoner

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]

Originally Posted by HD MOVIE SOURCE

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!