Nvenc 4:2:2

[excellentswordfight]

Hi,

Im not sure if this is the correct subforum, but as I suspect that its HEVC-relevant I thought I might as well put it here.

I've saw that one of the features in the new 5000-series from nvdia is actually 4:2:2 support in NVENC

https://blogs.nvidia.com/blog/generative-ai-studio-ces-geforce-rtx-50-series/

That is tbh big news! As someone in the broadcasting-world that deals a lot with big amounts of different 4:2:2 mxf formats its a bit of game changer of we could get HW-support for these. Does anyone know anything more about this? Is it only HEVC-flavors (so mostly pro-summer formats) or also AVC-flavors (AVC-I, XAVC)? Is it decode as well as encode?

Cause I saw that this was a bit of footnote feature for the latest Intel cards as well that they were going to support the sony XAVC-H format, which is a bit useless atm for most anyway as its a 8K format only atm afaik. But its atleast a good start in getting pro format support on these GPU:s.

https://www.phoronix.net/image.php?id=intel-arc-b580-battlemage&image=intel_battlemage_8_show

So what do you guys think, what format support can we expect on with this 4:2:2 update on nvidia cards?

[Selur]

Since the article only mentions decoding, there probably will be no encoding support and it's probably hevc only.
Otherwise, they would have mentioned it. ;)

[excellentswordfight]

Since the article only mentions decoding, there probably will be no encoding support and it's probably hevc only.
Otherwise, they would have mentioned it. ;)
Hmm, the news article were I saw this first only said that it would feature encode, but I can see now re-reading the blog that it actually only says decode.

But judging from this I guess it’s both?

” The problem is that editing 4:2:2 can be very CPU-intensive. Blackwell will fix that, and a sample workflow using a Core i9-14900K went from taking 110 minutes to encode to just 10 minutes with a Blackwell GPU.”

https://www.tomshardware.com/pc-components/gpus/nvidia-blackwell-for-creators-and-professionals-upgrades-for-editing-video-images-audio-and-more


But I think you are right about hevc, unfortunately, as mentioned it’s mostly pro-sumer cameras that does the hevc-flavors. I would have loved to see xavc-i mxf support.

[Z2697]

Let's wait to see the updated support matrix ;)
https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new

[FranceBB]

I would have loved to see xavc-i mxf support.

Same. As someone who encodes a lot of XAVC Intra Class 300 at 50fps on a daily basis, this would have been speeding things up a lot.

[excellentswordfight]

Some more details:

"In DaVinci Resolve, the H.265 4:2:2 10-bit processing was more than twice as fast as software decoding and exceeded even what we see from Intel Quick Sync."

https://www.pugetsystems.com/labs/articles/nvidia-geforce-rtx-5090-content-creation-review/

So HEVC 4:2:2 hw-decoding is confirmed and already implemented in Resolve at least.

Also saw this in the comments:

"There was a question in the Facebook Premiere Pro group regarding the new NVDEC capabilities with the RTX 50xx cards and Fergus from Adobe answered:

"Adobe has a very close partnership with Nvidia and we’ve been working with them to support the RTX 50 series GPU. We're particularly excited that the new GPU supports hardware acceleration of 10-bit 4:2:2 media in HEVC and H.264, as these formats provide a great combination of high quality and small file size.

We use Nvidia’s CUDA SDK (software development kit) to provide support for their products in ours. We’ve been testing the RTX 50 series cards with a prerelease version of that SDK. Today, Nvidia has made available a final version of that SDK which means we can finalize our support and release it. That will come first in a public beta, then a final release. I don’t have a date to share about the timing of that but it is a high priority for us. I’ll post to this group when the beta is available." "

So AVC support, e.g. xavc/avc-i might still be on the table. Lets hope it both on the decoder and encoder side.

[excellentswordfight]

Let's wait to see the updated support matrix ;)
https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
It has now been updated, the new broadwell cards support 4:2:2 both encode and decode, and its for both h264/avc and h265/hevc.

Lets hope we also get some adoption for industry formats @FranceBB !

[Z2697]

Somehow that feels both excellent and ridiculous (like, why now? or why until now?).
(they have had 444 encoding capability for years, is 422 that different?)

[Selur]

Probably not, but not enough interested for it to justify to work on putting it into a chip.

[benwaggoner]

Somehow that feels both excellent and ridiculous (like, why now? or why until now?).
(they have had 444 encoding capability for years, is 422 that different?)
The primary use case for 422 is interlaced video, which is rarely done with HEVC. That would be my guess.

[kolak]

Encoding is not much interesting, but decoding very.
Whole post world is waiting for 4:2:2 h264/5 decoding as this is used a lot in semi pro cameras and taxing CPU a lot. Only Intel and new Macs had support, where in reality Nvidia dominates that market.
Resolve users are excited :)

[olduser217]

Is SCC supported in HEVC 4:2:2 of NVENC and NVDEC?
Hardware of Intel specifically mentions that HEVC 4:2:2 supported by its decoder doesn't include SCC.

[FranceBB]

Lets hope we also get some adoption for industry formats

Unfortunately, it doesn't really look good... :(
I managed to get my hands on an NVIDIA RTX 5080 and I started experimenting a bit.

https://i.imgur.com/MOYVlHW.png

The idea was to see whether it could produce a compliant AVC Intra Class file, so I started with an AVC Intra Class 100. In particular a 1920x1080 H.264 High 4:2:2 Intra Profile, Level 4.1, 114 Mbit/s 4:2:2 25i TFF 10bit planar BT709 SDR file in a similar way to what x264 can do.

By looking at the documentation, I came up with the following command line:


ffmpeg -i "AVS Script.avs" -pix_fmt yuv422p10le -c:v h264_nvenc -s 1920:1080 -aspect 16:9 -r 25 -vf setfield=tff -flags +ildct+ilme -preset medium -profile:v high -level 4.1 -b:v 113664k -minrate 113664k -maxrate 113664k -bufsize 4547k -rc cbr -cbr true -g 0 -rc-lookahead 1 -lookahead_level 0 -no-scenecut true -forced-idr true -b_adapt false -b_ref_mode 0 -nonref_p false -weighted_pred 0 -coder cavlc -aud true -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -chroma_sample_location topleft -c:a pcm_s24le -ar 48000 -timecode 10:00:00:00 -y "output.mxf"


