[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 UTC
Submitter:
Seeders:
1
Information:
Leechers:
0
File size:
81.4 GiB
Completed:
100
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](https://github.com/MediaArea/MediaInfoLib/pull/1457), 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](https://netflixtechblog.com/bringing-4k-and-hdr-to-anime-at-netflix-with-sol-levante-fa68105067cd) for more details, and [here's the source files](http://download.opencontent.netflix.com/?prefix=SolLevante/) 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](https://zerobin.net/?cec09faa14c62d19#Lp1rXhZYJehzXEIGOHICguirb7Zffsxg5aCKxkot2MY=) 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](https://creativecommons.org/licenses/by-nc-nd/4.0/) 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](https://zerobin.net/?3ea331e3e000fde4#eQ8IrycfZ0wIcmuX4EtgliI3jj8NOeY7GKP0TORwzb4=) ``` 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](https://zerobin.net/?cec09faa14c62d19#Lp1rXhZYJehzXEIGOHICguirb7Zffsxg5aCKxkot2MY=)
314GB!!!!!!!!!!!!!!!!! Damn~
>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