x264: first GOP too short when using open GOP and fixed pattern

[loudmax]

Hi,
I'm trying to get files that are as similar as possible to those produced by Sony XAVC Long GOP encoders. To create the fixed GOP pattern IBBPBB...PBB with a GOP length of 24 frames, I used the following parameters:
--keyint 24 --bframes 2 --b-adapt 0 --no-weightb --weightp 0 --open-gop --no-scenecut
Unfortunately, this only works from the second GOP onwards, tested with 1080p50, csp i422, 10 Bit input/output. The first GOP is only 22 frames long and sets a P-frame as the second frame. Perhaps this is due to the fact that an IDR frame is generated first, which according to the documentation contradicts an open GOP. However, the Sony encoder also generates an IDR frame first and then the two B frames.
Is it possible to get the x264 encoder to also generate the first GOP with the specified pattern (with IDR frame) and length?

[poisondeathray]

You can override with a qp file


--qpfile <string> Force frametypes and QPs for some or all frames
Format of each line: framenumber frametype QP
QP is optional (none lets x264 choose). Frametypes: I,i,K,P,B,b.
K=<I or i> depending on open-gop setting
QPs are restricted by qpmin/qpmax.

[loudmax]

Thanks, but that didn´t work.
It seems to be impossible to get a GOP size of 24 in the first GOP with --open-gop enabled. The second frame will always be set as P-Frame.

I used this cmd:
x264 "infile.y4m" --keyint 24 --bframes 2 --b-adapt 0 --no-weightb --weightp 0 --open-gop --no-scenecut --output-depth 10 --output-csp i422 --qpfile "qp.txt" -o "outfile.h264"

with the attached qp-file.

[poisondeathray]

I can't see your qpfile - sometimes it takes awhile for attachments to get approved

It works for me. 24 frame GOP's with IBBP pattern. Later GOP's looked ok too


This was my qpfile

0 I 18
1 b 22
2 b 22
3 P 20
4 b 22
5 b 22
6 P 20
7 b 22
8 b 22
9 P 20
10 b 22
11 b 22
12 P 20
13 b 22
14 b 22
15 P 20
16 b 22
17 b 22
18 P 20
19 b 22
20 b 22
21 P 20
22 b 22
23 b 22



To emulate a Sony stream more closely you'd probably want to add some VBV restrictions as well

[loudmax]

Yes, further settings are required for a Sony-compatible file. But I wanted to solve the GOP problem first to see if it works at all.

Unfortunately, I'm either too stupid or I'm doing something fundamentally wrong. I still get with your qp file and this command line a first GOP with 22 frames and a P-frame in second position:
x264-r3191-4613ac3.exe "Input.y4m" --keyint 24 --bframes 2 --b-adapt 0 --no-weightb --weightp 0 --open-gop --no-scenecut --output-depth 10 --output-csp i422 --qpfile "qp.txt" -o "Output.h264"

Here are Input.y4m, Output.h264 and qp.txt:
https://www.dropbox.com/scl/fi/qgsp61pc7d9rkwzpbv4uo/opengop_test1.7z?rlkey=izqwwqsccemzuuhpue0il9lyx&st=qu7tn8bn&dl=1

[poisondeathray]

"Output.h264" looks ok to me - 24 frame gop, IbbP... - how are you determining frame type and GOP characteristics ?

[loudmax]

I used MediaInfo, showing all headers with debug details - 10.
Here are the results of output.h264 and a Sony reference file:
https://filetransfer.io/data-package/vhxSO2i7#link

Besides the other parameters, for the Sony file a 24 frame GOP is detected. For x264 only a 22 frame GOP.

[poisondeathray]

Not sure how accurate mediainfo would be for that

The 1st P frame is frame 1 in encoded order, but 4 in display order according to ffprobe. Ibbp is display order

[benwaggoner]

Does the Sony format use reference ("B" upper case) or non-reference ("b" lower case) B-frames? You can specify either in your qpfile. Reference offer better qualty/efficiency so should be used if compatible.

[loudmax]

Not sure how accurate mediainfo would be for that

The 1st P frame is frame 1 in encoded order, but 4 in display order according to ffprobe. Ibbp is display order

OK. ffprobe indicates that the Sony files in display order start with 2 B-frames. So BBI(DR)BBPBBP...BBPIBBP...
Guess that´s the old XDCAM preroll thing.

I have adjusted the qpfile accordingly, but I get the warnings that frame 0 is not compatible with the keyframe interval and frame 1 has been changed from type 5 to type 3.
The resulting file now has the GOP I(DR)PI(DR)BBPBBP...BBPIBB.

Is it possible to create files that start with 2 B-frames in display order?

[loudmax]

Does the Sony format use reference ("B" upper case) or non-reference ("b" lower case) B-frames? You can specify either in your qpfile. Reference offer better qualty/efficiency so should be used if compatible.

I guess it´s non-reference, but I´m not sure. Which parameter in the header tells me that?

[benwaggoner]