however this attempt failed miserably. Not only there doesn't seem to be a way to force NVEnc to produce 8 slices (unlike x264 --slices 8 command), but even forcing constant bitrate with several parameters and setting the buffer size = bitrate / framerate didn't make it produce a constant bitrate file, on the contrary:

https://i.imgur.com/pqpFtvz.png

As we can see the bitrate is all over the place, while in a proper Intra Class mode it should be constant without any deviation. Not only that, but if we look at the mediainfo we can see the references being 2 instead of 1 (which x264 can instead achieve with --ref 1):

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4.1
Format settings : 2 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 2 frames
Format settings, GOP : N=1
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201316001
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 114 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 2.193
Stream size : 8.39 GiB
Color range : Limited
Matrix coefficients : BT.709


All in all this was a pretty big disappointment.
Sure, NVEnc can produce a 4:2:2 10bit H.264 file, but it doesn't seem to be able to produce a valid AVC Intra Class output, no matter which options are used.

For those interested, here's the full command line option for NVEnc via FFMpeg (latest master):


Encoder h264_nvenc [NVIDIA NVENC H.264 encoder]:
General capabilities: dr1 delay hardware
Threading capabilities: none
Supported hardware devices: cuda cuda d3d11va d3d11va
Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 bgra rgb0 rgba x2rgb10le x2bgr10le gbrp gbrp16le cuda d3d11
h264_nvenc AVOptions:
-preset <int> E..V....... Set the encoding preset (from 0 to 18) (default p4)
default 0 E..V.......
slow 1 E..V....... hq 2 passes
medium 2 E..V....... hq 1 pass
fast 3 E..V....... hp 1 pass
hp 4 E..V.......
hq 5 E..V.......
bd 6 E..V.......
ll 7 E..V....... low latency
llhq 8 E..V....... low latency hq
llhp 9 E..V....... low latency hp
lossless 10 E..V.......
losslesshp 11 E..V.......
p1 12 E..V....... fastest (lowest quality)
p2 13 E..V....... faster (lower quality)
p3 14 E..V....... fast (low quality)
p4 15 E..V....... medium (default)
p5 16 E..V....... slow (good quality)
p6 17 E..V....... slower (better quality)
p7 18 E..V....... slowest (best quality)
-tune <int> E..V....... Set the encoding tuning info (from 1 to 4) (default hq)
hq 1 E..V....... High quality
ll 2 E..V....... Low latency
ull 3 E..V....... Ultra low latency
lossless 4 E..V....... Lossless
-profile <int> E..V....... Set the encoding profile (from 0 to 3) (default main)
baseline 0 E..V.......
main 1 E..V.......
high 2 E..V.......
high444p 3 E..V.......
-level <int> E..V....... Set the encoding level restriction (from 0 to 62) (default auto)
auto 0 E..V.......
1 10 E..V.......
1.0 10 E..V.......
1b 9 E..V.......
1.0b 9 E..V.......
1.1 11 E..V.......
1.2 12 E..V.......
1.3 13 E..V.......
2 20 E..V.......
2.0 20 E..V.......
2.1 21 E..V.......
2.2 22 E..V.......
3 30 E..V.......
3.0 30 E..V.......
3.1 31 E..V.......
3.2 32 E..V.......
4 40 E..V.......
4.0 40 E..V.......
4.1 41 E..V.......
4.2 42 E..V.......
5 50 E..V.......
5.0 50 E..V.......
5.1 51 E..V.......
5.2 52 E..V.......
6.0 60 E..V.......
6.1 61 E..V.......
6.2 62 E..V.......
-rc <int> E..V....... Override the preset rate-control (from -1 to INT_MAX) (default -1)
constqp 0 E..V....... Constant QP mode
vbr 1 E..V....... Variable bitrate mode
cbr 2 E..V....... Constant bitrate mode
vbr_minqp 8388609 E..V....... Variable bitrate mode with MinQP (deprecated)
ll_2pass_quality 8388609 E..V....... Multi-pass optimized for image quality (deprecated)
ll_2pass_size 8388610 E..V....... Multi-pass optimized for constant frame size (deprecated)
vbr_2pass 8388609 E..V....... Multi-pass variable bitrate mode (deprecated)
cbr_ld_hq 8388610 E..V....... Constant bitrate low delay high quality mode
cbr_hq 8388610 E..V....... Constant bitrate high quality mode
vbr_hq 8388609 E..V....... Variable bitrate high quality mode
-rc-lookahead <int> E..V....... Number of frames to look ahead for rate-control (from 0 to INT_MAX) (default 0)
-surfaces <int> E..V....... Number of concurrent surfaces (from 0 to 64) (default 0)
-cbr <boolean> E..V....... Use cbr encoding mode (default false)
-2pass <boolean> E..V....... Use 2pass encoding mode (default auto)
-gpu <int> E..V....... Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from -2 to INT_MAX) (default any)
any -1 E..V....... Pick the first device available
list -2 E..V....... List the available devices
-rgb_mode <int> E..V....... Configure how nvenc handles packed RGB input. (from 0 to INT_MAX) (default yuv420)
yuv420 1 E..V....... Convert to yuv420
yuv444 2 E..V....... Convert to yuv444
disabled 0 E..V....... Disables support, throws an error.
-delay <int> E..V....... Delay frame output by the given amount of frames (from 0 to INT_MAX) (default INT_MAX)
-no-scenecut <boolean> E..V....... When lookahead is enabled, set this to 1 to disable adaptive I-frame insertion at scene cuts (default false)
-forced-idr <boolean> E..V....... If forcing keyframes, force them as IDR frames. (default false)
-b_adapt <boolean> E..V....... When lookahead is enabled, set this to 0 to disable adaptive B-frame decision (default true)
-spatial-aq <boolean> E..V....... set to 1 to enable Spatial AQ (default false)
-spatial_aq <boolean> E..V....... set to 1 to enable Spatial AQ (default false)
-temporal-aq <boolean> E..V....... set to 1 to enable Temporal AQ (default false)
-temporal_aq <boolean> E..V....... set to 1 to enable Temporal AQ (default false)
-zerolatency <boolean> E..V....... Set 1 to indicate zero latency operation (no reordering delay) (default false)
-nonref_p <boolean> E..V....... Set this to 1 to enable automatic insertion of non-reference P-frames (default false)
-strict_gop <boolean> E..V....... Set 1 to minimize GOP-to-GOP rate fluctuations (default false)
-aq-strength <int> E..V....... When Spatial AQ is enabled, this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive) (from 1 to 15) (default 8)
-cq <float> E..V....... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0)
-aud <boolean> E..V....... Use access unit delimiters (default false)
-bluray-compat <boolean> E..V....... Bluray compatibility workarounds (default false)
-init_qpP <int> E..V....... Initial QP value for P frame (from -1 to 51) (default -1)
-init_qpB <int> E..V....... Initial QP value for B frame (from -1 to 51) (default -1)
-init_qpI <int> E..V....... Initial QP value for I frame (from -1 to 51) (default -1)
-qp <int> E..V....... Constant quantization parameter rate control method (from -1 to 51) (default -1)
-qp_cb_offset <int> E..V....... Quantization parameter offset for cb channel (from -12 to 12) (default 0)
-qp_cr_offset <int> E..V....... Quantization parameter offset for cr channel (from -12 to 12) (default 0)
-weighted_pred <int> E..V....... Set 1 to enable weighted prediction (from 0 to 1) (default 0)
-coder <int> E..V....... Coder type (from -1 to 2) (default default)
default -1 E..V.......
auto 0 E..V.......
cabac 1 E..V.......
cavlc 2 E..V.......
ac 1 E..V.......
vlc 2 E..V.......
-b_ref_mode <int> E..V....... Use B frames as references (from -1 to 2) (default -1)
disabled 0 E..V....... B frames will not be used for reference
each 1 E..V....... Each B frame will be used for reference
middle 2 E..V....... Only (number of B frames)/2 will be used for reference
-a53cc <boolean> E..V....... Use A53 Closed Captions (if available) (default true)
-dpb_size <int> E..V....... Specifies the DPB size used for encoding (0 means automatic) (from 0 to INT_MAX) (default 0)
-multipass <int> E..V....... Set the multipass encoding (from 0 to 2) (default disabled)
disabled 0 E..V....... Single Pass
qres 1 E..V....... Two Pass encoding is enabled where first Pass is quarter resolution
fullres 2 E..V....... Two Pass encoding is enabled where first Pass is full resolution
-ldkfs <int> E..V....... Low delay key frame scale; Specifies the Scene Change frame size increase allowed in case of single frame VBV and CBR (from 0 to 255) (default 0)
-extra_sei <boolean> E..V....... Pass on extra SEI data (e.g. a53 cc) to be included in the bitstream (default true)
-udu_sei <boolean> E..V....... Pass on user data unregistered SEI if available (default false)
-intra-refresh <boolean> E..V....... Use Periodic Intra Refresh instead of IDR frames (default false)
-single-slice-intra-refresh <boolean> E..V....... Use single slice intra refresh (default false)
-max_slice_size <int> E..V....... Maximum encoded slice size in bytes (from 0 to INT_MAX) (default 0)
-constrained-encoding <boolean> E..V....... Enable constrainedFrame encoding where each slice in the constrained picture is independent of other slices (default false)
-lookahead_level <int> E..V....... Specifies the lookahead level. Higher level may improve quality at the expense of performance. (from -1 to 15) (default -1)
auto 15 E..V.......
0 0 E..V.......
1 1 E..V.......
2 2 E..V.......
3 3 E..V.......

