x265 wastes some bytes when using open-gop

[Andreas Rheinhardt]

Hello,

I have recently encoded a small snippet once with the default setting of open-gop (i.e. open-gop activated) and once with --no-open-gop (for definiteness, I used the build provided here, but this shouldn't be relevant). The material I encoded had plenty of good candidates for keyframes so that even the version encoded with --open-gop had only closed gops. If I decode the two versions, the decoded frames are completely identical (I tested this with ffmpeg's framehash muxer). But the encoded frames aren't identical: The keyframes from the open-gop-allowed version are a few bytes bigger than the IDR-keyframes from the no-open-gop version. This is due to different headers: The header (both the NAL unit header and the slice header) of the second keyfame in the --no-open-gop file is 0x26 01 AD E0; for the file encoded with open-gop-allowed it is 0x2A 01 AD 78 5D 25 78. The difference is probably due to the necessity to include slice_pic_order_cnt_lsb and maybe reference list modifications for the non-IDR frame. After these bytes, the rest of the picture is the same. I don't see a reason not to use an IDR frame when one has a closed gop (even if open-gop is allowed); besides the advantage in bytes, the resetting of the slice_pic_order_cnt_lsb that is performed when one uses an IDR frame might improve splitting and joining: With H.264 I have seen instances where there were artifcats when joining two H.264 videos when the second one starts with a closed-gop I-keyframe with a recovery point SEI (and exact_match_flag set to 1) despite the SPS and PPS being all the same. The only differences were the frame_num and the pic_order_count.

Greetings and thanks Andi

PS: x264 has the same issue; I reported it on , but apparently no one cares. PPS: Due to copyright stuff I can't upload my own test file, but it should be easy to reproduce this if needed.

[Pradeep Ramachandran]

Thanks for the suggestion. From what I reckon, when you have open-gop encoding, encoders prefer encoding keyframes (such as scenecuts, or fades) as I-frames so that future frames can benefit from using frames before this frame as a reference. If you force an IDR, this reference cannot happen and therefore encoding efficiency (when looking at the entire video across different types of videos, and not just for a specific use case) may take a hit.

[Andreas Rheinhardt]

I am aware of what you say and it's the reason why IDR frames and open-gop are irreconcilable. But if I am not mistaken, then x265 (and x264) doesn't use any references from before the I-frame if one has a closed GOP (in order to be able to seek to this I-frame (making it a real keyframe) and in order to split the video at this point; and isn't it so that in streams encoded by x265 in case of an open gop only the frames that are shared between two GOPs (i.e. those that precede the keyframe from the latter GOP in display order, but follow it in coding order) rely on references from the first GOP, whereas all other frames from the second GOP don't need the first GOP at all? If it weren't so, videos encoded by x265 would show artifacts after seeking, but they don't)). This is the case in the situation I encountered: I didn't get artifacts when splitting the stream and playing the latter part. No references seem to cross the GOP boundary (for a closed GOP). I once analyzed the situation with x264 and they use memory managment control operations to enforce this. It seemed to me that x265 already does the H.265 analogue of this (as it should for the seekability of the created streams).

[Andreas Rheinhardt]

After reading some more in the standard I think I can rephrase my proposal: There are currently situations where x265 uses a closed gop that begins with an IRAP picture that is not an IDR picture. (In the case above, it is a CRA_NUT=clean random access picture.) In such situations there are no references to pictures preceding the IRAP picture so that the IRAP picture can be coded as IDR picture without affecting encoding efficiency. I propose that they really are encoded as IDR pictures because their slice header is a bit smaller (or at least I have not found an example where this isn't so).