[SCP-2223] Sol Levante [v2][Netflix 4K HDR Master][Lossless AV1 12-bit 444 + AV1 @ crf15 12-bit 444][FLAC 5.1 + 2.0][E-AC3 Atmos 5.1][CC BY-NC-ND 4.0][0DDE1B9E]

Category:
Date:
2021-12-19 01:48
Submitter:
Seeders:
3
Information:
Leechers:
0
File size:
81.4 GiB
Completed:
104
Info hash:
3e67eac1b30aebf100dadb1328dd404ee73a87cd

Warning: You WILL need a pretty beefy CPU (AMD Threadripper / EPYC, or top of line Intel Xeons) and at least an SSD (NVMe/ramdisk preferable) to play this in realtime. Otherwise mpv or similar should “just” work. If desired there is a second lossy video track at crf15, which should be decodeable on most devices, given your I/O thread keeps up! Needs about 2.6 Gbit/s of I/O :)

What’s this?

A year ago Netflix released an anime flex in the form of Sol Levante, a from-scratch 4K HDR production that lasts 5 minutes. They also released the lossless raws, which is pretty cool.

This is a lossless AV1 12-bit 4:4:4 encode with HDR metadata. First done as a way to insert a “legit” lossless meme into a specific tracker using allowed rules (only AV1 had +10 bitdepth allowed, on this site), the project quickly derailed due to AV1-related tooling not providing proper methods to work with HDR, HDR10, or specs not being completed. In addition it was found that mediainfo had several bugs, which made debugging of AV1 issues harder.

The encoded video was sourced from the master VDM TIFF sequence (in 16bit, but their own process brings it down to 12bit for release). See Netflix’s blogpost for more details, and here’s the source files for this (under vdm folder).
Alternatively use this command to download them: $ aws s3 cp s3://download.opencontent.netflix.com/SolLevante . --recursive --no-sign-request

Other general issues are working with a source with Full(pc) color space, not Partial(tv). Most tools out there assume partial color space, and/or make it hard to make the entire chain be full color space, without conversions.

Several encodes had to be scrapped due to some of these problems. And let me tell you, AV1 encoding is slow, specially with libaom, although better than in the past. Even using some top-of-the-line AMD EPYC cpus, it still takes several hours to encode 5 minutes of 4K footage, on cpu-used=3. In the end after several attempts, segfaults, patches, an encode with cpu-used=2 has been used.

Additionally special tools to work with AV1’s bitstream OBU format were created, to inject HDR10 metadata due to the inability of libaom to do so itself. It was also found that libav based systems do not look for HDR tags inside AV1 streams, requiring the tags to also be placed on the Matroska file.

All in all, I’d say AV1 was not ready for this, but now there are tools for it!

Decoding information

Good luck. You will need it. There is no hardware decoder that can ingest this.

AV1 is interesting as VP9 did where to encode with threads you split the file in rows/columns. This is also the only way to thread decoding. Meaning for more efficient decoding, you need as many threads as it was encoded with (though it IS faster).

This was encoded in a system with two AMD EPYC™ 74F3 CPUs, for a total of 512 MB of L3 cache. 96 threads. Lossless encode was faster than lossy, it stayed about 40 fpm (yes frames per minute) on heavy scenes, and about 1.4 fps on static scenes.

For decoding, would recommend many threads over few powerful cores.

Please comment your experience on decoding this file. Include player / CPU / backing storage / other notes.

Other notes

Included as attachments on the Matroska container are, the license file, a steps.md file with commands of how to create the media from source, and the av1-hdr.php tool for metadata injection.
These can be extracted using $ mkvextract attachments "[SCP-2223] Sol Levante [v2][Netflix 4K HDR Master][Lossless AV1 12-bit 444 + AV1 @ crf15 12-bit 444][FLAC 5.1 + 2.0][E-AC3 Atmos 5.1][CC BY-NC-ND 4.0][0DDE1B9E].mkv" $(seq 1 3)

Was going to make a larger release post, but other bugs that require people to obtain this sample file made this necessary earlier than expected.

License