[kolak]

There is always some deviation. There is no such a thing like CBR at constant 100Mbits. How would you encode black and white or bars frames with 100mbit with codecs like h264? Impossible without stuffing bits. It's not like nvenc can't do it. It's just not written to do it, because Nvidia has not real interest in it.

It took long time before x264 was able to do it. And without few people who pushed it, probably it would never happen.
Why bother with nvenc to do AVC-I if x264 can do it quite fast and works fine.

[Z2697]

Nvenc can write zero padding bits, or at least the downstream software (ffmpeg in this case) should be able to do it.
But for very strict CBR without zero padding... yeah that's pretty much impossible, if you have sample that can achieve that verified in the same way, I'd be very curious about it.
(zero padding bits are probably included in the framesize plot, so if it's zero padding then nothing to curious about)

I think the nvenc interface provided by ffmpeg doesn't support specifying the slices number, but the tool made by rigaya can probably do it: https://github.com/rigaya/NVEnc

By the way, x264 usually falls short when it comes to very small vbv buffer size, "1 frame" size is an extreme example.
Even for a pure random noise source it falls behind by whopping 10%, in more "daily" contents the number can be like 30%, 50%, 70%, or really anything.
So if the filler (zero padding) is ON, the bitrate you see is probably having a bunch of useless zeros... I can't imagine a situation where the padding is actually useful.

>ffmpeg -lavfi color=gray:s=1920x1080:r=25:d=60,format=yuv420p,noise=allf=t:alls=100 -c:v libx264 -b:v 113664k -maxrate 113664k -bufsize 4547k -x264opts filler=0 Noiz++.264

[libx264 @ 00000276419ac7c0] kb/s:102813.98


And, the VBV limit is "applied" on a macroblock basis, which means when it "takes off bits" the encoded stream will have a part of frame that's lower quality than the other part (usually the rows on top), especially in this extreme example (it's probably taking off bits every frame).

[tormento]

Unfortunately, it doesn't really look good... :(
Contact their tech support directly (perhaps you could register as enterprise/broadcasting and have special treatment) of writing on the forum.

Usually ther are really helpful.

[FranceBB]

There is always some deviation. There is no such a thing like CBR at constant 100Mbits. How would you encode black and white or bars frames with 100mbit with codecs like h264?

the way x264 currently does it is obviously undershooting and then performing a zero-fill to close the gap and it does it extremely well.

NVEnc:
https://i.imgur.com/DENQFCz.png

x264:
https://i.imgur.com/Q6PHh5h.png

if we open the raw_video.h264 created by x264 with an Hex Editor we can easily see that it has been zero-filled, in fact we have a part in which there's the bitstream followed by a bunch of zeros followed by the bitstream again in a repeating pattern (which is normal):

