Anime 10bit-High bitrate compression. [My settings and your opinion]

AiDz0r · 27th October 2012, 06:24

Hi all, i'm trying to compress anime videos (length of 25 minutes).

Using RipBot, I've concluded with these settings, I also did a lot pixel checks for almost nearly all settings/presets. So these are my settings for what i use in RipBot, please provide feedback, what you think that would improve the quality if you suggest anything I will try them out straight away and compare them to the current one I'm using and don't forget, this is for anime/cartoon videos. :

Quote:

--profile high10 --level 5.1 --preset veryslow --tune animation --bframes 16 --b-pyramid strict --b-adapt 2 --ref 5 --deblock -3:-3 --aud --nal-hrd vbr --vbv-bufsize 300000 --vbv-maxrate 300000 --trellis 2 --me tesa --subme 10 --weightb --aq-mode 1 --aq-strength 0.86 --analyse all --8x8dct --partitions all --direct auto --threads auto --thread-input --keyint 24 --min-keyint 2

I've also just heard about 10bit recently as well, I'm just curious is it possible to playback/stream videos in 10bit? I know a fact YouTube doesn't because I've tested it, although is it ever possible to playback 10bit video over flashplayer or HTML5 ?

Thanks.

AiDz0r · 27th October 2012, 07:43

2 pass vs CRF?

J_Darnley · 27th October 2012, 11:32

I don't think flash does or will ever support 10-bit but 10-bit through the HTML5 video is very possible if browsers would just use libavcodec. Chrome/chromium does but I think Google provides their own hacked up version in which I wouldn't be surprised to discover that they remove 10-bit support.

2-pass vs crf depends on what you want out of the encoder. If you have some storage medium to fill then use 2-pass. Otherwise crf.

Atak_Snajpera · 27th October 2012, 12:05

Quote:

--keyint 24 --min-keyint 2

why do you need such small GOP for anime?!

Quote:

--deblock -3:-3

weak deblocking for anime ?!

Quote:

--b-pyramid strict

why do you need something required for Blu-Ray?!

I think you should just stick to presets created by developers.

Code:

--profile high10 --preset veryslow --tune animation

cyberbeing · 27th October 2012, 13:49

Quote:

Originally Posted by J_Darnley

I don't think flash does or will ever support 10-bit

Adobe Flash 10.0 through 11.3 supported software decoding (HW acceleration disabled) of 10-bit video. In Flash 10 it was somewhat buggy, with a thin purple bar of padding on the right side of the video. In Flash 11 there was no such anomaly, and it even supported 10bit 4:2:2 decoding. Though for some reason it appears they broke or removed 10bit support in Flash 11.4 & 11.5 beta. Maybe someone should submit a bug report?

jmartinr · 27th October 2012, 17:26

Quote:

Originally Posted by cyberbeing

Though for some reason it appears they broke or removed 10bit support in Flash 11.4 & 11.5 beta. Maybe someone should submit a bug report?