This content is licensed Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license (CC BY-NC-ND 4.0). See Matroska attachment for full license.

Mediainfo

Partial mediainfo listed due to lack of post space. Full Mediainfo here

General
Unique ID: 134697691581549152805837957184331960461 (0x6555D4EE9860A097835389C1AE8BD08D)
Complete name: [SCP-2223] Sol Levante [v2][Netflix 4K HDR Master][Lossless AV1 12-bit 444 + AV1 @ crf15 12-bit 444][FLAC 5.1 + 2.0][E-AC3 Atmos 5.1][CC BY-NC-ND 4.0][0DDE1B9E].mkv
Format   : Matroska
Format version   : Version 4
File size: 81.4 GiB
Duration : 4 min 28 s
Overall bit rate : 2 608 Mb/s
Movie name   : [SCP-2223] Sol Levante [v2][Netflix 4K HDR Master][Lossless AV1 12-bit 444 + AV1 @ crf15 12-bit 444][FLAC 5.1 + 2.0][E-AC3 Atmos 5.1][CC BY-NC-ND 4.0]
ErrorDetectionType   : Per level 1
Attachments  : av1-hdr.php / steps.md / sollevante-cclicense.txt

Video #1
ID   : 1
Format   : AV1
Format/Info  : AOMedia Video 1
Format profile   : Professional@L5.0
HDR format   : SMPTE ST 2086, HDR10 compatible
Codec ID : V_AV1
Duration : 4 min 23 s
Bit rate : 2 613 Mb/s
Width: 3 840 pixels
Height   : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode  : Constant
Frame rate   : 24.000 FPS
Color space  : YUV
Chroma subsampling   : 4:4:4
Bit depth: 12 bits
Bits/(Pixel*Frame)   : 13.126
Stream size  : 80.0 GiB (98%)
Title: Lossless AV1 12-bit 4:4:4 from sollevante_lp_vdm_16b_p3d65_pq_20200218_3840x2160
Writing library  : libaom-av1 AOMedia Project AV1 Encoder 3.2.0-243-gdd950e6c6
Encoding settings: threads=96 lossless=1 usage=0 profile=2 bit-depth=12 use-16bit-internal pass=1 passes=1 cpu-used=2 frame-parallel=1 lag-in-frames=12 row-mt=1 tile-columns=3 tile-rows=3 enable-fwd-kf=1 kf-min-dist=240 kf-max-dist=240 color-primaries=smpte432 transfer-characteristics=smpte2084 matrix-coefficients=bt2020ncl
Language : English
Default  : Yes
Forced   : No
Color range  : Full
Color primaries  : Display P3
Transfer characteristics : PQ
Matrix coefficients  : BT.2020 non-constant
Mastering display color primaries: Display P3
Mastering display luminance  : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level  : 993
Maximum Frame-Average Light Level: 362
Copyright: Netflix, Inc.
Encoded by   : WeebDataHoarder
IMDB : tt12079068
LICENSE  : Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license (CC BY-NC-ND 4.0)
Original source form : VDM 16-bit Master
PRODUCTION_STUDIO: Netflix
TMDB : movie/688900
Terms of use : https://creativecommons.org/licenses/by-nc-nd/4.0/

Video #2
ID   : 2
Format   : AV1
Format/Info  : AOMedia Video 1
Format profile   : Professional@L5.0
HDR format   : SMPTE ST 2086, HDR10 compatible
Codec ID : V_AV1
Duration : 4 min 23 s
Bit rate : 39.6 Mb/s
Width: 3 840 pixels
Height   : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode  : Constant
Frame rate   : 24.000 FPS
Color space  : YUV
Chroma subsampling   : 4:4:4
Bit depth: 12 bits
Bits/(Pixel*Frame)   : 0.199
Stream size  : 1.21 GiB (1%)
Title: Lossy AV1 @ crf15 12-bit 4:4:4 from sollevante_lp_vdm_16b_p3d65_pq_20200218_3840x2160