https://i.imgur.com/34RObRX.png




Why bother with nvenc to do AVC-I if x264 can do it quite fast and works fine.

Mostly because of this: https://forum.doom9.org/showthread.php?p=1999533

x264 10bit doesn't have AVX512 support and it can't scale more than vertical resolution / 40, which means that for a FULL HD footage it can use up to 1080/40 = 27 threads, while for a UHD footage it can use up to 2160/40 = 54 threads. Unfortunately this comes at the expense of speed. Especially the UHD in XAVC Intra Class 300 they're 50p and even with a beast like a 56c/112th Intel Xeon we're only getting ~36fps which is slower than real time, which is a bit of an issue when it comes to time critical things like Sports highlights.



I think the nvenc interface provided by ffmpeg doesn't support specifying the slices number

It turns out that I just had to add -slices 8 even though it wasn't documented, so I tried again with:

ffmpeg -i "AVS Script.avs" -pix_fmt yuv422p10le -c:v h264_nvenc -s 1920:1080 -aspect 16:9 -r 25 -vf setfield=tff -flags +ildct+ilme -preset medium -profile:v high422 -level 4.1 -b:v 113664k -minrate 113664k -maxrate 113664k -bufsize 4547k -rc cbr -cbr true -g 0 -refs 1 -rc-lookahead 1 -lookahead_level 0 -no-scenecut true -forced-idr true -b_adapt false -b_ref_mode 0 -nonref_p false -weighted_pred 0 -max_slice_size 0 -slices 8 -coder cavlc -aud true -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -chroma_sample_location topleft -c:a pcm_s24le -ar 48000 -timecode 10:00:00:00 -y "output.mxf"

and it worked in the sense that now Mediainfo says that there are indeed 8 slices. The problem seems to be with -refs 1 as it seems to be ignored and the file is still created with 2 references instead of 1, so I have to dig further.

Mediainfo of the newly created file with NVEnc:

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4.1
Format settings : 2 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 2 frames
Format settings, GOP : N=1
Format settings, wrapping mode : Frame
Format settings, Slice count : 8 slices per frame
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 114 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 2.193
Stream size : 8.39 GiB
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


Mediainfo of the same file created with x264:


Video
ID : 1001
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2 Intra@L4.1
Format settings, CABAC : No
Format settings, GOP : N=1
Format settings, wrapping mode : Frame
Format settings, Slice count : 8 slices per frame
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 114 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : MBAFF
Scan order : Top Field First
Bits/(Pixel*Frame) : 2.193
Stream size : 8.39 GiB
Title : V1
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709



If I can get it to output with 1 reference frame and with zero filling / padding I might have something in my hands here. :)

[Z2697]

My question is, does the "very strict CBR" all that important?
x264 is wasting bits with zero padding in this case, nvenc is actually maintaining a frame size close to the target, which means no wasted bits.
The obvious choice is to disable the filler in x264, or ignore the fluctuations in nvenc, let them just average out.

The reference frame number shouldn't matter if you encoding in all intra mode. Intra frames don't have any reference frame.

Oh, and the bitrate deviation and marcoblock difference seems not very severe in all intra mode, I didn't notice it's the all intra case we are talking, sorry.
(not very severe but still ~10% zero bits)

As for the speed of x264 in this case, I think you can tune down a lot of things to make it a lot faster, without significant difference in the quality, because you are encoding all intra and the frame size is constricted to basically constant, there's no much room for adjusment that can be done by x264 parameters.
(Tune down things from high preset, or only crank up the important ones from low preset)

[excellentswordfight]

My question is, does the "very strict CBR" all that important?
x264 is wasting bits with zero padding in this case, nvenc is actually maintaining a frame size close to the target, which means no wasted bits.
The obvious choice is to disable the filler in x264, or ignore the fluctuations in nvenc, let them just average out.
In the world of DI-formats, yes. As these are used for in a vast amount of cases were compliance is critical, and as for strict CBR, although I have not seen this cause real world issues with any equipment/software, it can get rejected when used as deliveries if it gets picked up by an compliance analyzer in the receiving end. And I have experienced exactly that when setting up up encoders using FOSS solutions in the past, that have needed a bit of tuning to create files that passes.

@FranceBB have you looked if the issues with slices etc is a limitation in the sdk/api or just not implemented in ffmpeg?

Gonna have check with some of the vendors to see if there is any plans, and if they have had any discussions with nvidia.

edit. XAVC-flavors encoding using nvenc is under development in commercial products at least. So if its not possible today to configure nvenc to create compliant streams, maybe at least that work would lead to changes in the sdk to expose better control so it could later find support in FOSS solutions .

[FranceBB]

My question is, does the "very strict CBR" all that important?

Yes, the use case for those kind of files is an hardware playback port that is used for playout, the likes of Imagine Versio, so compliance is paramount. Those hardware playback ports are the bread and butter of linear tv and they're what used for playout, so the last thing you want is for them to crash and make the channel go black (that's potentially thousands of quids wasted very quickly).

In the world of DI-formats, yes. As these are used for in a vast amount of cases were compliance is critical.

I can confirm this.


The reference frame number shouldn't matter if you encoding in all intra mode. Intra frames don't have any reference frame.


I know, but the metadata is wrong nonetheless, so I would rather it not being there and be actually set correctly rather than being wrong. It's very easy for AutoQC to fail when you're sending those things out to other broadcasters etc. Having a reframe higher than 1 is definitely something that tools like Cerify, Aurora, Qualify, Baton etc check and will flag as error / straight rejection.




have you looked if the issues with slices etc is a limitation in the sdk/api or just not implemented in ffmpeg?


Slices are there in the SDK and they were also implemented in FFMpeg, however they were not documented, I had to dig in the source code to find the -slices command. Once I introduced -slices 8 it created 8 and -slices 10 created 10, according to which standard one wants to adhere (Sony is 8 with XAVC, Panasonic is 10 with AVC Ultra).



XAVC-flavors encoding using nvenc is under development in commercial products at least.

That's very good to know. The last two things we need to address are:

1) why -refs 1 is being ignored when I pass it in FFMpeg
2) someone to implement enableFillerDataInsertion in FFMpeg as it's already supported by the NVIDIA SDK