I submitted a bug report [https://bugbase.adobe.com/index.cfm?...bug&id=3324604] some time ago. But they probably won't fix it soon.

smok3 · 27th October 2012, 17:40

Quote:

Originally Posted by jmartinr

I submitted a bug report [https://bugbase.adobe.com/index.cfm?...bug&id=3324604] some time ago. But they probably won't fix it soon.

hmm, interesting ignorance from devs, this could well be one of the things that would prolong the life of flash (as opposed to html5).

Firebird · 27th October 2012, 18:57

Quote:

Originally Posted by smok3

hmm, interesting ignorance from devs, this could well be one of the things that would prolong the life of flash (as opposed to html5).

It's funny that they fixed it in 11.2 and now they're dropping it.

AiDz0r · 28th October 2012, 05:46

Quote:

Originally Posted by Atak_Snajpera

why do you need such small GOP for anime?!

weak deblocking for anime ?!

why do you need something required for Blu-Ray?!

I think you should just stick to presets created by developers.

Code:

--profile high10 --preset veryslow --tune animation

Here is my comparison.
http://thex264.neq3.com/

I've did what you said, instead of using --deblock -3:-3 it's now 3:3. with avisynth filter (line darkener) should be perfectly fine now.

--keyint 240 --min-keyint 24 --b-pyramid normal

Actually realized that the new preset was kind of better than the source.

mirkosp · 28th October 2012, 23:59

Quote:

Originally Posted by Atak_Snajpera

weak deblocking for anime ?!

While I agree with the rest you pointed out, weak deblocking does make sense with anime. It's not unlikely for anime to have a fine textures or heavy noise (be it effect or otherwise), and sharp edges are quite common. I find that even the default deblock settings are sometimes too strong and blurry for the look I like, and while I don't go down to -3:-3, I find -1:-2 to be pretty good generally. Remember, we are talking about japanese animation, not western. The x264 preset was more meant for simpson-like animation, with paint-bucket filling and heavy lineart.

akupenguin · 29th October 2012, 01:39

Quote:

Originally Posted by mirkosp

The x264 preset was more meant for simpson-like animation, with paint-bucket filling and heavy lineart.

No. The x264 developers are anime fans, not western. You can dispute whether we got it right, but that was the goal.

Keiyakusha · 29th October 2012, 11:21

I haven't read the thread I'll just make some comments...

many options in the commandline just useless and can be removed without affecting anything.
--profile high10 --level 5.1 I don't see the reason to use this at all. Even if you want to do 10bit encode this is not what you want to have in commandline
--bframes 16 nothing wrong with that but its too much for me
--deblock -3:-3 not suitable for anime I never go less than -1:-1 myself and higher than 0:0
--aud --nal-hrd vbr --vbv-bufsize 300000 --vbv-maxrate 300000 --b-pyramid strict I don't think you need that. Also I don't do bluray-compatible encoding but these options doesn't look correct to me anyway.
--me tesa really waste of time. even by having unlimited patience, no deadlines or something I wouldn't use that.
Don't touch --keyint options. Default is the way to go, always.
--ref 5 you can use some more. Especially for 720p and below. In fact I think better to use more of these but have bframes less than 16.

Some comment on --tune animation. This is just because akupenguin answered here and directed to those who say tune animation is good/bad, not a direct message to AiDz0r.
It was mentioned probably but in case of 8bit encoding I think it is not suitable for anime most of the time. It performs better in 10bit because 10bit is awesome, but still not perfect. However by saying that we have to set our goals straight. My goals (usually) is to encode anime in a way that I won't be able to (easily) tell the difference even in frame by frame comparison. I don't care about what I will or will not see when I actually watch the show normally. With this goal in mind, the whole default CRF model is not suitable. The problem is that most of the people who do anime encoding have goals very similar to mine, where having lower quality high motion scenes (whatever per-scene or per-macroblock) and other things is not acceptable. If your goal is similar, then --tune animation is not for you, go for custom commandline.
So tune animation mainly blamed not because it is bad by itself, but because among other things it doesn't redefines the crf behavior, mbtree, aq etc in a way that one would expect. But we really can't have one tuning that fits everything, so the only way is not to use tune animation or convince developers that one more animation preset is needed - for making virtually lossless encodes (not sure if I picked right word for that, but not mathematically lossless). Edit: i should note probably, that of course making virtually lossless encode is possible with any tuning, depending on how much bits you're putting in it. The thing is that by using custom commandline/custom tuning you can really bring amount of spent bits down = less final filesize.

benwaggoner · 29th October 2012, 17:44

Quote:

Originally Posted by Firebird

It's funny that they fixed it in 11.2 and now they're dropping it.

Back when I was on Silverlight, we discussed supporting this as well, and decided not to.

Silverlight's rendering mode always wound up in 32-bit RGBA, >8-bit wouldn't have a meaningful quality boost, even if there was content out there we could use. The test cost would have been HUGE relative to the benefits, and test cost was always the primary constraint on new features.

Bear in mind that browser plugins like this live in an extremely high threat security environment. The requirement is that the world's best hacker can't make an app or a bitstream that could lead to any kind of user data or system security compromise.

From a video perspective, that means fuzz testing against libraries of hundreds or thousands of cleverly malformed files to make sure that nothing weird happens. And video happens in very low-level SIMD optimized code that needs to run with really high performance, which makes a lot of the normal pre/post security code analysis more difficult than with "normal" code.

Once GPU acceleration gets into the mix, then you have to rely on the security of the DXVA/QuickTime implementations, which makes things even more complex.

So, every codec mode we simply blocked outright made the test cost much less, since we didn't need to test code paths that never got implemented. For the fuzz testing library, each significant new mode requries hundreds of new files.

Thus interlaced, 10-bit, SVC and other modes of theoretic interest but without clear industry momentum were obvious things to exclude.

I was really startled that Adobe actually shipped interlaced and 10-bit in Flash in the first place. Their decoder didn't have any deinterlacing mechanism, so output of that was always lousy. And they had 10-bit decoding when there was essentially no 10-bit content to test against, let alone rich fuzz testing libraries. This always felt like a security hole in the making.

Last I heard, there were still 0 known cases of any Silverlight web app causing end-user personal data or system compromise. Compared to Flash, I think that's a fine argument for the "only build what you can thoroughly test" development model.

bikar · 5th November 2012, 14:30

nah for me --tune options are bad
for instance I was encoding tonari no totoro and ended up with psy-rd 1.60:0.10 and I was very happy with the result
1:0.25 never worked well for me (for grain ofc)

27th October 2012, 07:43	#2 \| Link
AiDz0r ⃪ ͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤͤ ͤͤ Join Date: Nov 2009 Location: Australia Posts: 54	2 pass vs CRF? __________________ Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

27th October 2012, 11:32	#3 \| Link
J_Darnley Registered User Join Date: May 2006 Posts: 957	I don't think flash does or will ever support 10-bit but 10-bit through the HTML5 video is very possible if browsers would just use libavcodec. Chrome/chromium does but I think Google provides their own hacked up version in which I wouldn't be surprised to discover that they remove 10-bit support. 2-pass vs crf depends on what you want out of the encoder. If you have some storage medium to fill then use 2-pass. Otherwise crf. __________________ x264 log explained \|\| x264 deblocking how-to preset -> tune -> user set options -> fast first pass -> profile -> level Doom10 - Of course it's better, it's one more.

29th October 2012, 11:21	#12 \| Link
Keiyakusha 契約者 Join Date: Jun 2008 Posts: 1,576	I haven't read the thread I'll just make some comments... many options in the commandline just useless and can be removed without affecting anything. --profile high10 --level 5.1 I don't see the reason to use this at all. Even if you want to do 10bit encode this is not what you want to have in commandline --bframes 16 nothing wrong with that but its too much for me --deblock -3:-3 not suitable for anime I never go less than -1:-1 myself and higher than 0:0 --aud --nal-hrd vbr --vbv-bufsize 300000 --vbv-maxrate 300000 --b-pyramid strict I don't think you need that. Also I don't do bluray-compatible encoding but these options doesn't look correct to me anyway. --me tesa really waste of time. even by having unlimited patience, no deadlines or something I wouldn't use that. Don't touch --keyint options. Default is the way to go, always. --ref 5 you can use some more. Especially for 720p and below. In fact I think better to use more of these but have bframes less than 16. Some comment on --tune animation. This is just because akupenguin answered here and directed to those who say tune animation is good/bad, not a direct message to AiDz0r. It was mentioned probably but in case of 8bit encoding I think it is not suitable for anime most of the time. It performs better in 10bit because 10bit is awesome, but still not perfect. However by saying that we have to set our goals straight. My goals (usually) is to encode anime in a way that I won't be able to (easily) tell the difference even in frame by frame comparison. I don't care about what I will or will not see when I actually watch the show normally. With this goal in mind, the whole default CRF model is not suitable. The problem is that most of the people who do anime encoding have goals very similar to mine, where having lower quality high motion scenes (whatever per-scene or per-macroblock) and other things is not acceptable. If your goal is similar, then --tune animation is not for you, go for custom commandline. So tune animation mainly blamed not because it is bad by itself, but because among other things it doesn't redefines the crf behavior, mbtree, aq etc in a way that one would expect. But we really can't have one tuning that fits everything, so the only way is not to use tune animation or convince developers that one more animation preset is needed - for making virtually lossless encodes (not sure if I picked right word for that, but not mathematically lossless). Edit: i should note probably, that of course making virtually lossless encode is possible with any tuning, depending on how much bits you're putting in it. The thing is that by using custom commandline/custom tuning you can really bring amount of spent bits down = less final filesize. Last edited by Keiyakusha; 29th October 2012 at 18:03.

5th November 2012, 14:30	#14 \| Link
bikar Registered User Join Date: May 2012 Posts: 5	nah for me --tune options are bad for instance I was encoding tonari no totoro and ended up with psy-rd 1.60:0.10 and I was very happy with the result 1:0.25 never worked well for me (for grain ofc)