2011-04-05, 03:15 | Link #941 |
Giga Drill Breaker
Join Date: Jan 2009
|
Code:
--tune animation Code:
--ref {Double if >1 else 1} and about the giant file sizes now a days its because fansubbers use very quality oriented values for CRF im seeing CRF values of 13-18 as the ranges now for HD resolutions, i think CRF values of 20-23 will be better now a days as ive read somewhere that with higher resolution you could get away with higher CRF values |
2011-04-05, 04:12 | Link #942 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
Re: bigger filesizes, I think the simple explanation is that people got used to better quality. If you look at the 230MB 720p encodes from a few years ago they really don't look all that good and most of them are really fucking oversmoothed as well (since everything was a reencode of a reencode back then). Edit: the group you called out is one of those groups who seem to consist mostly of 14-year-olds. I know maybe 5-6 competent encoders that are still active, the rest are pretty bad. Some of the "pretty bad" ones know how to use an appropriate x264 preset, but many do not.
__________________
|
|
2011-04-05, 04:15 | Link #943 | |||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Quote:
Quote:
Also how do you guys feel about keyint infinite? I had a specific problem a few years back when I was encoding some Street Fighter vids I captured from an emulator. It looked pretty much perfect but partway through the video there was a notable shift in quality, where a new GOP was forced and an I-frame was inserted since keyint XXX was reached. The only way round this was to put in the largest keyint I was allowed. The video was 2 or 3 minutes long and the background stayed mostly the same but it would pan left and right and sometimes up, all of which was easily predicted by x264 and wasn't a large enough change to be considered a scene change and therefore a smart place to insert an I-frame. Quote:
__________________
|
|||
2011-04-05, 07:37 | Link #944 | |
Senior Member
Join Date: Mar 2008
|
Quote:
About the file size issue, I'm no encoder, but I still find a lot of 720p releases to have a relatively acceptable file size. When I see a 400-500 Mb encode it's generally an episode with a lot of motion. |
|
2011-04-05, 16:06 | Link #945 | |
Senior Member
Fansubber
|
Quote:
Re: mbtree, it seems like people disable it to preserve dithering and grain while using low aq-strength and psy settings. I find this kind of dumb, because higher aq and psy have always been much more efficient for that in my experience. |
|
2011-04-07, 00:29 | Link #946 |
Pioneer in Fansub 2.0
Join Date: Aug 2007
|
Back in 2006 basically all encodes were still re-encodes of crappy Share/PD raws and basically all of them look terribad at the 233-250MB size they have. Nowadays with Transport Stream sources people simply expect better.
__________________
|
2011-07-09, 06:06 | Link #951 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
And most sources are 8 bit precision only.
The point is to improve quality and compression by minimizing the quantization error. I still don't get the maths behind it, but apparently it can work wonders on at least some sources. So, 10 bit lets the encoder make a more accurate representation of the source material in less bits.
__________________
|
2011-07-09, 07:23 | Link #952 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
That's why even though the source is only 8 bit, upsampling it to 10 bit and then compression is almost always more efficient theoretically.
__________________
Last edited by Quarkboy; 2011-07-09 at 07:40. |
|
2011-07-09, 07:27 | Link #953 | |
Senior Member
Join Date: May 2006
Location: California
|
I'll re-quote what Dark Shikari said on the matter 8 months ago (emphasis mine).
Quote:
The downside is portability (requires an up-to-date software decoder + currently no hardware decode support) and speed (marginal perf hit from decoding at higher-precision + dither down). Basically this means dropping support for people who depend on hardware set-top boxes, and those who desire the ability to playback HD encodes on underpowered Atom/Via netbooks. Anybody with a modern 2GHz+ dual-core Win/Linux/Mac computer from the past 5 years should see no significant change in terms of content they are capable of playing back, as long as their software is up to date. I'm sure leechers will rage when the initial switch happens, just like the move to from AVI -> MKV and XVID -> H264, but the quality benefit will be worth it in the long run.
__________________
|
|
2011-07-09, 07:37 | Link #954 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
Unless you're getting 10bit HDCAM(-SR) sources from the studios, all you'll be getting is 8bit .ts streams that are banded to heck and back anyway. Perhaps you could add in a dithering/antibanding filter before compression, but all 10bit would do is prevent EXTRA banding artifacts from compression... It doesn't get rid of the ones already there. the rest of DarkShikari's points are all... somewhat obvious from what 10bit precision means. The less obvious effect of actually producing higher quality at smaller file sizes is more opaque (which I addressed above my concept of it). Or in other words, answering the question "why does higher precision decoding/keyframes help compression so much that it offsets the extra two bits everywhere?" is the tricky part.
__________________
|
|
2011-07-09, 08:19 | Link #955 |
Senior Member
Join Date: May 2006
Location: California
|
Correct, encoding with 10-bit x264 means you won't produce extra banding beyond what was already in the source, and opens the door to dithering pre-processing actually being retained in the encode without an insane bitrate. I wasn't replying to you directly, just the thread in general with something I had posted in the playback fourm. Below were the preliminary results Dark Shikari posted, at which point 10-bit x264 was still being decoded to 8-bit without dithering. Things have likely improved with all the 10-bit related commits since then.
Source Denoise/Deband -> 8-bit x264 Denoise/Deband -> 10-bit x264 The technicalities of why this all works goes over my head, but the basic idea was moving from 8-bit -> 10-bit eliminates Edit: Why does 10-bit save bandwidth (even when content is 8-bit)? [pdf link] Edit2: http://screenshotcomparison.com/comparison/65953 (Steins;Gate Blu-ray NCED 01:30 | 23.5MB 10-bit x264 CRF=15.0 vs. 38.9MB 8-bit x264 CRF=15.0)
__________________
Last edited by cyberbeing; 2011-07-13 at 03:35. Reason: see below + added addtional 8-bit vs 10-bit comparison |
2011-07-09, 13:56 | Link #956 | |
Junior Member
Join Date: Apr 2011
|
Quote:
I know TheFluff also blogged about the dos and don'ts of fansubbing and probably the most important was, don't do it if you aren't having fun. |
|
2011-07-11, 12:35 | Link #957 | |
x264 Developer
Join Date: Feb 2008
|
Quote:
So 10-bit removes 75% of the loss from intermediate rounding (vs 8-bit). Higher bit depth would be better, of course, but higher than 10 means that it's no longer possible to use 16-bit intermediates in the motion compensation filter. Since 30-40%+ of decoding time is spent there, halving the speed of motion compensation would massively impact decoding CPU time, and since we've already eliminated 75% of the loss, it's just not worth it. Last edited by Dark Shikari; 2011-07-11 at 12:49. |
|
2011-08-20, 07:48 | Link #960 |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
I think it should be obvious to anyone that there will never be hardware devices that play 10bit h264 with the exceptions of essentially HTPCs that are really running ffdshow.
I.e. no one is going to produce a chip that decodes 10bit. There's zero market for it. I suppose it's possible that the PS3/Xbox could play them, since they use software decoding, but I wouldn't hold your breath. The only reason h.264 decoding is so ubiquitous is because of the blu-ray and i-products standards, and non of those play or are compatible with 10bit.
__________________
|
|
|