[AV1 Encode Test] Sewayaki Kitsune no Senko-san - 01 [Error in the Matrix].

Category:
Date:
2019-04-16 23:26 UTC
Submitter:
Seeders:
0
Information:
No information.
Leechers:
0
File size:
70.9 MiB
Completed:
58
Info hash:
deaa83d484991269f42469ac57ca2d4234b1e805
This are encodes that I did playing with AV1 for experimentation and was surprised by the result plus I'm going to appreciate any comment one them. Both are full episodes. Video encoded in quality mode with a q of 50. For audio opus at 48kbps for the 480 version and 64 kbps for the 1080p version. Source for both is the 1080p version from HorribleSubs Mediainfo: General : [Encode Test] Sewayaki Kitsune no Senko-san - 01 [Error in the Matrix][AV1 480p 8bits q50][opus 48kbs][78968CFC].mkv Format : Matroska at 150 kb/s Length : 25.5 MiB for 23 min 45 s 30 ms Video #0 : AV1 at 94.0 kb/s Aspect : 852 x 480 (1.778) at 23.976 fps Audio #0 : Opus at 51.6 kb/s Infos : 2 channels, 48.0 kHz Text #0 : ASS Language : en General : [Encode Test] Sewayaki Kitsune no Senko-san - 01 [Error in the Matrix][AV1 1080p 8bits q50][opus 64kbs][E1B53296].mkv Format : Matroska at 267 kb/s Length : 45.4 MiB for 23 min 45 s 30 ms Video #0 : AV1 at 195 kb/s Aspect : 1920 x 1080 (1.778) at 23.976 fps Audio #0 : Opus at 67.7 kb/s Infos : 2 channels, 48.0 kHz Text #0 : ASS Language : en PD. Before any comment please watch them.

File list

>re-encoding lossy audio yikes
1080p was too much for my old xeon e5450. 480p looks much better than expected. What are the encoding hardware specs and how long did it take?
i5-750 2.6 Ghz + GT 1030 can reproduce this encode without effort, nice.
https://slowpics.org/comparison/445a0658-bb51-40af-8eec-6a89b4a0e6dc Looks basically miraculous for how low the bitrate is, but then again so does HEVC at these sort of bitrates.
Update: this encode absolutely wrecks x265 at the same bitrate (preset slow): https://slowpics.org/comparison/96694db0-fa0d-406d-937f-9f3fb76eb0a8
mfw can't play this in firefox without remuxing audio 100 times ![top 3 anime betrayals](https://i.imgur.com/tBrqOLu.jpg)
Interesting, what did you use to encode this (encoder version/app)?

PH13 (uploader)

User
@zsax you have found a strange bug, it lies the iteration between ffmpeg, mkvtoolnix and Firefox... only if the audio as opus file is generated with ffmpeg and muxed in with mkvtoolnix triggers the bug, but it don't happen is the audio is generated as opus in mkv or is done with opunenc. Another thing is that a ffmpeg generated mkv is not playable in Firefox but it plays in Chrome. Also Chrome play the uploads correctly. @oaso try another player one that is based in the decoder "dav1d" as I don't have problem playing the 1080p version in my computer and in my phone only the first 10 second don't play correctly (krin650). The encoder machine i7-7700HQ based laptop and the speed varies between 0.6 fps and 1 fps for the 480p file, for the 1080p it does a between 0.13 fps and 0.2 fps... basically hours or days to encode one episode. The software used was: AOMedia Project AV1 Encoder 1.0.0-1565-g373df0c91 ffmpeg version N-93524-g8161ac2902 I don't going to explain the audio due to the buggy behavior, and this is for video in 1080p (the 480p add scaling and changes arnr-maxframes to 15): ffmpeg -i %1 -pix_fmt yuv420p -strict -1 -f yuv4mpegpipe -sws_dither none -pix_fmt yuv420p -an -sn -dn - | aomenc.exe --threads=8 --good --cpu-used=4 --tile-columns=3 --tile-rows=0 --row-mt=1 --passes=2 --pass=1 --fpf=HD08bit.log --lag-in-frames=24 --kf-max-dist=240 --auto-alt-ref=1 --arnr-maxframes=7 --bit-depth=8 --input-bit-depth=8 --end-usage=q --cq-level=50 -o null.webm - ffmpeg -i %1 -pix_fmt yuv420p -strict -1 -f yuv4mpegpipe -sws_dither none -pix_fmt yuv420p -an -sn -dn - | aomenc.exe --threads=8 --good --cpu-used=4 --tile-columns=3 --tile-rows=0 --row-mt=1 --passes=2 --pass=2 --fpf=HD08bit.log --lag-in-frames=24 --kf-max-dist=240 --auto-alt-ref=1 --arnr-maxframes=7 --bit-depth=8 --input-bit-depth=8 --end-usage=q --cq-level=50 -o "%~dpn1_[AV1_08b-q50].webm" - For episode 2 I'm going to do more test to try to simplify the encoding and prevent the buggy behavior of the audio in the tool-chain.
wait... why are you playing mkv, or any other video files in a browser instead of a video player? Is this some new hip trend that I missed?
Please continue with this. Quite interesting. I hope you let us know your command line for encoding the next ones with the changes as well. Also @zsax: Why? Do you hate media players?
Tested 1080p version - can play it without problems on usual MadVR settings that I watch everything with, no dropped frames. Picture quality - amazing for the bitrate, no noticeable artifacts (exception below), object edges/lines are clear, most people won't be able to tell the difference between this and something with 3-4 or more times the filesize. Exception - fast movement has very noticeable artifacts, can clearly see how the screen is divided into blocks, example: https://i.imgur.com/DGnUuU5.jpg The biggest noticeable difference would probably be audio quality
This doesn't need to be marked red, by the way. Encodes from an untouched source like HS aren't considered "reencodes of an original release."
This honestly made me laugh. Just the fact you got these down to 70mb combined. What a wacky world.
When the black cloud appears at 1:24 the cpu usage peaks to 38% with the 480p, with the 1080 the video freezes for a while. I'm using VLC 3.0.6. I guess Core 2 era hardware is just too old for AV1, or maybe the next version will have a newer dav1d with more optimizations. Edit: I just tried on a Haswell i3, and the 1080p pays flawlessly. Very nice.