SVT releases opensource content for encoding R&D

[TEB]

https://www.svt.se/opensource/content

https://www.svt.se/opensource/assets/doc/SVT_Open_Content_Video_Test_Suite_2022_Natural_Complexity_v1-1-reduced.pdf

ftp://svtopencontent.svt.se


Happy encoding!

[Sovereign_Bits]

Ancient long time lurker first time poster here

I am looking for some footage to test a couple of encoders internally at our firm and this seems to fit the bill rather nicely. The goal is to create high quality files distribution so we are much more interested in quality than time which is why we need high quality input files. I have worked within post for many years but I have no academic background nor do I posses any programming knowledge to speak of. So I have a couple of questions that I hope someone around here can answer.

We are mainly interested in the bt.709 stuff but these files seems to be encoded with 12 bit YCbCr, is there any actual benefit to this over 10 bit? I understand that 12 bit allows for higher color precision and more information, but since I will be creating 8 bit and 10 bit exports do I gain anything from using a 12 bit input rather than a 10 bit input?

The clips are rather long (1 min) for single camera angle scenes but is there a reason why I would want to run an encoder for that amount of time to "truly" test it out? Or will I get the same result running encodes for 20-30 sec?

Finally the paper claims that all of the files are use lossless compression yet they all have vastly different file sizes. Is this to be expected? Although the writers claim otherwise, I must say that most of the technical text in this document is beyond my comprehension. I am not new to JPEG2000 but I have never seen a lossless variant of that codec.

Thanks in advance and thanks for such great footage.

[benwaggoner]

There's really not much added value in a 12-bit RGB source for 10-bit encoding, no. If you input at 12-bit to x265, you can use the --dither parameter to nominally improve quality a bit.

Lossless compression can vary in size a lot, based on the complexity of the content. Generally the less detail, the higher the compression ratio.

[Sovereign_Bits]

Okay that is pretty much in line with my expectations.

Thank you Ben for the info.

[excellentswordfight]

The clips are rather long (1 min) for single camera angle scenes but is there a reason why I would want to run an encoder for that amount of time to "truly" test it out? Or will I get the same result running encodes for 20-30 sec?
This is the reason why I'm not that interested in this specific test suite. I have always preferred tuning and testing encoders on the type of content that it will actually be used for.

But cudos to SVT for providing this, but imo, it's more useful for academic and theoretical applications and maybe not so much for real life optimizing of encoders. But I'm sure that it has value for SVT as they do more ENG 50p un-stylized type of content. This is also why I always have been very appreciative of Tears of Steel as its a rather nice sample of your typical 1080p24 SDR live action movie. And I would love to see something similar for 2160p24 HDR!

[Sovereign_Bits]

I agree that it is always preferable to test encoders on the content that we are actually going to encode or at least content that is very similar. We will certainly include some of our production content in our tests as well.

And while I also agree that this suite seems more academic it is always nice to be able to share footage with encoder vendors and developers without having to go through a more or less arduous legal process.

[benwaggoner]

2160p24 HDR!
You can slow it down to 48 fps and then encode every other frame. That's how NTSC<>PAL conversions used to be done.