config.guess and config.sub are the latest GPLv2 version. The license was changed to GPLv3 which is incompatible with x264.
ifb (19b26872) at 13 Dec 18:58
xavc: Use the default quantization matrix for Class 300/480
ifb (3884bdee) at 12 Dec 04:33
xavc: Allow I4x4 partitions with UHD Class 300/480
ifb (d9a19f0d) at 12 Dec 04:10
Makefile: Do not create multiple directories in one go
... and 19 more commits
ifb (72db4377) at 12 Dec 04:03
Compare to your two samples. NAL locations across all three match (so the bitrates are the same), even though x264 uses a CQM to mimic an EVS XT4K and my sample doesn't have any VUI/HDR signaling.
Btw, it's an open question how much that CQM helps. Now that we have more diverse samples, I think we can safely assume that it's not strictly required.
I'll try to run some PSNR/SSIM tests before I make a patch to enable I4x4. That's likely much more important.
The interesting part of your samples is that they use 4x4 partitions. I just created a fresh sample with Catalyst Browse and it also uses 4x4, so it seems like it's supported in XAVC 300/480 after all? My UHD samples from 3+ years ago are 8x8-only, same as all the HD AVC Intra flavors. I'm almost certain this is different behavior from Catalyst Browse, but I can't locate any old samples right now to confirm.
It would be a one-line patch to enable X264_ANALYSE_I4x4.
You see, it should really specify constant bitrate with 500 Mbit/s in the stream like something like --nal-hrd cbr and then --bitrate 500121
but it's the metadata that really matters here.
So your issue is actually with the bitrate indicated by the container? I can't help you with that. x264 writes no relevant metadata. There is no place for x264 to signal "500 Mbit/s".
And why bring up HRD? There are no HRD NALs in your samples. The frames are 1,250,304 bytes and match x264's output (except for CQMs and VUI).
Common to all AVCI flavors (from encoder.c):
h->param.i_nal_hrd = X264_NAL_HRD_NONE;
h->param.rc.i_vbv_buffer_size = avcintra_lut[type][res][i].frame_size;
h->param.rc.i_vbv_max_bitrate =
h->param.rc.i_bitrate = h->param.rc.i_vbv_buffer_size * fps_num / fps_den;
h->param.rc.i_rc_method = X264_RC_ABR;
h->param.rc.f_vbv_buffer_init = 1.0;
h->param.rc.b_filler = 1;
x264 seems to be outputting 504013 kbit/s (so 504 Mbit/s) which of course ain't right.
Simply asserting it's not right because "of course" is not a terribly convincing argument. Bit rates in that table are an approximation. 1,250,304 * 50 * 8 = 500121.6 kbit/s. Close, but not 500 Mbit/s.
Now an extra ~4 Mbit/s of overhead from non-frame NALs seems high, but maybe not. I don't know how or what calculated your 504013 kbit/s number, but the analyzer I'm using right now reports 587 Mbit/s for a hardware-encoded 59.94p Class 300 sample. "Of course" it should be 600 Mbit/s, but all frames are in fact 1,250,304 bytes which is what matters.
Very small samples (10-frames or less) would be enough to verify that the frames are 1,250,304 bytes or not. WeTransfer is fine with me.
Yes, the values for frame_size (VBV buffer) in encoder.c were reverse engineered to match samples created by EVS, Sony Catalyst Browse, and Adobe Media Encoder.
If you have a sample with different size frame NALs from what x264 creates, I can look into it.
ifb (ae03d92b) at 13 Jun 20:39
ifb (729e2051) at 08 Jun 20:26
Add support for Sony XAVC Class 300 and 480
ifb (61bdac5f) at 08 Jun 19:56
Add support for Sony XAVC Class 300 and 480
ifb (b684ebe0) at 07 Jun 20:07
Cosmetics: Fix vertical alignment for long_options
... and 5 more commits
Changed PPS to make XAVC Intra Class 300 and 480 use the same PPS size as XAVC Intra 100.
ifb (fa770fd5) at 05 May 07:23
AVC-Intra does not support x264_sei_version_write() and b_repeat_headers must be enabled. Prevent libx264 users from producing invalid AVC-Intra streams by enforcing these restrictions.
This fixes AVC-Intra mov files generated by ffmpeg.
Patch by Thomas Mundt