On this second point, one of my colleagues from Sky News talked to Timo Rothenpieler, one of the maintainers of the FFMpeg NVEnc integration and Timo replied with:


For AV1 the equivalent option seems to be enabled by default already. So I wouldn't even be opposed to just flat out enabling this by default when in CBR mode. Cause i can't think of a reason to use CBR and not want the padding. Just send a patch for it.


So, as long as someone is willing to create and submit a patch for it, he will accept it and merge it to the main FFMpeg repository.
Once that is out of the way, if we can also get -refs 1 interpreted and populated correctly in the metadata (point 1), I'd say that we achieved our result and we can start seriously testing on hardware playout ports. :D

[excellentswordfight]

That's very good to know. The last two things we need to address are:

1) why -refs 1 is being ignored when I pass it in FFMpeg
2) someone to implement enableFillerDataInsertion in FFMpeg as it's already supported by the NVIDIA SDK
I also noticed in your post that High 4:2:2 Intra Profile is not flagged, looking at the sdk documentation (I did not look at the source code), I cannot find the intra profiles either. It is ofc possible to do intra-only encoding, but the profile flag should be correct as well.

[Z2697]

There're spikes in nvenc encoded streams still, the filler will not eliminate those?

[excellentswordfight]

There're spikes in nvenc encoded streams still, the filler will not eliminate those?
According to the nvenc documentation maxrate should eliminate those, but maybe thats only in effect in vbr mode, but maybe vbr+maxrate creates more of a "true" cbr bitrate distrubution?

[FranceBB]

I also noticed in your post that High 4:2:2 Intra Profile is not flagged, looking at the sdk documentation (I did not look at the source code), I cannot find the intra profiles either. It is ofc possible to do intra-only encoding, but the profile flag should be correct as well.

Correct.
In x264 this is changed automatically, in fact even when you specify --profile high422 in combination with --keyint 1 then the actual profile gets set to High 4:2:2 Intra instead of High 4:2:2.

In particular, taking a peek at the x264 source code in set.c (line 143) we have


if( param->i_keyint_max == 1 && sps->i_profile_idc >= PROFILE_HIGH )
sps->b_constraint_set3 = 1;


which sets b_constraint_set3 to true when the keyint is set to 1 and therefore in encoder.c (line 1841)

h->sps->i_profile_idc == PROFILE_HIGH422 ?
(h->sps->b_constraint_set3 ? "High 4:2:2 Intra" : "High 4:2:2")

instead of using the normal High 4:2:2 profile we automatically switch to the High 4:2:2 Intra profile, which is the right thing to do.

Ideally, NVEnc should be doing the same and implement the same logic, but currently they're not doing it, which is why the High 4:2:2 profile is used instead.

There're spikes in nvenc encoded streams still, the filler will not eliminate those?

There are, but that's only because we're encoding a not-so-complex content and in some scenes it doesn't really need that much bitrate. The spikes are there but don't seem to be overshooting, in other words, they don't seem to be going above the specified maximum. This means that, once the rest of the frames with undershooting are gonna be zero-filled / padded, they will also be at the same size and therefore we're gonna get a true 113664 kbit/s constant bitrate.

Anyway, the enableFillerDataInsertion is supported by the NVIDIA SDK which means that someone needs to implement it in FFMpeg. One of my colleagues had a chat with Timo Rothenpieler which is one of the FFMpeg maintainers and he seems to be onboard with it, in the sense that if someone is gonna send a patch to enable it by default when we're using CBR, then he will merge it, but someone has to submit a patch nonetheless.


There's still the problem with -refs 1 being ignored and having the reference frames reported as 2 instead anyway. So, the reframe and the wrong profile are two blockers and my colleagues just bumped into the NVIDIA guys at NAB and reached out to them about those very specific issues. We'll see where we go from here, but they're now definitely aware of this. :)

[Z2697]

"-rc cbr" seems to enable the filler.
But I only tested on RTX 40.
I guess there's something missing in the "new" format settings.
Maybe you can try test the "old" yuv420p and see if the filler works.

update: Just checked FFmpeg's nvenc settings and I found a option named "cbr_padding".
commited this month
https://github.com/FFmpeg/FFmpeg/commit/839b41991d5ee6b9179fede9a402f7e15f859f0a

[takla]

Unfortunately, it doesn't really look good... :(
I managed to get my hands on an NVIDIA RTX 5080 and I started experimenting a bit.


