The first IDR-frame as reference for the first 2 B-frames

[Mitra]

H.264 specs says :

8.2.4.2.3 Initialization process for reference picture lists for B slices in frames: When this process is invoked, there shall be at least one reference entry that is currently marked as "used for reference" (i.e., as "used for short-term reference" or "used for long-term reference") and is not marked as "non-existing"

(thanks to nobody555 from the stackoverflow for find it)

As you can see ,only one I/P frame can be used as reference for B-frames. it means the same reference frame can use for both RefPicList0 and RefPicList1, but the document does not have enough details about it.( or it is difficalt to understand at least to me)


my question:
How to set the first IDR-frame as the only reference for the first B-frames in the open-GOP stream with this pattern:BBIBBPBB...? / How to implement it in the x264/libx264 source code?

Note: I want this to be done for the first two B-frames , not the rest of the stream.

(sorry if my English is bad)

[benwaggoner]

I'm confused. A B-frame can absolutely have more than one I/P frame it can reference. And a non-reference b-frame can reference more than one I/P/B frame. A B-frame is really defined by referencing both a past and a future frame.

Are you trying to force a single reference for some reason? In a way that --ref 1 wouldn't give you?

[Mitra]

Originally Posted by benwaggoner

I'm confused. A B-frame can absolutely have more than one I/P frame it can reference. And a non-reference b-frame can reference more than one I/P/B frame. A B-frame is really defined by referencing both a past and a future frame.

Are you trying to force a single reference for some reason? In a way that --ref 1 wouldn't give you?

Thank you for the reply,

Unfortunately, Common mistakes on the Internet is confusing. . . .

I used to think like you until a while ago, but according to the ITU document, this does not seem to be true.

Also many commercial encoders starts open-GOP stream with this pattern: BBIBBPBB...(stream order) , in this pattern, the first I(DR) is the only reference for both first B-frames.


As you know ref parameter can set the number of previous frames each P-frame can use as references,but ref=1 does not work for B-Frames.

[benwaggoner]

Originally Posted by Mitra

TI used to think like you until a while ago, but according to the ITU document, this does not seem to be true.

Also many commercial encoders starts open-GOP stream with this pattern: BBIBBPBB...(stream order) , in this pattern, the first I(DR) is the only reference of both first B-frames.

I implemented it by cutting on the I-frame but due to the loss of a P before 2 first B-frames they are not decodable , So I want to implement it in the standard way for myself.

As you know ref parameter can set the number of previous frames each P-frame can use as references,but ref=1 does not work for B-Frames.

The BBIBB... pattern is either Open GOP (with the leading Bs referencing the prior GOP) or RADL, which references only following frames in playback order, but can reference more than one future frame. Open GOP is generally used with files and on optical disc, while RADL can be used with stream switching.

B-frames have ALWAYS used both forward and backward prediction, and thus at least 2 frames, all the way back to MPEG-1. Older codecs like MPEG-1/2 and VC-1 supported 2 reference frames for B-frames while allowing only 1 reference for P-frames. The resulting improvement in compression efficiency from the bidirectional prediction making B-frames smaller is a key motivation for B-frames in the first place (they also reduced cumulative drift due to different floating point implementations in MPEG-1/2).

The x264/x265 --ref syntax is dumb as it means different things with and without B-frames. It should really follow the bitstream syntax parameter, so the max ref frames is the same with and without B-frames

[Mitra]

Originally Posted by benwaggoner

The BBIBB... pattern is either Open GOP (with the leading Bs referencing the prior GOP) or RADL, which references only following frames in playback order, but can reference more than one future frame. Open GOP is generally used with files and on optical disc, while RADL can be used with stream switching.

B-frames have ALWAYS used both forward and backward prediction, and thus at least 2 frames, all the way back to MPEG-1. Older codecs like MPEG-1/2 and VC-1 supported 2 reference frames for B-frames while allowing only 1 reference for P-frames. The resulting improvement in compression efficiency from the bidirectional prediction making B-frames smaller is a key motivation for B-frames in the first place (they also reduced cumulative drift due to different floating point implementations in MPEG-1/2).

The x264/x265 --ref syntax is dumb as it means different things with and without B-frames. It should really follow the bitstream syntax parameter, so the max ref frames is the same with and without B-frames

So, please explain the reference of the first two B-frames of this sample and show me how we can do this by x264 , Etc.

StreamEye says the only reference for both is the first IDR.

Note: I'm talking about the first 2 B-frames , not the rest of the stream.

[benwaggoner]

Originally Posted by Mitra

So, please explain the reference of the first two B-frames of this sample and show me how we can do this by x264 , Etc.

StreamEye says the only reference for both is the first IDR.

Note: I'm talking about the first 2 B-frames , not the rest of the stream.

OH! Gotcha. Sounds like RADL from x265. In that case, they are B-frames only in the sense that the allow prediction from frames later in temporal order.

I think it is technically possible for one of those to reference a P-frame after the IDR, but for most content the encoder wouldn't find useful references there to use, so they wouldn't be in the list.

x264 doesn't have --radl, of course. You could evaluate this if you used a QPfile to force a "bbIP" start sequence, and make the P a better reference for the bb than the I is.

[Mitra]

Originally Posted by benwaggoner

OH! Gotcha. Sounds like RADL from x265. In that case, they are B-frames only in the sense that the allow prediction from frames later in temporal order.

I think it is technically possible for one of those to reference a P-frame after the IDR, but for most content the encoder wouldn't find useful references there to use, so they wouldn't be in the list.

x264 doesn't have --radl, of course. You could evaluate this if you used a QPfile to force a "bbIP" start sequence, and make the P a better reference for the bb than the I is.

Thanks for your explanation,

but unfortunately not possible with QPfile ,because using QPfile, the first frame in stream order will always be IDR ,not B.

[Balling]

Originally Posted by Mitra

Thanks for your explanation,

but unfortunately not possible with QPfile ,because using QPfile, the first frame in stream order will always be IDR ,not B.

You can use DGIndexNV. You need a nice Nvidia gpu. If you have that you can just press F3 and it will show you your Open GOP – so probably 2 first B frames will be corrupted