Audio #1
ID   : 3
Format   : FLAC
Codec ID : A_FLAC
Bit depth: 24 bits
Stream size  : 103 MiB (0%)
Title: FLAC 5.1
Language : Japanese
Default  : Yes

Audio #2
ID   : 4
Format   : FLAC
Codec ID : A_FLAC
Bit depth: 24 bits
Title: FLAC 2.0
Language : Japanese

Audio #3
ID   : 5
Format   : E-AC-3 JOC
Commercial name  : Dolby Digital Plus with Dolby Atmos
Codec ID : A_EAC3
Bit rate mode: Constant
Bit rate : 768 kb/s
Channel(s)   : 6 channels
Channel layout   : L R C LFE Ls Rs
Stream size  : 24.5 MiB (0%)
Title: E-AC3 Atmos 5.1 (Netflix)
Bed channel count: 1 channel
Bed channel configuration: LFE

File list

  • [SCP-2223] Sol Levante [v2][Netflix 4K HDR Master][Lossless AV1 12-bit 444 + AV1 @ crf15 12-bit 444][FLAC 5.1 + 2.0][E-AC3 Atmos 5.1][CC BY-NC-ND 4.0][0DDE1B9E].mkv (81.4 GiB)

this is crazy!!! 81GB for 4 min 23 s !!!

DataHoarder (uploader)

User

A few other notes, apparently can’t edit description any longer. Message says “What the fuck are you doing?” which is very fitting.

AV1 is interesting as VP9 did where to encode with threads you split the file in rows/columns. This is also the only way to thread decoding. Meaning for more efficient decoding, you need as many threads as it was encoded with (though it IS faster).
This was encoded in a system with two AMD EPYC™ 74F3 CPUs, for a total of 512 MB of L3 cache. 96 threads. Lossless encode was faster than lossy, it stayed about 40 fpm (yes frames per minute) on heavy scenes, and about 1.4 fps on static scenes.
For decoding, would recommend many threads over few powerful cores.

Original raws were 314 GiB

Here is the steps.md file if you are lazy

only AV1 had +10 bitdepth allowed

lol

I thought AV1 was supposed to be used to actually compress files and not waste hdd space.
Evidently I was wrong XD

DataHoarder (uploader)

User

This compressed 314GiB into 80 GiB, I’d say it’s good!

This release is a meme

Wait, what the fuck?

WHY DIDN’T YOU USE A DEDICATED LOSSLESS CODEC FOR THIS INSTEAD OF AV1!!!

Like, there’s actually so much misinformation here holy shit.

  1. “AV1 is interesting as VP9 did where to encode with threads you split the file in rows/columns. This is also the only way to thread decoding. Meaning for more efficient decoding, you need as many threads as it was encoded with (though it IS faster).” This is not true at all. With dav1d and ffvp9 as well for VP9, you have 3 ways to thread: frame threading, tile threading, and row threading. You don’t only have tile threading.

  2. Why are you using static keyframe placements? That’s innefficient. Only do this if you are encoding for 3GPP or whatever.

  3. 64 tiles(2³ * 2³ = 64 tiles). That’s a lot of tiles lmao. Far too many in fact. Maybe if you were encoding at 8k, but even then, 32 tiles would be good enough.
    Also, you’re using non square tiles, which reduces efficiency. Better to use 8 tile columsn x 4 tiles rows instead, so it would be --tile-columns=3 --tile-rows=2 if you really wanted to.

  4. Again, using lossless AV1 is just so funny when it’s not very good.

  5. You’re using an amount of lookahead lower than default(default is 35, you have 12).

DataHoarder (uploader)

User

Tiles, are each part of row x column in this case.

RE: lookahead, took too long and segfaulted on many cases via libaom

Selection of lossless AV1 was to upload it on another tracker following their rules. No other reason, it is a meme.

You can only find the end encode but not all the scrapped ones that failed for a myriad of reasons, including why it used master libaom (again, could not properly encode without libaom)

This was done on a system with enough threads to back the row/tiles setting.

Holy fuck. Best. Shitpost. Ever. Highly doubt I will be able to play this, but keep it up.

is there a good enough reason to get this, I wonder