1) Level 4.1 is limited to: 60000/60000/75000 for bitrate, maxbitrate and vbv buffer, respectively.
2) The H264 Nvidia Encoder of the RTX 5000 series only supports yuv420 8bit & yuv422 8bit (https://developer.nvidia.com/video-encode-decode-support-matrix)

With those limitations in mind and with respect to your proposed settings, I've crafted the following command for the open source NVenc by rigaya (https://github.com/rigaya/NVEnc) which offers a far superior implementation than the, I want to say, half-assed approach of FFmpeg.


NVEncC64.exe --codec h264 --level 5.0 --cbr 100000 --max-bitrate 100000 --vbv-bufsize 100000 --preset p7 --output-csp yuv422 --lookahead 0 --no-i-adapt --no-b-adapt --strict-gop --gop-len 1 --bframes 0 --ref 1 --slices 8 --cavlc --split-enc forced_2 --colormatrix bt709 --colorprim bt709 --transfer bt709 --colorrange limited -i TEST.mkv -o AVC.mkv


Console output result:
NVEncC (x64) 9.03 (r3425) by rigaya, Sep 15 2025 13:01:40 (VC 1944/Win)
OS Version Windows 11 x64 (26100) [UTF-8]
CPU AMD Ryzen 5 7600X 6-Core Processor [5.45GHz] (6C/12T)
GPU #0: NVIDIA GeForce RTX 5070 Ti (8960 cores, 2497 MHz)[PCIe4x16][580.88]
NVENC / CUDA NVENC API 13.0, CUDA 13.0, schedule mode: auto
Input Buffers CUDA, 17 frames
Input Info avsw: utvideo(yv12)->nv12 [AVX2], 1280x720, 24000/1001 fps
Vpp Filters cspconv(nv12 -> yuv444)
cspconv(yuv444 -> nv16)
Output Info H.264/AVC high422 @ Level 5
1280x720p 0:0 23.976fps (24000/1001fps)
avwriter: h264 => matroska
Encoder Preset quality
Rate Control CBR
Multipass none
Bitrate 100000 kbps (Max: 100000 kbps)
Target Quality auto
QP range I:0-51 P:0-51 B:0-51
QP Offset cb:0 cr:0
VBV buf size 100000 kbit
Split Enc Mode forced_2
Lookahead off
GOP length 1 frames
B frames 0 frames [ref mode: disabled]
Ref frames 1 frames, MultiRef L0:auto L1:auto
AQ off
Slices 8
VUI matrix:bt709,colorprim:bt709,transfer:bt709,range:limited
Others mv:auto cavlc deblock adapt-transform:auto

encoded 14441 frames, 681.66 fps, 76793.30 kbps, 5513.83 MB
encode time 0:00:21, CPU: 19.9%, GPU: 8.9%, VE: 48.6%, GPUClock: 2882MHz, VEClock: 2323MHz
frame type IDR 14441
frame type I 14441, avgQP 6.02, total size 5513.83 MB


MediaInfo:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L5
Format settings : 1 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 1 frame
Format settings, GOP : N=1
Format settings, Slice count : 8 slices per frame
Codec ID : V_MPEG4/ISO/AVC
Duration : 10 min 2 s
Bit rate : 75.3 Mb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 3.407
Stream size : 5.28 GiB (98%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709



FFBitrateViewer result (https://i.ibb.co/Zps84LG7/AVC100.png)

[excellentswordfight]

1) Level 4.1 is limited to: 60000/60000/75000 for bitrate, maxbitrate and vbv buffer, respectively.

Note that we are discussing the High 4:2:2 Intra Profile

"The maximum bit rate for the High Profile is 1.25 times that of the Constrained Baseline, Baseline, Extended and Main Profiles; 3 times for Hi10P, and 4 times for Hi422P/Hi444PP."

https://en.wikipedia.org/wiki/Advanced_Video_Coding#Profiles

XAVC-I uses level 4.1 for 1080i25/30 and 4.2 for 1080p50/60.

[takla]

Note that we are discussing the High 4:2:2 Intra Profile

"The maximum bit rate for the High Profile is 1.25 times that of the Constrained Baseline, Baseline, Extended and Main Profiles; 3 times for Hi10P, and 4 times for Hi422P/Hi444PP."

https://en.wikipedia.org/wiki/Advanced_Video_Coding#Profiles

XAVC-I uses level 4.1 for 1080i25/30 and 4.2 for 1080p50/60.

Good info.
But there are no intra profiles for the Nvidia encoder.
Valid profiles for H264 NVenc are:
baseline, main, high, high10, high422 8bit, high444 8bit

[excellentswordfight]

Good info.
But there are no intra profiles for the Nvidia encoder.
Valid profiles for H264 NVenc are:
baseline, main, high, high10, high422 8bit, high444 8bit
Hence my previous post :)
I also noticed in your post that High 4:2:2 Intra Profile is not flagged, looking at the sdk documentation (I did not look at the source code), I cannot find the intra profiles either. It is ofc possible to do intra-only encoding, but the profile flag should be correct as well.
Which is currently a dealbreaker as the biggest sellingpoint of a 4:2:2 encoder would be for these broadcast/DI/Mezz formats (XAVC/AVC-I), like there a a whole industry doing thousands and thousands of hours of encodes in these formats on cpu currently.

[FranceBB]

It's been a while since the last time we updated this thread, but we never stopped working. Over the last few months we were able to get in touch with the NVIDIA developers directly and show them what we were trying to achieve in our tests.

This led to an almost endless series of trial and errors on test drivers not available to the public in which we've been experimenting for almost 8 months up until now. As we approach Christmas and we get ready to wrap up the year, our testing has come to an end and we're finally seeing the results of NVIDIA's hard work as they worked on our feedbacks.


In our latest test with the non-public test drivers from December 12, 2025, we were finally able to achieve the right specs and produce a correct FULL HD 1920x1080 Profile High Level 4.1 ref 1 keyint 1 slices 10 114 Mbit/s 4:2:2 25i TFF BT709 SDR 10bit planar + PCM 24bit 48000Hz mxf file.

The following command line taking the input from Avisynth as a frameserver and producing the raw_video.h264 via NVEnc and raw_audio.wav via Lavc muxed in an mxf container by BMX using an NVIDIA RTX 5080 on Windows 11 Enterprise 25H2 x64


ffmpeg.exe -i "AVS Script.avs" -pix_fmt yuv422p10le -c:v h264_nvenc -aspect 16:9 -r 25 -vf setfield=tff -flags +ildct+ilme -preset p1 -tune ull -profile:v high -level 4.1 -b:v 113664k -minrate 113664k -maxrate 113664k -bufsize 2274k -rc cbr -cbr true -g 0 -rc-lookahead 1 -lookahead_level 0 -no-scenecut true -forced-idr true -b_adapt false -b_ref_mode 0 -nonref_p false -weighted_pred 0 -max_slice_size 0 -slices 10 -coder cavlc -aud true -refs 1 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv -chroma_sample_location topleft -signal_standard 4 -c:a pcm_s24le -ar 48000 -timecode 10:00:00:00 -f mxf -max_muxing_queue_size 700 -map_metadata -1 -metadata "creation_time=now" - | bmxtranswrap.exe -p -y 10:00:00:00 -t op1a -o "output.mxf" -


produced the appropriate AVC Intra Class 100 output:



General
Complete name : output.mxf
Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 8.90 GiB
Duration : 10 min 34 s
Overall bit rate : 121 Mb/s
Frame rate : 25.000 FPS
Encoded date : 2025-12-18 13:43:41.748
Writing application : BBC bmx 1.6.0.0.0
Writing library : libMXF (Win64) 1.6.0.0.0
Video
ID : 1001
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2 Intra@L4.1
Format settings : 1 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 1 frame
Format settings, wrapping mode : Frame
Format settings, Slice count : 10 slices per frame
Codec ID : 0D01030102106001-0401020201323001
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 114 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 2.193
Stream size : 8.39 GiB (94%)
Title : V1
Color range : Limited
Matrix coefficients : BT.709
Audio #1
ID : 2001
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 87.1 MiB (1%)
Title : A1
Locked : Yes
Audio #2
ID : 2002
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 87.1 MiB (1%)
Title : A2
Locked : Yes
Audio #3
ID : 2003
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 87.1 MiB (1%)
Title : A3
Locked : Yes
Audio #4
ID : 2004
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 87.1 MiB (1%)
Title : A4
Locked : Yes
Audio #5
ID : 2005
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 87.1 MiB (1%)
Title : A5
Locked : Yes
Audio #6
ID : 2006
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100
Duration : 10 min 34 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 87.1 MiB (1%)
Title : A6
Locked : Yes
Other #1
ID : 901-Material
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:10:34:03
Time code settings : Material Package
Time code, stripped : Yes
Title : TC1
Other #2
ID : 901-Source
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:10:34:03
Time code settings : Source Package
Time code, stripped : Yes
Title : TC1


The buffer also looks fine, although we do occasionally get some brief overshooting (which shouldn't be a problem as long as the hardware playback port support higher classes as their physical registers will not overflow):

https://i.postimg.cc/Y9Czqtp3/image.png

Checking the file with the HEX Editor we can see the bitstream

https://i.postimg.cc/DZ0135gc/image.png

followed by the padding (i.e NVEnc is correctly zero-filling in most areas to meet the target bitrate):

https://i.postimg.cc/X7Sx9SLm/image.png


Although the bitrate control is worse compared to x264, the fact that this is entirely achieved on hardware while achieving 10x realtime encoding speed for normal FULL HD contents is highly impressive.



As of today (December 18th 2025), we've given NVIDIA our seal of approval which means that those test drivers will eventually be promoted to stable and will be released to the public come 2026.

This is a huge step forward and will make generating TX Ready files for broadcasting companies much quicker compared to pure software encoding on the CPU. The fact that this can be achieved via Avisynth, FFMpeg and BMX (which are entirely open source) using NVEnc makes it a great victory for everyone who has a modern NVIDIA GPU. On top of this, it can also be automated via FFAStrans with the filter_builder generating the appropriate filterchain before it delivers the correct uncompressed A/V stream living in RAM to NVEnc.


It took a while, but we finally got there. :D

[tormento]

It took a while, but we finally got there. :D
How many times did I told you to use GPUs? :)

[FranceBB]

How many times did I told you to use GPUs? :)