I guess it´s non-reference, but I´m not sure. Which parameter in the header tells me that?
In x265 logs, it is "B" versus "b."

I'd be pretty startled if they were using Reference B, as there's not huge value with max of 2 B-frames, and non-reference B can make random access more efficient and encoding more easily parallelized with minimal lookahead.

[loudmax]

I am now pretty sure that non-referenced b-frames are used.
At least with that and some other settings I can get pretty close to the Sony stream. I can probably omit the leading b-frames. Both, the Sony Catalyst and Avid, also leave them out.

I'll have to try out my generated files with hardware playouts and NLE software in the next few days.

[FranceBB]

Speaking of hardware playout ports, are you muxing the raw_video.h264 stream produced by x264.exe in an mxf container?
And if so, which muxer are you using?
The only reason why I'm mentioning this is that I opened up a bug for the mxf muxer in FFMpeg which has issues with XAVC Long GOP a long time ago, but nobody seemed to care, which means that it's still broken to this very day: https://trac.ffmpeg.org/ticket/9647

[loudmax]

Speaking of hardware playout ports, are you muxing the raw_video.h264 stream produced by x264.exe in an mxf container?
And if so, which muxer are you using?
The only reason why I'm mentioning this is that I opened up a bug for the mxf muxer in FFMpeg which has issues with XAVC Long GOP a long time ago, but nobody seemed to care, which means that it's still broken to this very day: https://trac.ffmpeg.org/ticket/9647

I create the video with ffmpeg, but pipe it through bmxtranswrap. That should make it work.

Interestingly, the code criticized in the ffmpeg ticket is part of a patch I wrote in 2014 to enable AVC Intra in MXF. Long GOP was not planned back then.

Edit: I have just seen that the code has been extended for AVC Long GOP.

[benwaggoner]

I am now pretty sure that non-referenced b-frames are used.
At least with that and some other settings I can get pretty close to the Sony stream. I can probably omit the leading b-frames. Both, the Sony Catalyst and Avid, also leave them out.

I'll have to try out my generated files with hardware playouts and NLE software in the next few days.
If you use --no-open-gop, that should eliminate leading b-frames, forcing all GOPs to start with an IDR frame.

[Balling]

If you use --no-open-gop, that should eliminate leading b-frames, forcing all GOPs to start with an IDR frame.

LOL, you sure about that? https://forum.videohelp.com/images/imgfiles/Df6d4pR.jpg

This is display order, in coding order I frame would be first, of course, for Closed GOP. I believe this is that crazy unidirectional B frames.

[benwaggoner]

LOL, you sure about that? https://forum.videohelp.com/images/imgfiles/Df6d4pR.jpg

This is display order, in coding order I frame would be first, of course, for Closed GOP. I believe this is that crazy unidirectional B frames.
Wow, I didn't realize x264 would ever produce those! It must be a pretty edge case as I can think of some things that would, er, not work so great if that happened with any frequency.

In HEVC we can get a similar effect using RADL, but that is a non-default feature.

[rwill]

Wow, I didn't realize x264 would ever produce those!

And I don't think x264 does. That picture seems to be from some Mpeg-1/2 slides.

[filler56789]

LOL, you sure about that? https://forum.videohelp.com/images/imgfiles/Df6d4pR.jpg

This is display order, in coding order I frame would be first, of course, for Closed GOP. I believe this is that crazy unidirectional B frames.
+
And I don't think x264 does. That picture seems to be from some Mpeg-1/2 slides.
F.W.I.W, here is the source of that image :—/

https://slideplayer.com/slide/5086013/

[Balling]

Wow, I didn't realize x264 would ever produce those! It must be a pretty edge case as I can think of some things that would, er, not work so great if that happened with any frequency.

In HEVC we can get a similar effect using RADL, but that is a non-default feature.

Yep, bug in x264. The file that is produced above by x264 (Output.h264) has B frames that come after I frame in presentation order, while actual Sony XAVC that is not Intra will be two B frames in the closed GOP (CLOSED !!!! not open, indeed, each starting with two B frames Closed GOP does not depend on previous frames from previous GOP). See VQ Analyzer:

https://i.imgur.com/kHqrebH.jpeg

and this for next GOP:

https://i.imgur.com/dYNbkzK.jpeg

(green is B frames, only one layer of B frames here, I frame is red, and P frames are blue dots and the two numbers like 240/242 mean DTS/PTS, the order is obviously presentation, though hierarchy view sometimes mixed presentation order and dts order if it is impossible to show reliably). SAMPLE is here, it uses full range 422 and slog3 as transfer and s3 cine gamut. https://we.tl/t-hBsbs6Sy3G

7 days only.


+

F.W.I.W, here is the source of that image :—/

https://slideplayer.com/slide/5086013/

Nope, allowed in Sony XAVC.

[filler56789]

Nope, allowed in Sony XAVC.

¿Why the heck so many people LOVE to pretend they misunderstand anything that I write? 🤔

[Balling]

¿Why the heck so many people LOVE to pretend they misunderstand anything that I write? 🤔

I just pinged you. Sorry.