Posted under Site Bug Reports & Feature Requests
Requested feature overview description.
AV1 is a royalty free video codec that compresses 30% more than VP9 at the same quality.
Why would it be useful?
The codec would reduce video file sizes compared to VP9, wich is good for users with slow connections or data caps. It will also allow to upload longer videos within the size limit at a reasonable quality.
What part(s) of the site page(s) are affected?
Server side scripts (i guess).
Updated by Versperus
Bump.
It's more common than it was 2 years ago. Now you can get hardware decode support cheaply with Amazon Fire TV Stick 4K Max, Tiger Lake laptops, etc.
Looks like 75% of the market has support to it. And apple still pretends it doesn't exist.
omegaumbra said:
Useful website thingyLooks like 75% of the market has support to it. And apple still pretends it doesn't exist.
That is by browser support, not the presence of hardware decode support.
Although if the computer is fast and the video isn't 4K or something, it might be fine.
lance_armstrong said:
That is by browser support, not the presence of hardware decode support.Although if the computer is fast and the video isn't 4K or something, it might be fine.
Oh yeah, you are right.
By the way, a possible AV1 support would also mean AVIF support?
omegaumbra said:
Oh yeah, you are right.
By the way, a possible AV1 support would also mean AVIF support?
It has been discussed.
I think the real problem is that artists don't use it and have no reason to. Why add support for something on e621 when the sites where most of the artists are don't support it. They should probably be saving all of their work as lossless PNGs anyway. A typical hard drive could fit 1 million or more such images.
AVIF does have a lossless option, but I see some debate about how it works: https://github.com/AOMediaCodec/av1-avif/issues/111
Updated
omegaumbra said:
Oh yeah, you are right.
By the way, a possible AV1 support would also mean AVIF support?
JPEG XL is faster and has more features. Very few people have taken AVIF seriously.
Will it be implemented?
electricitywolf said:
JPEG XL is faster and has more features. Very few people have taken AVIF seriously.
Name 5 artists using JPEG XL. Same problem as AVIF.
electricitywolf said:
Will it be implemented?
I think AV1 will be supported eventually, since YouTube rips could be AV1 and more videos could be squeezed under the 100 MB limit.
Most video decoding hardware now support AV1 including decoders from Intel, AMD, Nvidia, and various mobile SoCs. Supporting it on E6 would allow higher quality Youtube rips to be uploaded.
giuth43284o said:
Most video decoding hardware now support AV1 including decoders from Intel, AMD, Nvidia, and various mobile SoCs. Supporting it on E6 would allow higher quality Youtube rips to be uploaded.
YT rips suffer from the same problem as Twitter, Tumblr, and so on - they are recompressed very aggressively. Irony: Artists uploading here have to reduce quality to get it within 100MB limit. Some will post a normal resolution here, and then have offsite link to Mega.NZ or the like for a 450MB monster.
AV1 is apparently already supported and that line of code has been there for a year already, interestingly it seems to originate from a commit 5 years ago (obviously that's way older than this thread) so it really leaves me to wonder whether this is actually working or not.
Has anybody posting here actually attempted to upload an AV1 file?
faucet said:
AV1 is apparently already supported and that line of code has been there for a year already, interestingly it seems to originate from a commit 5 years ago (obviously that's way older than this thread) so it really leaves me to wonder whether this is actually working or not.Has anybody posting here actually attempted to upload an AV1 file?
I'll try it in a bit, if I can find one.
OK, it's still filtered by extension.
Source: https://github.com/SPBTV/video_av1_samples?tab=readme-ov-file
Rating: Safe
Tags: not_furry github animated test_pattern
Description: Testing AV1 functionality using test files from Github - for Faucet. topic #31467
error: ActiveRecord::RecordInvalid - Validation failed: File ext video/mp4 is invalid (only jpg, gif, png, and webm files are allowed)
Updated
alphamule said:
OK, it's still filtered by extension.
It needs to be remuxed into a webm container, and the audio converted.
ffmpeg -i spbtv_sample_bipbop_av1_960x540_25fps.mp4 -c:v copy -c:a libopus spbtv_sample_bipbop_av1_960x540_25fps.webm
(FWIW, the video doesn't play in my browser, Pale Moon v33.1)
faucet said:
Has anybody posting here actually attempted to upload an AV1 file?
I think Mairo might've, but it also could've been a joke
Updated
I thought I'd add some input. I'm on an 8 year old computer with a Ryzen 1700. I don't have HW accelerated decoding on my GPU, and as a result of Discord allowing AV1 streaming, if a friend choses 1440p, I lose 25% of my CPU. If they stream in 4K, my CPU reaches 50% and my desktop becomes stutter. Until faster decoders are made, resolution limits are in place, or HW decoding is massively widespread, allowing them on E6 could cripple older devices or outright crash older phones.
jonnyawsom3 said:
I thought I'd add some input. I'm on an 8 year old computer with a Ryzen 1700. I don't have HW accelerated decoding on my GPU, and as a result of Discord allowing AV1 streaming, if a friend choses 1440p, I lose 25% of my CPU. If they stream in 4K, my CPU reaches 50% and my desktop becomes stutter. Until faster decoders are made, resolution limits are in place, or HW decoding is massively widespread, allowing them on E6 could cripple older devices or outright crash older phones.
Yeah, this is why a lot of places have downsampled versions.
Bumping this, the extra compression at the same quality would allow fitting higher quality posts into the 100MB limit, which is getting more and more limiting as expectations for quality increase.
It is technically already supported according to e621ng, but the files are not accepted on upload due to a bug that is currently being investigated.
If and when this is fixed, what are the rules going to be when it comes to upload guidelines? Obviously if the source is AV1, that should always be used, but what if it came from a site like YouTube that lossily transcodes everything in the first place and AV1 is just one of the codecs offered?
errorist said:
If and when this is fixed, what are the rules going to be when it comes to upload guidelines? Obviously if the source is AV1, that should always be used, but what if it came from a site like YouTube that lossily transcodes everything in the first place and AV1 is just one of the codecs offered?
I'd assume no difference. Whichever is the best quality, the actual format doesn't matter (some formats may generally lend itself to better quality, but it ultimately depends on the quality of the result and not the format, any format can be made to look worse than another).
Well, that's the thing, it's going to be subjective. If YouTube (or whatever) is doing its job properly, both versions will be too close in quality to make the call. And the objectively best version will be the one still sitting on the creator's hard drive, inaccessible to anyone else unless they decide to sign up here and post it themselves.
Hoping the av1 bug is fixed soonish. Especially since Handbrake allows hardware accelerated av1 encoding but not for vp9, so it takes over 10x longer to encode to a worse format...
Until then, for people who are familiar with ffmpeg, here's some base code to modify that converts to vp9 with hardware acceleration:
ffmpeg -i "input.mp4" -vf scale=1920:1080 -c:v vp9_qsv -b:v 3000k -c:a libopus -b:a 128k -preset veryslow "output.webm"
("vp9_qsv" is for supported Intel CPUs/GPUs, change that to whatever your hardware uses)
Edit: Apparently Intel is the only manufacturer with hardware support for vp9 encoding? Looks like my B580 came in clutch, also works on their cpus from 7th gen and up, sorry to everyone else
Updated
This is a bug in underlying technology called marcel: https://github.com/rails/marcel/issues/80
This issue has been open for going on 3 years.
tarrgon said:
This is a bug in underlying technology called marcel: https://github.com/rails/marcel/issues/80This issue has been open for going on 3 years.
Jeez, that's a long time not to fix that bug.
I hope it gets through, AV1 really is magic as far as video codecs go, and hardware acceleration is dramatically more widespread now
Seems that AV1 support has been finally implemented, but only with the MP4 container it seems?
The supported filetypes wiki doesn't mention anything regarding AV1 for the WEBM container, just for MP4.
Honestly, I didn't even know the MP4 container supported AV1. I thought it was limited to WEBM. (And MKV too, but that container supports basically everything.)
(I mean yeah, technically you could also put VP9 + OPUS into an MP4 file, but at this point you're better off with WEBM.)
While it's nice to see MP4 finally supported for upload, I fear this will lead to a lot of confused users complaining (and not reading the wiki) that they can't upload their H.264/H.265 encoded videos.
If AV1 has the chance to be supported, why WebP doesn't?
This format has been supported by many devices and browsers and also has better compression ratio compared to PNG (lossless) and JPEG (lossy)
snedmano said:
Seems that AV1 support has been finally implemented, but only with the MP4 container it seems?
The supported filetypes wiki doesn't mention anything regarding AV1 for the WEBM container, just for MP4.
Honestly, I didn't even know the MP4 container supported AV1. I thought it was limited to WEBM. (And MKV too, but that container supports basically everything.)
(I mean yeah, technically you could also put VP9 + OPUS into an MP4 file, but at this point you're better off with WEBM.)While it's nice to see MP4 finally supported for upload, I fear this will lead to a lot of confused users complaining (and not reading the wiki) that they can't upload their H.264/H.265 encoded videos.
I think this is because AV1-capable software and hardware usually supports AV1 stream contained MP4. And MP4 are also supports AAC & MP3 so it would be more flexible
And also possibly, to avoid confusion/differentiating between VP9 and AV1
gerontophilia said:
I think this is because AV1-capable software and hardware usually supports AV1 stream contained MP4. And MP4 are also supports AAC & MP3 so it would be more flexible
I guess that makes sense, yeah.
I've checked recent videos from YouTube with yt-dlp and they do seem to use AV1 with MP4 as well, rather than WEBM.
Though, I'm not sure if this is just yt-dlp gaslighting me, since YouTube does keep audio and video separate.
gerontophilia said:
And also possibly, to avoid confusion/differentiating between VP9 and AV1
I'm not sure about that.
Actually, in this very thread it was discussed a while ago that AV1 was already technically supported with WEBM, but couldn't be uploaded due to a bug.
Now AV1 is supported for MP4, but seemingly still not for WEBM, as the bug doesn't seem to have been fixed.
The bug seems to be it not detecting the AV1 data in a WEBM file as video data, resulting in it thinking it's a WEBM file with just audio.
snedmano said:
Now AV1 is supported for MP4, but seemingly still not for WEBM, as the bug doesn't seem to have been fixed.
It was closed in favour of MP4: https://github.com/e621ng/e621ng/pull/830#issuecomment-2824378831
The bug is fixed but not merged: https://github.com/rails/marcel/pull/104
Now that MP4 files can be used upload videos, my questions now are:
When is a MP4 higher quality then a WEBM file? or the other way around? does file size matter in that regard?
What websites with mp4 support have native AV1 streams?
joshbilzerian said:
When is a MP4 higher quality then a WEBM file? or the other way around?
When it has less visible artifacting. Generally it'll be whichever file had the fewest conversions done to it, but the encoding quality can also factor into it. If there are separate vp9 and av1 encoded files, and neither are the original created/released by the creator (where one would necessarily be created from the other), you'll need to compare them for the severity of compression artifacts. If the creator uploaded a vp9 video that you can download directly, an av1 conversion of that download will never be the higher quality version. In contrast, if a site always recompresses uploads to vp9 and av1, and you're given a choice of which to download, neither are the original and would need to be compared.
Updated
whatamiherefor said:
It was closed in favour of MP4: https://github.com/e621ng/e621ng/pull/830#issuecomment-2824378831
I still think it's a good idea to allow AV1 for WEBM as well. There would be no downside to allowing it for both.
Currently, it's not possible to upload a file with AV1 video and Opus audio without having to convert one of the two streams.
In fact, this site does automatically create AV1 and Opus WEBM versions of uploaded MP4 files, similar to the MP4 versions created of uploaded WEBM files.
Example post #5546519
Download of uploaded version: https://static1.e621.net/data/e4/47/e447365544e57845d1b3bfe4f6b52e1c.mp4
WEBM version created by site: https://static1.e621.net/data/e4/47/e447365544e57845d1b3bfe4f6b52e1c.webm
whatamiherefor said:
The bug is fixed but not merged: https://github.com/rails/marcel/pull/104
Well, If the fix hasn't been merged yet, I'd argue the bug hasn't been fixed. (But that’s just arguing over semantics here.)
It's a shame though, since the fix is seemingly just two tiny mapping changes. And that pull request is almost a year old...
Actually, the last change to this repository was exactly one year ago (to the day) and it looks to me like it has been completely abandoned.
gerontophilia said:
I think this is because AV1-capable software and hardware usually supports AV1 stream contained MP4. And MP4 are also supports AAC & MP3 so it would be more flexible
And also possibly, to avoid confusion/differentiating between VP9 and AV1
post #3813645
With artists I have talked with, all of their software have AV1 under MP4 and basically nothing even supports input as WebM, so this is one primary reason why this format support is huge deal.
watsit said:
When it has less visible artifacting. Generally it'll be whichever file had the fewest conversions done to it, but the encoding quality can also factor into it. If there are separate vp9 and av1 encoded files, and neither are the original created/released by the creator (where one would necessarily be created from the other), you'll need to compare them for the severity of compression artifacts. If the creator uploaded a vp9 video that you can download directly, an av1 conversion of that download will never be the higher quality version. In contrast, if a site always recompresses uploads to vp9 and av1, and you're given a choice of which to download, neither are the original and would need to be compared.
post #3813645
I basically handle them all the same, video is video.
Previously problem was VP8 or VP9, but VP8 is essentially obsolete but in terms of quality, slightly higher bitrate looks identical to VP9 regardless. (Just please stop using VP8 already though)
snedmano said:
I still think it's a good idea to allow AV1 for WEBM as well. There would be no downside to allowing it for both.
Currently, it's not possible to upload a file with AV1 video and Opus audio without having to convert one of the two streams.
In fact, this site does automatically create AV1 and Opus WEBM versions of uploaded MP4 files, similar to the MP4 versions created of uploaded WEBM files.Example post #5546519
Download of uploaded version: https://static1.e621.net/data/e4/47/e447365544e57845d1b3bfe4f6b52e1c.mp4
WEBM version created by site: https://static1.e621.net/data/e4/47/e447365544e57845d1b3bfe4f6b52e1c.webm
Fake news as they say.
Downside is that software which has implemented support for these formats as per standards, would not be able to play AV1 in WebM file, which would cause issues which take time and effort to troubleshoot. Software that support AV1 as input e.g. editing software, always accepts MP4, not necessarily WebM.
MP4 container supports Opus audio in it, it's supposted in ISOBMFF, aka MP4, https://en.wikipedia.org/wiki/Opus_(audio_format)#Containers
Also site does currently create VP9/Opus WebM sample of AV1 uploads, but currently it's just a quick patch as previously the site would generate MP4 sample, which would overwrite the MP4 upload, nuking it from the server. That's why first upload post #5530056 is deleted, as it no longer exsists.
It's also funny you link to a post that literally has AV1 with Opus audio as it's literally just youtubes tracks 400 and 251:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '.\e447365544e57845d1b3bfe4f6b52e1c.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomav01iso2mp41
encoder : Lavf61.7.100
Duration: 00:00:31.86, start: 0.000000, bitrate: 996 kb/s
Stream #0:0[0x1](und): Video: av1 (libdav1d) (Main) (av01 / 0x31307661), yuv420p(tv, bt709), 1920x1440, 879 kb/s, 12 fps, 12 tbr, 12288 tbn (default)
Metadata:
handler_name : ISO Media file produced by Google Inc.
vendor_id : [0][0][0][0]
Stream #0:1[0x2](eng): Audio: opus (Opus / 0x7375704F), 48000 Hz, stereo, fltp, 114 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]mairo said:
Downside is that software which has implemented support for these formats as per standards, would not be able to play AV1 in WebM file, which would cause issues which take time and effort to troubleshoot. Software that support AV1 as input e.g. editing software, always accepts MP4, not necessarily WebM.
Interesting, I always thought AV1 was made primarily with WEBM in mind.
The sample videos I found always used WEBM as the container.
mairo said:
Downside is that software which has implemented support for these formats as per standards, would not be able to play AV1 in WebM file, which would cause issues which take time and effort to troubleshoot. Software that support AV1 as input e.g. editing software, always accepts MP4, not necessarily WebM.
MP4 container supports Opus audio in it, it's supposted in ISOBMFF, aka MP4, https://en.wikipedia.org/wiki/Opus_(audio_format)#Containers
Also site does currently create VP9/Opus WebM sample of AV1 uploads, but currently it's just a quick patch as previously the site would generate MP4 sample, which would overwrite the MP4 upload, nuking it from the server. That's why first upload post #5530056 is deleted, as it no longer exsists.It's also funny you link to a post that literally has AV1 with Opus audio as it's literally just youtubes tracks 400 and 251:
Aw shucks you're totally right. Guess I saw OPUS as the audio stream and assumed I was looking at the WEBM sample and not the MP4 version.
I was sure the supported filetypes wiki didn't mention OPUS as an allowed audio stream for MP4 uploads, checked it again and sure enough, that's exactly what it says in black and white (or in this case, white on blue).
So I was blabbering about a non-issue after all. Sorry about that.
On a related note, do you know of a somewhat faster method to convert videos using FFMPEG to AV1 with 2-pass encoding?
For example this is the command I used for the post replacement for post #4418898:
ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 9M -g 48 -pass 1 -an -f null NUL ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 9M -g 48 -pass 2 -c:a copy output_AV1_libaom-av1_2Pass_9M.mp4
The resulting video was great. I've exported the frames of both the input and the output video to individual PNG files and compared some frames. I could detect barely any quality difference.
The only issue being that the conversion is extremely slow.
For 10 seconds of video the conversion takes about 1 hour.
I've checked out Handbrake and did the same thing there.
The whole conversion (50 seconds of video) was finished in about 20 minutes.
But I'm not sure I can trust the output of Handbrake.
snedmano said:
Interesting, I always thought AV1 was made primarily with WEBM in mind.
The sample videos I found always used WEBM as the container.
At least it's possible to remux the file from mp4 to webm without having to reencode the video (or audio if it's Opus; unfortunately AAC or MP3 will need to be reencoded to Opus to put it into webm).
snedmano said:
On a related note, do you know of a somewhat faster method to convert videos using FFMPEG to AV1 with 2-pass encoding?
For example this is the command I used for the post replacement for post #4418898:ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 9M -g 48 -pass 1 -an -f null NUL ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 9M -g 48 -pass 2 -c:a copy output_AV1_libaom-av1_2Pass_9M.mp4
Adding -row-mt 1 to both commands can help, assuming a multi-core and/or hyperthreading CPU.
https://trac.ffmpeg.org/wiki/Encode/AV1
snedmano said:
Interesting, I always thought AV1 was made primarily with WEBM in mind.
The sample videos I found always used WEBM as the container.Aw shucks you're totally right. Guess I saw OPUS as the audio stream and assumed I was looking at the WEBM sample and not the MP4 version.
I was sure the supported filetypes wiki didn't mention OPUS as an allowed audio stream for MP4 uploads, checked it again and sure enough, that's exactly what it says in black and white (or in this case, white on blue).
So I was blabbering about a non-issue after all. Sorry about that.On a related note, do you know of a somewhat faster method to convert videos using FFMPEG to AV1 with 2-pass encoding?
For example this is the command I used for the post replacement for post #4418898:ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 9M -g 48 -pass 1 -an -f null NUL ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 9M -g 48 -pass 2 -c:a copy output_AV1_libaom-av1_2Pass_9M.mp4The resulting video was great. I've exported the frames of both the input and the output video to individual PNG files and compared some frames. I could detect barely any quality difference.
The only issue being that the conversion is extremely slow.
For 10 seconds of video the conversion takes about 1 hour.I've checked out Handbrake and did the same thing there.
The whole conversion (50 seconds of video) was finished in about 20 minutes.
But I'm not sure I can trust the output of Handbrake.
It started as WebM because it is successor to VP9 which is WebM primarily, but then the whole industry saw how ridiculous licensing for h265/HEVC and got on board for AV1 - even goddamn Apple.
There's a reason why everything even now is h264/AVC instead of h265/HEVC after a decade (except anime scene, anime scene loves their waifus with no compression and lowest filesizes), even though h265/HEVC is soooo much better. Luckily AV1 does seem even better.
Technically speaking, you can have VP9 also on MP4 container, just that similar to AV1 in WebM container, depending on software that the file is used with, can cause issues as many do not list that as supported even though on paper it is.
So I would keep VP9 as WebM and AV1 as MP4, just to keep things as standartized as possible.
The e621 wiki page is manually written by staff, so it's not to be taken as technical documentation, but rather what we have encountered and tested and try to keep things working here specifically.
Also because AV1 is now free industry standard, there are multiple encoders for it (unlike VP8 and VP9 where you basically have to use libvpx).
https://trac.ffmpeg.org/wiki/Encode/AV1
Again, this is only what I have personally researched so far and majority are this encoding guide, but libaom is like the initial successor to libvpx so the commands and useage are basically the same, but encoding times are basically insane and unuseable. I would not use this encoder.
What I would personally recommend is libsvtav1, encoder by Intel and Netflix which is much faster and produces pretty great files, this is also the default software encoder in HandBrake, just keep in mind that commands are completely differend, default keyframe positioning is extremely small and it cannot do two pass.
Then there's also rav1e which I haven't tested yet and if you have newer machine, you should have some level of hardware encoder available e.g. QuickSync or NVENC, however quality per bitrate does get lower with these, but artists and animators who natively export from their editing software already use hardware acceleration with h264/AVC as well, as long as the bitrate is high enough this is not an issue.
(Also the fact that artists and animators have option they can export to directly in their software is already huge benefit, where I don't recall any major video editing software adding WebM formats even now sadly)
When doing software transcoding, I would highly avoid using constant/constrained bitrate mode (e.g. -b:v 10M) and use quality mode instead (e.g. -crf 16) unless needing to target specific filesize.
Reason is that many content here is short form, at which point quality modes adjust bitrate according to content and the files aren't visually compressed or bloated as result. Also all modern formats basically plead in documentations and examples to use CRF and not bitrate unless using hardware encoding.
I would also advice againts replacing old WebM transcodes with MP4 transcodes on e621, unless the source was AV1 to begin with (e.g. Bilibili). Even if you can copy audio tracks now, just to avoid flood of posts being in replacements for really small if no benefits and audio is still technically outside the scope of the website.
There's still stuff like talks about samples being reworked, so replacements like this currently would just increase the workload.
Just wanted to say I'm excited to see this change!
I'm considering revisiting this old post, seeing if I can make it better with AV1 encoding. The limiting factor here was the filesize - VP9 could only make this clip so large (resolution-wise) before the end result exceeded 100MB, unless I nerfed the CRF to the point where the video started looking awful. I should be able to make that clip in higher resolution using AV1.
Updated
mairo said:
It started as WebM because it is successor to VP9 which is WebM primarily, but then the whole industry saw how ridiculous licensing for h265/HEVC and got on board for AV1 - even goddamn Apple.
There's a reason why everything even now is h264/AVC instead of h265/HEVC after a decade (except anime scene, anime scene loves their waifus with no compression and lowest filesizes), even though h265/HEVC is soooo much better. Luckily AV1 does seem even better.
One thing I liked about H.265 over VP9 was the ability to do the encoding on the GPU (Nvidia NVENC), which made the encoding process much faster.
But yeah, I haven't encountered a single site that actively used H.265. Most likely due to these licensing fees you mentioned.
I don't get what’s the point of charging so much for your product, that no one really ends up using it. They'll only shoot themselves in the foot with that.
Not even YouTube implemented that. Though they do support it for Upload. But that doesn't mean much.
I experimented with all sorts of codecs for YouTube and they accepted almost all of them, though they re-encode these to their own codecs anyways.
mairo said:
Technically speaking, you can have VP9 also on MP4 container, just that similar to AV1 in WebM container, depending on software that the file is used with, can cause issues as many do not list that as supported even though on paper it is.
So I would keep VP9 as WebM and AV1 as MP4, just to keep things as standartized as possible.
The e621 wiki page is manually written by staff, so it's not to be taken as technical documentation, but rather what we have encountered and tested and try to keep things working here specifically.
Technically I could also upload an MP4 file with FLAC as the audio stream, since the container does support it. (At least FFMPEG lets me use it)
However, I'm pretty sure this wouldn't stay up for long, since the supported filetypes does say that Files other than this are subject for deletion as broken/corrupted.
And that’s completely fine, since limiting the allowed codecs to what’s necessary minimizes possible compatibility issues.
mairo said:
Technically speaking, you can have VP9 also on MP4 container, just that similar to AV1 in WebM container, depending on software that the file is used with, can cause issues as many do not list that as supported even though on paper it is.
So I would keep VP9 as WebM and AV1 as MP4, just to keep things as standartized as possible.
The e621 wiki page is manually written by staff, so it's not to be taken as technical documentation, but rather what we have encountered and tested and try to keep things working here specifically.Also because AV1 is now free industry standard, there are multiple encoders for it (unlike VP8 and VP9 where you basically have to use libvpx).
https://trac.ffmpeg.org/wiki/Encode/AV1
Again, this is only what I have personally researched so far and majority are this encoding guide, but libaom is like the initial successor to libvpx so the commands and useage are basically the same, but encoding times are basically insane and unuseable. I would not use this encoder.
What I would personally recommend is libsvtav1, encoder by Intel and Netflix which is much faster and produces pretty great files, this is also the default software encoder in HandBrake, just keep in mind that commands are completely differend, default keyframe positioning is extremely small and it cannot do two pass.
Then there's also rav1e which I haven't tested yet and if you have newer machine, you should have some level of hardware encoder available e.g. QuickSync or NVENC, however quality per bitrate does get lower with these, but artists and animators who natively export from their editing software already use hardware acceleration with h264/AVC as well, as long as the bitrate is high enough this is not an issue.
(Also the fact that artists and animators have option they can export to directly in their software is already huge benefit, where I don't recall any major video editing software adding WebM formats even now sadly)When doing software transcoding, I would highly avoid using constant/constrained bitrate mode (e.g. -b:v 10M) and use quality mode instead (e.g. -crf 16) unless needing to target specific filesize.
Reason is that many content here is short form, at which point quality modes adjust bitrate according to content and the files aren't visually compressed or bloated as result. Also all modern formats basically plead in documentations and examples to use CRF and not bitrate unless using hardware encoding.
Interestingly I did try to use -crf 10 as the setting, but got a worse result than with -b:v 9M, so thats why I ended up using that one.
Maybe If I used a lower number (Though I think -crf 10 is already fairly high quality) or a different encoder entirely I would have gotten a better result.
Thank you for the advice and taking your time to help me out with this stuff!
mairo said:
I would also advice againts replacing old WebM transcodes with MP4 transcodes on e621, unless the source was AV1 to begin with (e.g. Bilibili). Even if you can copy audio tracks now, just to avoid flood of posts being in replacements for really small if no benefits and audio is still technically outside the scope of the website.
There's still stuff like talks about samples being reworked, so replacements like this currently would just increase the workload.
I was already planning to do a higher quality VP9 replacement for that post since I've added the BVAS tag, but never got around to it until now.
The post used the version from YouTube, which had significantly lower bitrate than the version the artist has uploaded on MEGA.
This means this replacement did significantly increase the video quality, regardless of whether the conversion was to VP9 or AV1. Keeping the original AAC stream was just an added bonus.
I wouldn't do any replacements with AV1 conversions unless they noticeably improve video quality to that post.
snedmano said:
On a related note, do you know of a somewhat faster method to convert videos using FFMPEG to AV1 with 2-pass encoding?
....
The only issue being that the conversion is extremely slow.
For 10 seconds of video the conversion takes about 1 hour.
libaom-av1 doesn't appear to auto-tile the output, unlike vp9 - try something like the following:
This will still be *very* slow, but should be faster. For a faster, but considerably less efficient output, bump cpu-used to 4.
Updated
tredfg543 said:
libaom-av1 doesn't appear to auto-tile the output, unlike vp9 - try something like the following:
- ffmpeg -i input.mkv -an -c:v libaom-av1 -crf 24 -cpu-used 2 -tiles 4x3 -row-mt 1 -pass 1 -f null NUL
- ffmpeg -i input.mkv -c:a libopus -b:a 96k -c:v libaom-av1 -crf 24 -cpu-used 2 -tiles 4x3 -row-mt 1 -pass 2 output.mp4
This will still be *very* slow, but should be faster. For a faster, but considerably less efficient output, bump cpu-used to 4.
I've tried that out with the same 50 second video and it finished transcoding in about 25 minutes.
Not exactly blazing fast either, but worlds away from the speed of the command I used.
It's about the same speed it previously took to transcode to VP9 for me, so I can definitely work with that.
(Though, I also need to try out the encoders recommended by Mairo for comparison.)
I'm not exactly sure what tiling does, but from the name I assume it splits each frame into a bunch of different chunks which are encoded individually?
snedmano said:
I'm not exactly sure what tiling does, but from the name I assume it splits each frame into a bunch of different chunks which are encoded individually?
That's my understanding. It benefits both encoders and decoders [because multiple threads can be used], but does slightly compromise compression efficiency, because motion from one tile to another tile cannot be encoded as such - it "runs off the border" of one tile and into another tile as new pixels.
tredfg543 said:
That's my understanding. It benefits both encoders and decoders [because multiple threads can be used], but does slightly compromise compression efficiency, because motion from one tile to another tile cannot be encoded as such - it "runs off the border" of one tile and into another tile as new pixels.
Interesting, I guess that's why heavily compressed videos often has this blocky/tiled look to it.
snedmano said:
Interesting, I guess that's why heavily compressed videos often has this blocky/tiled look to it.
Nah, that's just blocking from bitrate starvation.
Now, if you can make out a rectangular *pattern* to the blocking, maybe in video that's been extremely bitrate starved, maybe you'd be onto something.
The tiles 4x3 referenced here for example, divides the video into a total of 12 tiles, four across by three down.
tredfg543 said:
The tiles 4x3 referenced here for example, divides the video into a total of 12 tiles, four across by three down.
Ah, that's what it does.
I thought that meant each tile would be 4x3 pixels large. But now that I think of it, that would have been a bit excessive.
tredfg543 said:
Nah, that's just blocking from bitrate starvation.
post #3813645
Altough I have to say that with post #5547679, bitrate is getting so low that even VP9 is showing blocky artifacts in blurry scenes and fade in/out, but AV1 just kinda, pushes through it.