Well, I am now xD

https://images2.imgbox.com/46/ea/48VrACv2_o.png

[Z2697]

It's a bit hard to understand, this threads has Nvenc in its title, what's the option to use "not GPUs"?
(Well technically it's an ASIC chip that's not really "inside" the GPU, but you know)

And if it's something from the past, AVC 4:2:2 encoding only gets added in RTX50 series no matter how smart you are.

[FranceBB]

It's a bit hard to understand, this threads has Nvenc in its title, what's the option to use "not GPUs"?

It's a recurring joke about the argument we routinely have about using NVEnc vs x264 'cause he has always been in favor of it and I've always been against it (we're both Italian).

Internally at Sky I've always been one of the people arguing that using NVEnc wouldn't make sense 'cause for distribution encoding using software encoding with x264 will achieve better result both in subjective quality and in SSIM / PSNR and the cost of encoding something on the CPU nowadays - especially for FULL HD - is almost negligible. x264 scales up to vertical resolution divided by 40, which means that for FULL HD you would have 1080/40 = 27 threads which are easily achievable with modern CPUs.

AVC 4:2:2 encoding only gets added in RTX50 series

Yep, that's what started everything 'cause now for the first time we had NVEnc being capable of encoding mezzanine files like AVC Intra Class 100 which is used in the UK instead of distribution files. Of course, x264 still remains better in terms of quality, but this paved the way to a new use case: Sky News clips. You see, for news we get clips from all over the world from quite literally any source, because if you have - let's say - a fire somewhere you get people passing by filming it with whatever mobile phone at whatever resolution with whatever framerate with whatever codec with whatever sampling with whatever chroma placement with whatever colormatrix, transfer and primaries etc. When those get downloaded, they're then passed to a workflow that indexes the file, checks the frame properties from the indexer and cross references those with ffprobe and Mediainfo and then the filter_builder creates the filterchain in Avisynth to go from the input to whatever the destination is supposed to be so that it can deliver the uncompressed A/V Stream to x264 which encodes in AVC Intra Class 100 and then sends it to AVID Mediadirector which checks it into AVID Interplay. From there, it can then be edited and scheduled to be played on an hardware playback port by the Viz Mosart. Obviously, clips from random users are always at a far lower quality than what they're re-encoded into (in this case FULL HD 1920x1080 Profile High Level 4.1 ref 1 keyint 1 slices 10 114 Mbit/s 4:2:2 25i TFF BT709 SDR 10bit planar + PCM 24bit 48000Hz muxed in an mxf container), so in x264 most of the time the stream undershoots and is zero-filled to meet the target bitrate. This also means that it won't really matter if we encode them with the GPU using NVEnc to use the hardware encoder (ASIC) within those chips 'cause the quality loss compared to x264 in this case is basically non-existing. On the other hand, the speedup is significant. We're talking about 3-4 times for heavy filtering and almost 10 times when we only have to re-encode without any filtering (not even dividing in fields if it's already interlaced).


This might be off topic, but if you wanna know the logic behind the workflow in the filter_builder, shout and I'll recap it/write it down.

[excellentswordfight]

It took a while, but we finally got there. :D
Amazing, as a broadcaster myself this is very cool!

Have you tried any of the other flavors? i.e. XAVC-I for 1080p and 2160p (Class300/480), I assume they should work as well? We stayed with XDCAM for 1080i, so personally my use cases are more for 1080p and 2160p. We are also looking at XAVC long GOP when we make the full 1080i->1080p transition, as keeping 50Mbps instead of going up to 200Mbps is quite enticing. Here are some details on the Long GOP format structure https://www.ard.de/die-ard/ARD-ZDF-XDF-01-MXF-Profile-for-XAVC-Long-GOP-50-Mbit-s-1080p508-16-mono-AES3-PCM-Audio-Tracks-100.pdf

But exciting times, would be very cool to see the full capture, editing, export, playout life-cycle all decode/encode done on GPU!

And you know if there is actually any difference at all, on a h264 or bitstream level between (panasonic) AVC-I and (sony) XAVC-I for 1080i? Is it only vendor metadata?

Now we also need nvidia to release a updated version of NVIDIA L4 so you can have server-cards for production/server scenarios.

[FranceBB]

The main difference are the slices: AVC from Panasonic uses 10 slices while XAVC uses 8 slices, so in theory it should be possible to create an XAVC Intra Class 300 output as well.

When everyone is back from the holidays, I'll try to encode a movie in both ways and run it through SSIM/PSNR and compare it with the x264 output

[Z2697]

I bet it will end up being determined by how much each of them undershoots the bitrate really...

[FranceBB]

@excellentswordfight can you try to encode a content with this? It should be able to generate an XAVC Intra Class 300.

In other words, we're creating a UHD 3840x2160 Profile High Level 5.2 ref 1 Slices 8 500 Mbit/s 4:2:2 50p BT709 SDR 10bit planar



ffmpeg.exe -i "AVS Script.avs" -pix_fmt yuv422p10le -c:v h264_nvenc -aspect 16:9 -r 25 -preset p1 -tune ull -profile:v high -level 5.2 -b:v 500000k -minrate 500000k -maxrate 500000k -bufsize 10000k -rc cbr -cbr true -g 0 -rc-lookahead 1 -lookahead_level 0 -no-scenecut true -forced-idr true -b_adapt false -b_ref_mode 0 -nonref_p false -weighted_pred 0 -max_slice_size 0 -slices 8 -coder cavlc -aud true -refs 1 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv -chroma_sample_location topleft -c:a pcm_s24le -ar 48000 -timecode 10:00:00:00 -f mxf -max_muxing_queue_size 700 -map_metadata -1 -metadata "creation_time=now" - | bmxtranswrap.exe -p -y 10:00:00:00 -t op1a -o "output.mxf" -


Note the different level, bitrate and slices.

[excellentswordfight]

@excellentswordfight can you try to encode a content with this? It should be able to generate an XAVC Intra Class 300.

In other words, we're creating a UHD 3840x2160 Profile High Level 5.2 ref 1 Slices 8 500 Mbit/s 4:2:2 50p BT709 SDR 10bit planar



Note the different level, bitrate and slices.
Unfortunately, I dont have access to any 5000-series card, but if you can upload a 1min sample I can run it through some analyse tools, and also some playout-servers to see if I can find any compliance issues. We could also see if it works with things like adobe:s smart render.

[RichardK]

Amazing, as a broadcaster myself this is very cool!

Have you tried any of the other flavors? i.e. XAVC-I for 1080p and 2160p (Class300/480), I assume they should work as well? We stayed with XDCAM for 1080i, so personally my use cases are more for 1080p and 2160p. We are also looking at XAVC long GOP when we make the full 1080i->1080p transition, as keeping 50Mbps instead of going up to 200Mbps is quite enticing. Here are some details on the Long GOP format structure https://www.ard.de/die-ard/ARD-ZDF-XDF-01-MXF-Profile-for-XAVC-Long-GOP-50-Mbit-s-1080p508-16-mono-AES3-PCM-Audio-Tracks-100.pdf

But exciting times, would be very cool to see the full capture, editing, export, playout life-cycle all decode/encode done on GPU!

And you know if there is actually any difference at all, on a h264 or bitstream level between (panasonic) AVC-I and (sony) XAVC-I for 1080i? Is it only vendor metadata?

Now we also need nvidia to release a updated version of NVIDIA L4 so you can have server-cards for production/server scenarios.

Hi, I'm one of the authors of that document.

I had a RTX PRO 4000 for testing NVENC 10 bit 422 support and was able to get quite close to the XAVC L50 specifications. For encoding, I used ffmpeg nvenc with a standard GYAN build, and for MXF wrapping, I used bmxtranswrap with our XDF-01 profile, since ffmpeg writes faulty index tables (missing temporal offsets).

I found out that the dpb size param is not sufficient for achieving the target GOP structure und references. I cannot assess the technical interactions of nvenc and ffmpeg encoding parameters so it was a little bit of trial and error. My target was a GOP length of 24, an IDR frame at the beginning of every GOP, an IBBP structure and max 2 references for a b frame without visible artifacts.

- bf 2 is necessary for the IBBP GOP structure
- DPB 4 -> B frames will have 4 references instead of 2 references
- DPB 2 -> B frames will have 2 references, but there are visible artifacts
- DPB 4 and refs 1 -> B frames will have 2 references and there are no artifacts

ffmpeg commandline:

.\ffmpeg.exe -y -r 50 -i xdf_ref.mxf -c:v h264_nvenc -s 1920:1080 -aspect 16:9 -r 50 -preset p5 -tune hq -profile:v high422 -level:v 4.2 -pix_fmt p210le -rc vbr -cbr false -cbr_padding false -rc-lookahead 24 -lookahead_level 0 -b_adapt false -b_ref_mode 0 -weighted_pred 0 -max_slice_size 0 -slices 4 -aud true -g 24 -dpb_size 4 -refs 1 -coder cabac -bf 2 -b:v 49999872 -maxrate 49999872 -bufsize 49999872 -no-scenecut true -forced-idr true -color_primaries bt709 -color_trc bt709 -colorspace bt709 -c:a pcm_s24le -ar 48000 -map 0:v -map 0:a -timecode 10:00:00:00 -f mxf nvenc_output_longgop.mxf

bmx commandline:

.\bmxtranswrap.exe -l logfile.txt -t op1a -y 10:00:00:00 --ard-zdf-xdf -o nvenc_bmx_output_longgop.mxf .\nvenc_output_longgop.mxf


It would be interesting to hear your test results and whether there are any further optimization possibilities for the parameters.

Unfortunately, NVENC is still writing the following parameters incorrectly to the bitstream:

- log2_max_frame_num_minus4 = 4 (8) instead of 0 (4)
- log2_max_pic_order_cnt_lsb_minus4 = 4 (8) instead of 1 (5)
- max_num_ref_frames = 4 instead of 2

It would be good to fix that, even if it doesn't seem to have a noticeable impact on interoperability.

I hope this information helps you with testing and encoding.