HEVC

>>60414000
If you can run it smoothly then there's no reason not to convert your library - it should shrink your library quite a bit

File: 1491114087606.jpg (98KB, 640x934px) Image search: [Google]

98KB, 640x934px

>>60414000
Professional encoder here

No, it still is a meme. As of the version 2.3, there still isn't a native Film tuning and the default one delivers worse quality comparetively to x264 at profile 5.0+ and slower settings.

I've been making extensive texts every 2~3 versions.

I only recommend HEVC for flat digital animation (anime) and low grain with custom tune settings (default ones are shit) and very slow preset at CRF 17 or lower. Anything higher quality (CRF 16 or higher) x264 is still better.

>>60414123
>suggesting a lossy to lossy encoding
Don't be a retard, you will only make your videos look worse.

Though I did try encoding some low compleixty encode oversized porns I donwloaded some time ago and was disapointed with the results. As much as lossy to lossy transcode is undesirable, x265 just smooths away too much detail for significant (30%+) size savings.

Not a "professional" encoder, but I do experiment with it every year or so. So far, it yields much larger files than x264 at the same bitrate. Eh.

>>60414926
>So far, it yields much larger files than x264 at the same bitrate
>same bitrate
>much larger files

You should "professionally" kill yourself

>>60414784
dat oil painting effect tho

File: Alliance_For_Open_Media_AOMedia.png (84KB, 664x333px) Image search: [Google]

84KB, 664x333px

>>60414000
Good night, MPEG. You had a good run. We'll take it from here.

>>60414000
Its what i try to download all my anumu and TV shows in.

I stick to low-ish bitrate 720p(22 min TV shows are maybe 120megs each) or 480p(22 min TV shows are maybe 80megs each).

>>60414784
If it's good for anime, then that's all it needs.

>>60414926
You are retarded. It compresses files better while keeping the same quality as x264.

>>60414926
>It yields much larger files than x264 at the same bitrate.
>Not a "professional"

ya don't say

>>60414000
I have used it a few times, it's good but it still uses way too much CPU in most computers

File: 4 HEVC CUSTOM FILM TUNNING 0.1fps crf22 4700kbps 1080p.mkv_snapshot_04.47_[2017.05.15_21.51.07].png (3MB, 1920x800px) Image search: [Google]

3MB, 1920x800px

>>60415001
Yes, is a problem, but with custom tuning, you can get some decent results.

At around 5000kbps for a 2.40 aspect ratio, mildly action 35mm hollywood flick, with default settings it is inferior than x264 even at very low speeds. However, after tuning it, it actually slightly surpass x264.

Though 5000kbps is not good enough for grain and detail retention at 1080p, I never go bellow 8000~10000kbps myself. At 8000kbps, no matter how much I tried tweak x265, I couldn't get it to look better than x264 with 5.1 profile and Film tune at very slow. Neverming x265 actually is 3 times slower.

Pic related. one of the test encodes at crf22. Smudged as fuck.

Here are the film tune settings I recommend for modern 35mm holywood films:

avs4x265.exe -o output.x265 --crf 18 --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 4 --subme 5 --merange 44 --b-intra --no-amp --ref 6 --weightb --keyint 120 --min-keyint 1 --bframes 6 --aq-mode 1 --aq-strength 1.2 --rd 5 --psy-rd 1.2 --psy-rdoq 5.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 100 --max-merge 4 --qcomp 0.6 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --ipratio 1.3 --input-depth 16 "input.avs"

Of course, tunings should always be adjusted according to source and CRF desired.

File: download.jpg (7KB, 225x225px) Image search: [Google]

7KB, 225x225px

>>60414000
Hold out for AV1 as >>60415020 suggests.

HEVC is animu meme tier.

>>60415104
Not necessarily. Not good for old analog anime or non-flat highly detailed texturized and cgi anime either.

If you ever want to play your videos in a web browser, you don't want HEVC.

HEVC will force me to update all my computers just to see videos
>Please make it come later
>Please

>>60417063
That or AV1 will force goyim to buy a decent 4+ core CPU to decode 4k.

Recently I've been downloading only HEVC.
I used to download movies in the 3-5GB range now I can find get the same quality at much lower file sizes.
Not sure how it compares to 50GB x264 files though

>>60417285
>I used to download movies in the 3-5GB range now I can find get the same quality at much lower file sizes.

Because 99% of movie encoder "groups" (actually, kids) are shit that use lazy settings and profile 4.1

x264 profile 4.1 is up to 40% inferior to Profile x264 5.1. HEVC still can't beat x264 profile 5.1

>>60414000
It can store the same quality at half size compared to h264. But for GPU encoding you need at least GTX9xx and probably most TVs don't support it yet. So no meme if you have a good GPU

>>60414000
well definitely not now that AV1 will be out soon. If anything move to VP9 since licencing is a dead meme

>>60414784
>>suggesting a lossy to lossy encoding

ALL video online is lossy to lossy, there are no raw 1TB intermediate for a movie

>>60418945
Well, we also call BDRemuxes and transport streaming with no subtitles RAW, while that is not the correct term either. You got what I meant by that: recompressing an already overcompressed video in the first place.

>>60418157
>It can store the same quality at half size compared to h264.
That is a blatant lie. Stop propagating nonsense second hand jornalists and bloggers repeat without actually doing proper research about it.

>>60414000
It's a great and efficient codec...however not ready for prime time yet.

H264 is mature and everywhere.

H.265 is definitively worth using if you are encoding video from a good source. Video recorded with a cellphone, for example, become rather huge H.264 files who are not very well compressed for some reason (your phone may vary). Re-encoding these to H.265 will save you a lot of space without losing quality. If you're going to rip something like a BlueRay disc then it's also definitively worth using.

If you have a movie collection of BD-rips then it's probably not worth re-encoding but I guess that depends on how lossy the original rip is.

I re-encode all musicvideos and other videos that I put on my phone to H.265 because it saves a lot of space and all phones made the last 3 years have support for it. The PC on the other hand has been lagging, for example it's just the latest Intel CPUs that have hardware decoding for it and Ryzen doesn't have it. AMD GPUs do have it now but that's just starting with the latest cards (RX 4xx and later).

If you got hardware support for decoding it then there's really no reason not to use it. It really is much better. As for the alternative, VP9.. ffmpeg doesn't support encoding that multi-threaded which, to me, means it's a non-option. And AMD gpu's don't even have support for it.

You guys know that HEVC aka H.265 is already yesterdays news right?

JEM is the path forward unto a new and enlightened experience.

Overview on page 15: https://www.dvb.org/resources/public/scene/dvb-scene49.pdf

Details: http://mpeg.chiariglione.org/sites/default/files/files/standards/parts/docs/w16698.zip

>>60421921
Any codec can store the same quality at half size.
Although, I've seen h265 encodes that look great at really low sizes.

>>60422110
So H.266 is coming right after AV1 and it's even better.

>>60417063
It really is quite sad that the PC platform is so far behind. My two year old tablet has HEVC hardware decoding and can play it in 1080p just fine. My two year old laptop can't even play 720p.

The very latest NVidia and AMD GPUs have hardware decoding but fairly new GPUs like the R9 390 doesn't have it. Ironically none of them do VP9 hardware decoding and that's also been a standard feature of cellphones and tablets for quite some time. Then again.. a $99 cellphone also has a good speaker and a 13MP camera these days while laptops usually have garbage speakers and a 1MP camera.

File: AVNONE.png (45KB, 850x572px) Image search: [Google]

45KB, 850x572px

>>60422184

Not only that, but the article shits all over AV1:

>An experimental software model, AV1 derived from VP9, was released in 2016 and according to a recent study of an AV1 software snapshot, it is fully based on VP9 with two additional in-loop filters which are supposed to provide about 2.5% bitrate reduction on top of VP9. The additional filters are disabled by default, enabling results in compilation errors. Currently the AV1 software is a moving target with no official release versions.

>It can be seen that the AOM AV1 encoder performs even worse than the H.264/AVC JM reference encoder.

>2.5% bitrate reduction of VP9
>14.8% more overhead compared to H.264

AV1 BTFO.

>>60414000
Rendered obsolete by AV1

>>60414784
>Using profile
You're embarrassingly far from professional

>>60422329
LMAO, you got to be kidding me.

The AV1 bitstream format is scheduled to be frozen sometime around Q4 this year.

Let that sink in.

h.265 is here NOW. We can use it or not use it. We can test it and see how it works. We can tune it and get minor improvements.

AV1 hasn't even got a final bitstream format. We're pretty far away from something meant to be used. The "journalist" testing some experimental code couldn't even figure out how to compile it. Perhaps AV1 will be good, perhaps not. What we can say for sure is that there's really no point in looking at that format until this time next year.

>>60422455
I don't use profile, I use custom tuning for each sample, if you had read my comment properly you would have read that. But for purpose of testing, profiles and built-in tunes are a good reference start for a standardized comparison, now fuck off.

>>60422281
Why can't we add new codecs to pcs

>>60422479

It's a known fact that VP9 can't use some of the same algorithms that make HEVC as efficient as it is due to licensing issues. Furthermore, it takes about a decade each time a new H.26x format comes out due to research and development. AV1 is just trying to cobble together a fully "free" codec that is somewhat comparable to HEVC.


Oh and also:
>The "journalist" testing some experimental code couldn't even figure out how to compile it.

See: >>60422110
>Benjamin Bross is a Project Manager at the Video Coding & Analytics Department of the Fraunhofer Institute for Telecommunications - Heinrich Hertz Institute, Berlin

Next time try to actually read the article before autistically flailing against the keyboard.

>>60414000
My laptop is loud when using it so I always download h264, also have to force h264 on youtube because vp9 makes it run kinda hot too.

https://addons.mozilla.org/en-US/firefox/addon/h264ify/

Absolutely not a meme if you have at least marginally decent hardware.
I've been slowly replacing my collection from AVC to HEVC (not re-encoding but getting new HEVC encodes from bluray sources) and it's been great. I've managed to greatly increase the size of my collection without needing more storage space thanks to HEVC savings.
Quality-wise it's simply fantastic. Just find a release group who knows what they're doing.

>>60422859
You have no idea what you are doing. You also probably have eyecancer.

>>60414784
>>60415393
>>60414000
I know it's not the place to ask this, but could you tell me the difference between h264_nvenc and libx264? Is there a significant difference in quality? Hardware encoding is 200x faster for me

>>60423490
>Is there a significant difference in quality?
Can't you find this out by just looking at the results?

>>60423490
GPU encoding is basically for live streaming. Shit quality for archiving compared to x264.

>>60414123
>reencoding lossy shit
retard

>>60418945
>not shooting with black magic ursa in raw

File: 32.jpg (203KB, 585x511px) Image search: [Google]

203KB, 585x511px

>>60414784
> professional encoder
more like literal retard

>>60422859
>Just find a release group who knows what they're doing.

no release group that is worth downloading is using h265

>>60424925
>group that is worth downloading
>still using outdated and inefficient codec

>>60425143
t. public tracker pleb

>>60425386
>who needs h264 when every release group worth downloading uses xvid

>>60422859
every hevc encoder is curry as fuck yify shit

sorry but the Tsar of encoding, daiz already did tests and h265 HEVC is better than h264. Not to mention latest nvidia video cards have support for HW 10,12 bit decoding

AV1 is still a meme

>>60426076
AV1 isn't even finished yet so it's pretty stupid to complain about its usability.

>>60422329
What a pile of clickbait crap xDDDDDDD

'journalism'

>>60425447
Quite a few of them are, but definitely not all of them.

Why aren't animu torrents encoded with h.265? There's literally no noticeable difference (in animu) and the end result is almost half the file size.

>>60427179
It's fairly new so very few people know how to fine tune it. h.264, on the other hand, is what everyone knows how to use. It's also much more computationally expensive to encode.

>>60427179
There are, you just have to know where to look.
There's no noticeable difference in film too, if done properly.

It's not very mainstream yet because it doesn't run well on VLC and on most people's toasters.

>>60427299
I'm pretty sure that most people would have a cpu powerful enough to software decode a 1080p main 10 file.

>>60427179
underwater did HEVC releases

>>60427517
Most normies have facebook machines that can't handle HEVC.

>>60427766
normies use crunchyroll, not fansubs

HEVC is fine but encoders try so hard to make it look like garbade. If only they reduce the file size like 30-40% compared to the x264 it would be fine, but they try to reduce it like 100% at minimum.

>>60427782
Crunchyroll uses fansubs. They have almost no professional translators.

>Streaming

HEVC hardware encoding on GTX 10xx GPUs is fast but absolute shit, even with tweaked settings to maximize quality at any speed cost. Most streaming software doesn't support H265 yet.

CPU encoding at 30+ fps is only possible at settings that render it inferior to H264 presets of comparable speed.

>4K HDR

No content and no point. Unless your eyes are 10cm or less away from the screen, you're not going to be able to see the black space between pixels on 1080p screen. HDR is not supported by any TVs or monitors, unless you're willing to shell out massive bucks. What's marketed as 'HDR' is typically bullshit, where the screen can't even display 10-bit color let alone achieve the contrast ratio required. I don't believe there's a TV or monitor in existence that supports the full Rec. 2020 color space.

>Re-encoding H264 videos to save space

Waste of time and money (electricity cost + hardware wear). Re-encodes will always be inferior to the original, and you'll never get the original back unless you download it again.

>Sharing small-sized videos

The point of sharing small-sized clips is to save time. H265 encoding requires lots of time, and the best reduction you can get is only 50%.

~100kbps-1000kbps clips do a significantly better job of retaining watchable quality than H264 does, and is the only niche of any practical use.

https://my.mixtape.moe/eyoeoh.mkv

https://my.mixtape.moe/mlbchd.mp4

AOM is shit btw

>>60428114
>AOM is shit btw

What did he mean by this?

>>60427863
What

>>60428271
Most of their translation staff are former fansubbers

>>60414000
600MB 720p movies look passable, so that's OK in my book.
I don't think you can get the same quality with h.264.

>>60428288
so they are no longer fansubbing neets

>>60428196

Meant AV1, but AOM are shit too

Made wild claims about 50%+ bitrate saving over HEVC instead of actually getting any work done. How long's it been now since we were supposed to get Daala? I think it's about 4 years now, and all they've done since then is wrapped up Daala and presented it under a new name

>>60428408
That doesn't mean their quality improved.

>>60428469
The quality is of course better than any cartel subs who dare to localize jokes or remove them

I haven't seen anything. I see HEVC h.265 encodes out there and they're hit or miss. The space savings are nice but that's it. I've been ignoring them mostly since it's not finalized and it looks like others might surpass it at some point like AV1.

>>60428433
Yeah but I mean it hasn't even been released yet. Their current ETA is something like Q4 2017, presumably because they took the whole thing back to the drawing board instead of releasing something that's trash.

Are they actually incompetent or just slow? I'm actually waiting on AV1 to encode a ton of shit, so I hope it ends up being at least slightly better than H265 once it goes stable.

>>60428572
>The space savings are nice but that's it.
What else did you expect?
Most sources are bluray and h.264 anyway, so it's not going to have better colors and stuff.

>>60414000
Total meme. Just stick with H264 until hardware acceleration for H265/HEVC becomes more ubiquitous

>>60414784
>As of the version 2.3
Guess you are talking about x265. For a "professional" you seem to think H.265 (the standard) is just x265 and can be used interchangeably.

File: AV1 AOM Encoding.png (91KB, 677x846px) Image search: [Google]

91KB, 677x846px

>>60415020
>>60415402
Gonna be awhile, here is me encoding 1080p recently with AV1 in pretty much default mode. I have a FX-6300 which is certainly not cutting edge but fast enough currently. Despite telling it 6 threads it was single core the entire time. After quite a bit of time I was 75 frames in and encoding 1.5 frame per minute. So I just quit. This picture is from April of this year.

With Super Slow preset in x264 @1080p, I tend to average 6-10fps depending on content.

File: logo4-1.png (20KB, 307x81px) Image search: [Google]

20KB, 307x81px

>>60428633
>>60428726

AV1 is going to be better than HEVC, and not bogged down by the JEWS at MPEG-LA and the other license parties in the HEVC group.
AV1 will have won this competition by 2019, screencap this.

>>60428855
Now that I look at it I think at the bottom, the 75 counts the look ahead, and the 50 stood for 50 frames encoded so far.

I tried decoding it and got some pretty messed up color problems. Like decoding the raw video with the wrong color scheme so I just dropped it.

File: old_town-PSNR.png (21KB, 1070x575px) Image search: [Google]

21KB, 1070x575px

>>60414784
>professional encoder
>very slow preset
>doesn't even mention 10-bit encoders
Fuck off you troll.

For everyone else, yes you should switch. Latest snowfag x265 encoder is at least 50% more efficient than H264.

You can get it here and see for yourself:
https://builds.x265.eu

>newbie encoding guide v1.0 [04-06-2017]

>Video codec
Use HEVC, hardware decoders for it are plentiful.

>Quality
Use CRF unless you desperately need to fit your video in a specific streaming bandwidth (VBR) or fit inside a specific medium such as a 1GB file size or dvd (VBR 2 pass). 22 CRF means a good quality compared to original and 16 CRF means high quality compared to original. Using any other CRF beside 0 for lossless encodes should be avoided.

>Preset
The "fast" preset should almost always be used as it gives you the best balance between video compression efficiency and encoding speed. Anything faster will give you bigger file sizes and anything slower will give you slower encoding speeds.

>Encoder
Staxrip should be used for most things unless you really need to fine tune your shit, in which case MEgui will suffice

>10-bit or 8-bit
Generally 10-bit will help out with color banding and improve compression efficiency but at the cost of little hardware decoding support. So only use 8-bit if general hardware decoding compatibility is important to you.

>>60428886
Can someone link me to some AV1 documentation for reference please? I'll look up at the beginning of this thread too, but I would like some solid information as to why it's a potential standard moving forward

t. Another professional encoder who's org is mulling over HEVC vs VP9 currently

>>60428698
I'm being general about the lack of quality for the space. I'm usually better off grabbing 576p DVD's in some cases. This is or was the case for certain HD encodes and scene groups too. I'm not really saving space or enough.

File: gorilla-thinking-680x382.jpg (52KB, 680x382px) Image search: [Google]

52KB, 680x382px

>>60428946
>Anything faster will give you bigger file sizes and anything slower will give you slower encoding speeds.

>>60428993
It's basically VP10, but with every major company under the sun pouring their resources and unfinished projects into it.

>>60426076
Daiz is an idiot. A good encoder is the one that master Avisynth, not x264 tune settings. There are plenty of people that have more knowledge in Avisynth than him.
>>60424904
hurr.

>>60427179
>>60427229
With proper tuning flat anime may have better savings than regular x264 encodes but it still have problems with detail retention of low contrast detailed textures, no matter how much you tweak the AQ.

>>60427766
There are thousands of Atom based notebooks out there. (Celerons Nxxx) Those things can't decode HEVC 1080p natively.

>and the best reduction you can get is only 50%.
You were doing fine until you said this bullshit.


>100kbps clips do a significantly better job of retaining watchable quality than H264 does,
>100kbps
>watchable

Even at 720p that is impossible unless you are legally blind or have eyecancer.

>https://my.mixtape.moe/mlbchd.mp4
smudged as fuck

>https://my.mixtape.moe/eyoeoh.mkv
Also pretty smudged but "passable". Now take a shot with the camera moving too and watch the thing fall apart quickly and the bitrate ramp to much more than 1000kbps.

Only reason those look remotely decent is because the first one was made digitally with good light, so no grain. The second one looks degrained, but the only way to get H265 to deliver decent quality on a full lenght movie with less than 2000kbps average, would be to degrain the whole thing with tr=2 or tr=3 with SMdegrain which is painfully slow.


>>60428364
>600MB 720p movies look passable,
Enjoying your eyecancer yet?

H.265 is fire.

>>60414784
holy fuck, what a fucking retard.

>>60428433
>>60428855

Paid MPEG-LA shills detected. Literally contrarian fucks who are against an unprecedented decision to go 'open' by many major companies.

>>60428633
>>60428886

They haven't finalized the bitstream yet(?) but there's already an encoder and you can play the output with mpv

Highly doubt they're going to go from inferior to H265, to beating it by 25%+ in a few months

>>60429054
Is there anything wrong with that? I'm open to improving my guide.

>>60428946
>Brought to you by YIFY® Standardisation Committee

>>60428946
>>60428761
>you seem to think H.265 (the standard) is just x265 and can be used interchangeably.

Of course I know the difference, Even if I distractely switched the terms, I have never seen a person that know about different tunings that doesn't know the differece. If you assumed I didn't you are an idiot. And is everyone uses x265 because it is by far the best free H265 implementation around, now fuck off.

>>60428946
>doesn't even mention 10-bit encoders
Are you retarded or what? I'm not fucking Daiz who is a total autist with 10 bit encodes even when they are not necessarily needed (grainy high bitrate sources) and only kill compatibility (for H264 standard)

>Latest snowfag x265 encoder is at least 50% more efficient than H264. At what profile? What settings?
>PSNR graphic
>WHAT IS FUCKING PSY
>Generally 10-bit will help out with color banding and improve compression efficiency
>he feel for the 10bit banding meme

See, you are the one that have no idea what you are talking about now.

>>60429197
I think he was pointing out the "well, duh" nature of that sentence. It's like saying "things that are more expensive to produce will cost more money".

>>60429170
>inferior to H265

Source? Isn't VP9 already basically on par with H265?

>HEVC Main 10 is well supported through hardware
>can finally watch my cartoons in a normal way once the groups start using HEVC
Fucking hell. Anime groups constantly overestimate the quality their users will put up with - 8-bit H264 was more than good enough considering most people just stream animes in godawful quality online. But no, 10-bit had to be used with inane encoding settings, killing all hardware compatibility in the process.

God, I hate public anime release/encoding groups so much.

>>60429170
>Highly doubt they're going to go from inferior to H265, to beating it by 25%+ in a few months

Care to elaborate on your bullshit?

Here's my sources:
https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/

>>60428993

If you need something TODAY just go with h.265.

AV1 is still bogged down in the weeds.

Here is the status of the codec as of January:
https://www.youtube.com/watch?v=lzPaldsmJbk

If you REALLY want to wait, then wait for JEM to be finalized: >>60422110

>>60429165
Post your encoding speeds fag like I did.

VP9 is good and use it.

>>60429318
>Fucking hell. Anime groups constantly overestimate the quality their users will put up with - 8-bit H264 was more than good enough considering most people just stream animes in godawful quality online. But no, 10-bit had to be used with inane encoding settings, killing all hardware compatibility in the process.

Worse thing is that they propagated the myth that banding can only be fixed by 10 bit encoding and is caused by 8 bit in the first place, whereas few people actually explained properly that the original banded anime sources were caused by bad digital filtering of textures, not of limitations of the final BD encoding process. If you use a debanding filter it will hold up pretty fine with a 8 bit encode with high quality settings, 99% of users only have 8 bit screens anyways and no one seems to realize that.

10 bit for debanded anime gives 10~15% savigns only on small very compressed and very flat animation. Anything that has grain and more fine texture like analog anime or Film this benefit vastly gets reduced to 5% at best. I always think that compatibility shouldn't be thrown away that easy, but Herkz and Daiz are completely retarded elitists that forced 10 bit all of the time even when it wasn't that benefical with their stupid A+ filter criteria. Well, at least they didn't use FLAC, the most retarded thing to appear in the anime encoding scene since over-localized subs.

>>60428946
Psnr is worse than ssim which is still worse than the human eye.

>>60429432
Also every source besides UhdBluray, is 8bit to start with.

>>60429098
>Even at 720p that is impossible unless you are legally blind or have eyecancer.

80kbps + 17kbps audio @ 720p:
https://my.mixtape.moe/nobzfj.mp4

30kbps (more action/cutscenes; text and imagery is still easily identifiable):
https://my.mixtape.moe/tsiabv.mp4

96kbps 480p porn:
https://my.mixtape.moe/enbbtf.mp4

>You were doing fine until you said this bullshit.

In the 100-1000kbps range, HEVC saves ~50% of the size for comparable quality generally

>would be to degrain the whole thing with tr=2 or tr=3 with SMdegrain which is painfully slow.

Degraining is unnecessary and probably harms the results. You're setting a rule where the encoder could otherwise make better cost-benefit decisions (i.e. SAO)

What exactly is AVC? Given two anime BD rips, should one go for AVC or Hi10p version? What's the difference between the two?

>>60415161

>You are retarded. It compresses files better while keeping the same quality as x264.

Bullshit, it beats x264 at VERY low bitrates and at resolutions that are bigger than 1080, for the typical media today (720p, 1080p) x264 does equal or better, at MUCH lower encoding times.

There's a reason the 'scene' haven't moved on to HEVC, heck even the anime scene which jumps on any improvement, like x264 10bit which isn't even supported by hardware, is not moving towards HEVC.

HEVC is dead in the water, AV1 will be what everything transitions to after x264.

File: download (4).jpg (7KB, 390x129px) Image search: [Google]

7KB, 390x129px

>>60429244
Yify uses 2-pass ABR encodings, which I loathe. 22/16 CRF 10-bit HEVC should be used 90% of the time desu.

>>60429267
shut the fuck up

>>60429273
hmmm okay. Maybe: "Faster presets will increase file sizes and slower ones will make encoding times longer"?

File: AVC 10000kbps VERY SLOW FILM CUSTOM TUNNING.mkv_snapshot_03.36_[2017.05.16_15.46.20].png (4MB, 1920x800px) Image search: [Google]

4MB, 1920x800px

>>60429605
>https://my.mixtape.moe/tsiabv.mp4
What the fuck is this? What is the point of that? That is unwatchable even on a 4.7 inch screen.

>In the 100-1000kbps range, HEVC saves ~50% of the size for comparable quality generally
Fair enough, too bad at that range for 720p everything looks awful.

TO be fair, I'm quite picky with quality of video. I usually find 3~5gb public movie releases a torture to watch and in that range (around 4000kbps) there still is some benefit in switching to x265. However, I encoding a 1080p movie around 4000kbps in 720p instead of 1080p in x264 will give a less smudged image overall than x265 at 1080p with exception of very low movement scenes, so again, the benefits of x265 are questiona.

But for
For 5000~8000kbps 2.40 1080p the difference disappears on light grain 35mm sources, for anything 8000+ more x265 fail with any tested tune I have ever seen to surpass x264.

>Degraining is unnecessary and probably harms the results.
I'm too lazy to find and cut the test encodes I did to upload at Mixtape moe. But trust me, degraining an original 1080p movie and encoding in 720p will be better than encoding it in 1080p or just dowscanlling. SAO does not substitute a good degrain filter of course I'm talkinga bout high quality light degrain here, not a aggressive 7,7,7,7 HQDN3D.

>>60429311
No, HEVC is better

http://iphome.hhi.de/marpe/download/Comp_LD_HEVC_VP9_X264_SPIE_2014-preprint.pdf

>>60429462
Yes but in this case it's just being used to compare how much better one preset is compared to another one at a specific bit rate. As you can see anything faster than the fast preset brings single digit gains which aren't worth it imho. Going from say 3GB to 2.9GB isn't really that much of a jump.

>>60429751
>that picture
>falling for the 8 bit causes banding meme

No, you shut up, preferable by choking yourself to death with your own eyes.

File: 10vs8bit.png (189KB, 625x277px) Image search: [Google]

189KB, 625x277px

>>60429791
>>60429831
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

Piss off you retarded sack of shit with down syndrome, you're really starting to get on my nerves.

>>60429854
>10 bit source

>>60429809
>As you can see anything faster than the fast preset brings single digit gains which aren't worth it imho.
>still thinking PSNR can represent the perceived quality
>justify PSNR results to not use slow settings

Holy shit, you keep spouting one gold nugget after other .

You have obviously never made some proper quality test encodes at very slow custom tuned settings and performed proper ABX tests.

Quality differences from medium to very slow are pretty fucking noticeable in x265. I personally don't think the change from slow to very slow is that benefical specially considering the encoding times, but from fast to slow is pretty hell clear even after an ABX test. Do some real tests yourself.

>>60429751
Joke image, and you can tell 8bit x264 to stop stealing bit rate from low contrast areas to improve any banding problem. I mean 99% of your sources are already 8bit on the disk. Going to 10bit wont create original colors as they were never there. Best case would be to 8bit to 10bit with dithering. Which is creating colors that were never in the source but gives truer 10bit gradients.

>>60429311
>>60429325

There was that comparison done recently where AV1 was found to be 65% worse than x265 (and significantly worse than x264, VP9)

x265 will point to that, AV1 will point to tests where AV1 does better. I only take such tests with a grain of salt. I think it's best to download the encoder and test yourself, which you can do now with AV1 and H265. The reason you can't go by these comparisons people do is because they're comparing it against a made up standard such as PSNR, and they always use the default settings rather than tweaked settings (especially important with x265).

I've compared x265 and AV1 with my own tests, and AV1 isn't that bad, but it's definitely not better than x265 and it's not matching it. AV1 is also extremely slow, which I expect is what AOM will be focusing on during the next few months, rather than trying to make the quality better than x265. The only area where it seems AV1 could be better than H265/H264 is at extremely low bitrates (20kbps and under).

>>60428993

>but I would like some solid information as to why it's a potential standard moving forward

AV1 (which is a working name, it will be called something else when it's finalized) will be what everything will move to when they transition from h264.

The main reason it exists is because the big companies behind it, Google, Microsoft, Amazon, Netflix, Nvidia, Intel, AMD, ARM, Adobe, Cisco, Mozilla and a ton more, have realised that being stuck in MPEGLA's royalty trap is a bad prospect, so they merge and create a better and royalty free codec.

It's based on the VP10 codec work, with more techniques supplied by Cisco and Daala and other stuff they've come up with during development.

Here are some links with information on the state of AV1 (which may have improved more since these tests as it's still developed and the bitstream won't be finalized until Q4 this year)

https://www.elecard.com/page/aom_av1_vs_hevc
https://www.elecard.com/news/results-of-elecards-latest-benchmarks-of-av1-compared-to-hevc

In short, HEVC is dead in the water, not only because of AV1 coming, but also because of the insane greed of the HEVC patent holders which has resulted in three different entities you need to negotiate royalties with in order to use it.

AV1 is royalty free and better than HEVC, will be supported in hardware by Intel, AMD, ARM, Nvidia, Broadcom, Realtek, in all software by Google, Microsoft, Mozilla etc, and by all streaming giants Google, Netflix, Amazon.

File: IMG_0338.jpg (148KB, 545x832px) Image search: [Google]

148KB, 545x832px

>>60429381
This is all good info re: AV1 and JEM thanks guys

>>60429873
I did m90. I spent weeks testing out different encoder settings so I could get rid of nearly 2TB worth of blu ray muxes I downloaded.

What I found was that while using a CRF of 22 like a normal human being instead of some random bitrate I pulled out of my ass, the fast preset gave me the "best" file sizes when taking encoding speed into account.

>>60429892
fuck man, read the dam pdf in >>60429854

>>60414926

Nicely done

>>60429865
>being this dense

>>60429917
Really great info thanks man

File: 8bittestencodevs01_snapshot_00.02.12_[2017.05.16_16.21.53].png (2MB, 1920x816px) Image search: [Google]

2MB, 1920x816px

>>60429854
>>60429949

>http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf
You do realize the one on the right is also 8 bit? You do realize that png is 8 bit right?

I have done deband tests with high quality 8 bit encodes and compared it to 10 bit at same bitrate settings. The rouding erros problems are irrelevant for perceived quality given enough bitrate. At high quality settings (CRF 17 and better) the bandwidth gains are pretty negligible, less than 5% at best.

Pic related is an 8 bit x264 encode I made for myself with f3kdb. All original awful banding on the source was removed and properly preserved in 8 bit encoding.
(correct pic this time)

>>60429938
>crf 22
If you think CRF 22 is acceptable, you don't have well trained eyes yet.

Try at least 18 next time.

>>60430111
Alright I'll try to make this as simple as possible for your thick skull:
10-BIT ENCODERS HAVE MORE PRECISION THAN 8-BIT ENCODERS

THEY CAN PICK FROM 1 BILLION COLORS VS ONLY 16 MILLION

THIS RESULTS IN LESS COLOR BANDING ACROSS ALL BITRATES AND 5-20% BETTER COMPRESSION EFFICIENCY ACROSS ALL 8 OR 10-BIT SOURCES

1 BILLION > 16 MILLION

DO YOU UNDERSTAND?

>>60430266
Depends on the source dumbass.

>>60430266
Let me explain better to you instead.

With the exception of brand new scarce BT2020 UHD material out there, all modern consumer digital video in existence is originally 16 million colors. The point of an encoder using a 1 billion color profile is that when encoding with a lot of compression, it throws away a lot of intermediante bits in gradients. With 10 bit it can reconstruct those gradients with a more smooth ramp with more intermediate and predictable steps resulting in smoother gradients and reduced filesize.This can result in over 10% savings, indeed.

However, if you encode in high enough quality settings, there will be much less loss intermediate information between blocks, so there won't be a need of reconstructing those gradients in the first place and they will look exactly how they were even at 8 bit encoding, the savings in 10 bit will hardly reach 5% and won't give a superior quality than the original.

Why is this so difficult for you to understand?

>>60424792
so what? You do realize the difference between lossless->lossy and lossy->lossy is negligible in REAL LIFE, right? Even commercial blurays are not lossless, dafuq

With the right settings the difference is nigh imperceptible. Do you stand there with a magnifying glass looking for differences in your transcodes?

jesus fuck i swear this place is full of autists who just want to disagree purely for the sake of being autistic cunts and nothing else

>>60430298
Clown, not you too. :(

>>60430352
Oh well in that case yeah 8-bit vs 10-bit becomes retarded but who the fuck saves video in 100mbps? Why do you think yify rips are so god dam popular. Why do you think I delete my whole collection of blu ray remuxes?

File: strawman.jpg (26KB, 400x400px) Image search: [Google]

26KB, 400x400px

>>60430434
>100mbps

>>60430434
"high enough quality settings" doesn't mean 100mbps, but more like 8~10 depending on the source, this can result in less than 8gb for a 1h:47m movie which is not that absurd. Can even fit on an ancient DVD9.

YIFY is popular because the majority of people indeed have eyecancer and low standards and he had access to a shitton of blu rays and consistently delivered a lot of movies per week. It is also popular because it was quite small. However, their encodes were far from any good. They choose a target filesize that please many people, but they could have delivered better quality with more optimized encoding settings.

>>60430520
I'm exaggerating but you get my point.

>>60430545
So you'd rather have bloated encodes than deal with 10-bit internal encoders despite them having a growing number of hardware encoders (kabylake, Snapdragon 820 and up, ect)?

>>60430584
*hardware decoder
but the encoders exist as well

>>60430584
>So you'd rather have bloated encodes than deal with 10-bit internal encoders despite them having a growing number of hardware encoders (kabylake, Snapdragon 820 and up, ect)?

No, for HEVC I embrance 10 bit easily because it is now part of the standard and can be hardware decoded on any cheap Android TV box.

For x264 it was retarded on many cases because it could only be decoded via software. It made sense for daily TV airing episodes with reduced filesize (around 350~500) per episode, at that level the quality was indeed significantly better than an 8bit equivalent, but the for bloated storage, specially old analog anime it was just utterly pointless to sacrificy long ter compatibility over 5% gains. As much as I love to stay on my room with my big ass high quality AH-IPS 10 bit like any other Neet, I sometimes had problem playing 10 bit out of home and reenconding (or plex non-direct streaming mode) was a pain in the ass and reduced to much the quality.

Also 8gb for a movie is not bloated at all, but 1.5gb per anime episode is kinda ridiculous, specially for shitty upscale shows.

>>60422597

The problem is that it is done through hardware decoding. Many CPUs and GPUs today come with various kinds of hardware decoding that makes them better

So "adding a codec" means you have to replace a component in your PC with one that has hardware decoding for that particlualar codec. That often means replacing the CPU and the motherboard at the least, and perhaps even the RAM depending on whether or not you're upgrading from DDR3 to DDR4. If you have a aftermarket cooler, you might have to replace that as well because the new motherboard. And if you already have a high performing PC, replacing those parts might run you several hundred dollars and the gains in almost every other regard than HEVC playback might be negible.

With phones, well, you really just buy a new phone and you get a better literally everything. I mean, I'm fine with spending 500 dollars on upgrading my phone and get a bigger and better display, moar coars and more storage but I'm not at all fine with spending 500 dollars just to play some obscure codec hardly anyone uses.

>>60430111
Now compare to gradfun3 in 10bit.

Let's summon him.

Daiz
Underwater
Commie
Nyaa
NyaaTorrents
H.264
H.265
HEVC
10bit
madVR
MPC-HC
Fakku

>>60430665
Hmmm what CRF you using?

8GB seems like a lot even for a 1080p movie

Any thoughts on FLAC?

Oh if anyone wanted to know I was able to compress my blu-ray remuxes down from almost 2TB to around 300GB with about the same quality.

10-bit 22 CRF fast preset HEVC encoding was used.

>>60431159
Meme. Either stick to Opus or WAV

File: FLAC is cancer.png (11KB, 590x127px) Image search: [Google]

11KB, 590x127px

>>60431159

>>60414000

Spending time on learning how to best use HEVC is a waste, it's clear now that it will never be the successor to h264, that crown will most likely go to AV1, and even that will take quite some time after it's finally released (likely around december 2017).

So you are better off using h264 for now, for encodes that are not bitrate starved, it does just as well or better than HEVC, at a much higher encoding speed, unless you are targeting something like 4k resolution.

HEVC never made a splash, the entire internet still runs on h264, heck even VP9 has better market traction than HEVC simply due to Google using it on Youtube.

>>60414000
>is it still meme-tier or is it worth switching to yet?

Well, when the torrent you want is H.256, then that's what you'll be using.

Just update your codecs. What's the problem?

>>60431332

>Meme. Either stick to Opus or WAV

Opus is the best LOSSY audio codec, but WAV ?

Are you insane ? FLAC losslessly encodes WAV in to a much smaller file, then you can easily decompress it to WAV again should you need to, with no loss of quality.

>>60431442
>then you can easily decompress it to WAV again should you need to, with no loss of quality.

impossible

>>60430751
It'll probably be about 5% smaller. I need to prepare a comparison for under 100 megabytes for when this kinda of subjects appears again...

>>60431088
Well, I don't save every single movie I watch in 8gb, otherwise I'll go bankrupt buying HDs. but I do burn lots of DVD9 and also BD-Rs (1 usually encode 3 movies per 23.3gb disc). Simpler movies and not so important I rather do a 3.5gb 720p encode. CRF values varies a lot, usually around CRF 17~18 with mbtree on for 2.40 movies gives about that filesize. But I often use 2 pass to fit movies in BDs.


>>60431159
FLAC for video is utterly retarded. (for arhival of music is ok, of cours) Differently from video encoding where you can pause and pixel peep, 99% of samples become 100% transparent for 100% of people given enough bitrate on a modern lossy codec. Many people think they can percevei different on a 200kbps AAC or even mp3 and prefere flac. Turns out they are being fooled by Placebe by the own subjective self-suggestion. They always fail double blind tests on the first time.

Anyway, for video, I recommend AAC for stereo and for multichannel, given enough bitrate, AC3 for compatibility, although some players had patent issues with AC3, so having a backup stereo AAC track is always a good idea.

>>60431347
q127 is overkill.
Stick with Q91 or even 82 for video. Video soudtrack does not have as much high frequency loud information as music. Do an ABC-HR if you don't believe me.

>>60431316
CRF22 is simply too low for me. I bet you would get better quality results if you downscalled to 720p and used 19CRF. I have already made such a test. I encoded a test sample at x265 24crf very slow, then got the resulted bitrate and encoded in 720p with x264 in 2pss. The x264 result was better looking and much faster encoded. instead. A light degrain, even with hqdn3d may help. Try that.

>>60431332
Opus for video is another compatibility killer. AAC is fine.

>>60431332
>wav
WHAT.

>>60431720
If people realize it's retarded then why does almost every 1080 BDRip anime come with FLAC, I don't get it.

>>60431436
maybe he encodes chinese cartoons bdmv like i do.
as for me, x265 is still too damn slow.

>>60431504
FLAC uses lossless compression, while MP3 is 'lossy'. What this means is that for each year the MP3 sits on your hard drive, it will lose roughly 12kbps, assuming you have SATA - it's about 15kbps on IDE, but only 7kbps on SCSI, due to rotational velocidensity.

>>60431866
Retarded encoders.

>>60431866
>anime
found your problem

>>60431866
FLAC started to be used back in the day when there was a rise in 6.1 DTS channel audio in 2009.

DTS was not very compatible and had trouble in bitstreaming and AAC was not compatible with 6.1 format back then, only 5.1 or 7.1. They people started use FLAC because it was much more efficient in lossless than DTS and the only way to preserve 6.1 channels.

But then somehow that became popular and people started using FLAC also to preserve the 24 bits of some DTS. But no big decent groups used FLAC back then. Then the thing got out of controle and people started using FLAC as a "superior" format even for 16bit stereo without ever even doing a proper ABC-HR test.

Anime fansubing has been in decadence for a log time now. Many reencode groups are quite mediocre and don't know what they are doing just copying settings from other groups. Even trusted ones. They are even worse when it comes to audio, because testing the quality of an audio encode is not as easy as pixel peeping, they don't even know about Double Blind tests and the power of the placebo effect. MANY MANY encoder and fansuber groups are ignorant about audio but THE BEST ONES don't use FLAC, including the cartel. (not saying they are the best fansubers, but when they don't bloat their releases too much, they do above average encodes). There simples is no point in using Lossless audio for video.

>>60430111
>crf 18
you're blind.
16 is clearly better. unless it's a shit show with artificial film grain.

File: [-__-'] Ghost Hunt - 19 [DVD 576p AAC] [D3441AB8].mkv_snapshot_22.01_[2017.05.05_18.43.39].png (1MB, 1024x576px) Image search: [Google]

1MB, 1024x576px

>>60430434
>Why do you think I delete my whole collection of blu ray remuxes?

>>60432008
That depend a lot of the settings. I was suggesting CRF 18 for 1080p but I rather go at least with CRF 17, but I was sure the guy was going to bitch that was too bloated. For 720p you need to go much lower. Even so, a properly configured tune with AQ 0.65~0.8 is fine with 17 in most case at 1080p specially for a grainy source which I prefer to turn mbtree off which kinda increases the relative quality per CRF setting overall. It's not like I want to preserve every shitty show in maximum quality.

>>60431945

kek

HEVC seems to do better than H.264 at low bitrates (say, 700kb/s for 720p video).

So if I just want to download something quickly (I have shit internet) I download HEVC releases nowadays.

>>60432386
Sub-1Mbps bitrates for HEVC and AV1 are only really justifiable for mostly static content. In motion they break.

>>60414000
265 is dead in the water, worse quality, slow as fuck, minor size savings, neglible for ANY MODERN country where internet is not metered. If my bluray isnt at least 12mbps I aint watching shit on the bigscreen.

H265 anime encoder here
You save about 1 GB for every 10 episodes when compared to h264

>>60433031
>H265 anime encoder here
Might as well announce to the world you're a subhuman retard. Anime encoders are great at pretending they know their shit. They don't.

>>60433078
Explain to me what I don't know then?
Or are you pretending you know your shit when you dont?

>>60433031
so, it's fucking nothing?
great job.

>muh compatibility.

What is this? 1997?
Maybe we should be encoding everything with Xvid 240i and mp3 for maximum compatibility, then. I mean, even yify is incompatible with my 10-year-old chinese mp4 player and that's unacceptable.

But seriously, if you aren't ready to accept the future (such as HEVC and opus), than you probably shouldn't be on the technology board.

Also, the whole AV1 vs HEVC is utterly stupid. HEVC exists now and is great. When AV1 comes and if it's superior to HEVC, we'll switch to that.

>>60432628
Still better than H.264.

>>60432991
>t. brain dead mongoloid

>>60433130
That's not gonna happen for a while. I love how these AV1 shills think that their stupid codec will be better than HEVC and have HW decoding support on 99% of stuff in a year or two.

That shit takes time.

>>60433117
I don't know shit about encoding, but I do know that anime encoders don't either.
>gigabyte or more per 20 minute episode
>10-bit H264
>level 5 or higher
Just fuck my hardware compatibility up for no particular reason.

i've been recording all of my webcam shows in HEVC using Bandicam...did i fuck up? why are some people claiming worse quality?

File: my head is beginning to hurt.png (41KB, 539x555px) Image search: [Google]

41KB, 539x555px

Damn, I just want a more efficient codec that is adopted by most and makes encoding faster. HEVC is still stupid slow, but the size gains are there. AV1 please hurry the fuck up. I still have xvid .avi somewhere on the drives.

>>60433186
No, they're just retards that used HEVC when it was released day 1 and assumed it wouldn't improve but it did.

Also what CRF are you using? I'd recommend 0 especially if you're gonna upload that shit to youtube.

>>60433259
Are you implying AV1 will be faster to encode than HEVC?

Anyway I get ~20 FPS encoding 720p 10-bit HEVC video using 22 CRF and the fast preset on my A10-7870K @ 3.8GHz.

What kind of dinosaur processor are you using?

>>60433308
>20FPS
for what purpose

Is HEVC terrible for grain, or is it just bad encodes?

>>60433172
blame daiz

>>60433337
Wot???

>>60433342
Just bad encodes. I had a ton of 720p movies with grain and I was still able to cram them in 1-3 GB file sizes with a CRF of 22.

>>60433122
> have 1000 animes on hard drive
> save 100GB
> nothing
I bet you also swear by 320 mp3 and not 192 Opus

>>60433377
You should thank our lord and saviour Daiz. He made qualcum and inhell develop 10-bit HEVC decoders for their shit.

>>60433422
>192 Opus
>Not opus 128

Why?

>>60433172
Why would anyone care about your hardware issues?
You're embarrassingly white.

>>60433186
>why are some people claiming worse quality?
I guess they're trying to be edgy.
Every video encode I've done was better quality in HEVC compared to H.264.
HEVC is much slower, though. But unless you're racing to be the first to release a video or something I don't know why that matters.

>>60433122
Not nothing. That's actually a pretty big improvement.

>>60433384
variable frame rate is trash and no standard video plays back at 20FPS

>>60433031
>H265 anime encoder here
More like reencoder. I don't have a single x265 anime, because all good encodes are x264.
>>60433384
I'm not talking about encode size, I mean grain preservation compared to source.
>I had a ton of 720p movies with grain
You reencoded? How disgusting. Your reasons for shilling HEVC appear to be solely for filesize. Suppose storage is a non-issue - what are the actual merits?

File: x265-2.png (582KB, 600x600px) Image search: [Google]

582KB, 600x600px

>>60433575
No, that was the encoding speed I got. The video frame rate was never changed from the blu-ray source.

This is why a lot of people get a hard on for ryzen processors. The $300 1700 OC'd to 4 GHz can encode 1080p HEVC video at 30 FPS or about 60 FPS for 720p HEVC video.

They probably used the medium or slow preset though.

>>60433628
Ah, gotcha. I'm retarded

>>60433447
> not 128
> why
Because if it's worth doing its worth overdoing

>>60418095
Nothing has hardware support for x264 profile 5.1 though

>>60431436

I'm a poorfag running Kodi on an Atom/Nvidia ION2. Has worked perfectly and silently for 6 years. H265 decoding is CPU@4fps

>>60414926
I thought there was supposed to be intelligent people on /g/

>>60433966
There are. There are quite a bit of retards as well.

>>60433839

RPi also can't play H.265
>no way, josephus

>>60433628
>tfw getting 8fps H.264 720p
Somebody buy this for me
http://www.ebay.com/itm/Build-Your-Own-Dell-T5600-Precision-16-Core-2-60GHz-E5-2670-No-OS-Wholesale-/382029040949

>>60415402
>hold out
So never ever use anything new then?

Being free doesn't make a codec good - being usable on many devices does.
Until AV1 has hardware decoding it's meme-tier garbage (which means it will likely ALWAYS be meme-tier garbage)

>>60433839
We all have to update someday anon.
Just keep using H.264 until you upgrade.

-t. Kodi/XBMC/XBMP user since Xbox.

>>60433130
>>60433460
You know, watching anime on a tablet or even a notebook on the bus or airplane is not really that bad. Even if you have a fast enough processor (octa core) to play x264 10 bit in software, the battery will die much faster if it was hardware decoded. Being compatible with Android TV Box is also nice, as the quality would be better than transcode streaming with PLEX. Specially if you are only sacrificing ONLY 5~10% of encoding efficiency (which does not mean inferior quality, just slightly bigger filesize) for those benefits. We are not suggesting reverting to XVID, don't be a retard.

>HEVC exists now and is great.
That is false, though. It is not great for high quality archival. x264 is still better.

>>60433628
>They probably used the medium or slow preset though.
Yeah, even if you find acceptable fast preset I don't. Most encoders won't have real time with HEVC ever. By the time processors get fast enough we will already have H.267, VP11 and AV2.


>>60433717
That is why I encode in 5.0, only 3 less ref frames and smaller buffer in practice that is almost no loss in efficiency.

>>60434881
>Being free doesn't make a codec good - being usable on many devices does.
Indeed. too bad VP9 can't do either and have worse quality than x264.

>>60433308
You seemed like a reasonable guy and then to a guy who wrote:
>HEVC exists now and is great. When AV1 comes and if it's superior to HEVC, we'll switch to that.

...you responded that he's a AV1 shill. Why all this fucking hostility?

The codec is not out yet, so there's no point comparing it. The hopes are high though because of the sides involved, the multiple-codec chimera thing and the whole idea revolving around ditching closed-sources licensed shit.

No one is claiming that a codec that isn't even out is already better.

We're just happy about the prospect that something might finally go in the right direction.

>>60435058
>bus rider

>>60435668
Ok well I have no problem with people like you. I do want AV1 to succeed, truly.

What gets my jimmies rustling is people claiming HEVC is DOA or trash when AV1 hasn't even been finalized.

>>60436008
Why don't you want a royalty-free superior codec to replace a closed expensive inferior codec?

>>60436126
>Why don't you want a royalty-free superior codec to replace a closed expensive inferior codec?
I do but I accept it's an unrealistic expectation. Anyway all hype should be out away for it until it's finalized at least.

This is like when everyone was overhyping kaby lake and it turned out to be a smoldering pile of steaming shit.

>>60436245
>This is like when everyone was overhyping kaby lake and it turned out to be a smoldering pile of steaming shit.

Well at least if AV1 is a flop, they won't be charging 330USD for it, kek.

>>60436387
What's sad is all that money spent just so they can jerk off about getting a few more FPS in some stupid video game. But yeah no loss if AV1 is a flop.

Though with how shit went with daala, VP8, Theora, and VP9 I don't expect it to be that amazing. Maybe match HEVC in compression efficiency and encoding speed for the same quality but nothing more.

Would be nice if AV1 + Opus became dominant though. I too hate supporting these jews.

>>60433422
>not flac
>opus
>upsampling to 48khz because retarded codec is retarded
check out this pleb.

File: The.Young.Pope.S01E05.720p.BluRay.X264-REWARD.mkv_snapshot_28.55_[2017.01.25_19.16.31].jpg (131KB, 1280x720px) Image search: [Google]

131KB, 1280x720px

>>60433422
>1000 animes

>>60437768
I know right, we should all have shows about some pedophile organization that encourages people to have 10-20 kids, right?

File: The Martian [BD 1080p] [C80941E1].mkv_snapshot_00.36.12_[2017.05.17_07.47.28].png (3MB, 1920x800px) Image search: [Google]

3MB, 1920x800px

anyway, i downloaded the martian bdmv.
encoded with x264 8bit.
1080p 7.3GB, 7.1 AAC LC q100 + directors commentary.
came out 7.3GB, looking better than scene rips and way smaller.

>>60433384
i hope your source is bdmv.

>>60437894
What CRF?

>>60437894
you can google for, The Martian [BD 1080p] [C80941E1], all you want.
you won't find it on the internet.
:^)

>>60437956
can't remember. can't find it in my bat file. might be 18 to 20. i don't go higher unless for max compression.

Format profile                           : High@L5
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 8 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 2 h 31 min
Bit rate                                 : 5 921 kb/s
Width                                    : 1 920 pixels
Height                                   : 800 pixels
Display aspect ratio                     : 2.40:1
Frame rate mode                          : Constant
Frame rate                               : 23.976 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.161
Stream size                              : 6.26 GiB (86%)
Writing library                          : x264 core 148 r2721kMod 72d53ab
Encoding settings                        : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.64 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=1200 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.08
Language                                 : English
Default                                  : Yes
Forced                                   : No

What exactly do I need to git gud at encoding? I don't want to be like that coalgirl retard that uses low CRF values for all releases.

File: The Martian [BD 1080p] [C80941E1].mkv_snapshot_01.07.09_[2017.05.17_08.09.00].png (3MB, 1920x800px) Image search: [Google]

3MB, 1920x800px

>>60438135

>>60438161
nothing.
encoder settings is irrelevant.
you can get great results with the presets.
more importantly is the avisynth filter chain.
unless it's kyoanus or khara, you will need some post processing because nips and their retarded choice.
for kyoanus, i just removegrain() to gain a little compressibility with no penalty and gradfun3() for good measure.

for fucked up scaling, anti aliasing with maa2().

for shows with fucked up contrast boost, ylevels to flatten it up and aggressive debanding. lossy source will band. with planetes, it's either dark space or washout space and banding. the choice was clear.

for upscaling shit.
nnedi3_rpow2, lsfmod, awarp4.

Which videoplayer should I use for anime?
I used vlc previously but I saw anons bash it

>>60438344
Alright, I'll go read up on the differences then. Thanks anon.

>>60437894
>>60438135
NIce job, that is precisely the sweetspot I like when encoding my movies. Care to share that copy with me? :^) I can give you my godzilla with similar size and settings.

>deblock 0:0

I'd just have used film tune which gives -1:-1 deblock and ip ratio of 1.3 for further improving the overall quality, but overall your settings are good.

>came out 7.3GB, looking better than scene rips and way smaller.

That because scene rippers are shit. They use default settings, profile 4.1 and medium or fast encoding presets. I usually encode around 7gb exactly like you didn and it end looking better than 12~14gb encodes of large scene groups.

>>60438161
Don't be lazy and use very slow preset with tune for grainy sources and default for flat digital animation.

Some further tweaking may be useful, specially at PSY RD and AQ, but that is advanced level shit.
What is more important is like the other anon said, learn some basic scripts in avisynth, but I wouldn't follow all his recommendations, tough.


>>60438344
>removegrain()
Removegrain is fairly inneficient, use SMDegrain with tr=1 which is much higher quality and not abismally slow.

I don't recommend using ylevels or automatic luma range correction, it usually clips and chursh blacks more than it fixes anything. Either fix exposure manually scene by scene, prefereably with Histogram or RGB parade to make sure you are not clipping this up or don't touch luma at all.

>>60439426
>with tune for grainy sources
I meant, with film tune for grainy sources.

Don't use the grain tune. That is too specific for very noisy oldschool filmes, or very high iso (like 16000) digital camera capture at night with very high bitrate settings.

>>60439426
>Either fix exposure manually scene by scene, prefereably with Histogram or RGB parade to make sure you are not clipping this up or don't touch luma at all.
haha.
no.
too much effort.
shows like relife are overcooked all around. so it's fine. they obviously boosted contrast of the final video rather during production. the wrong decision.

removegrain is fast as fuck.
the frames are basically identical to the naked eye but smaller when compressed. that's why i slap it on.
honestly, i haven't tried smdegrain, can't be bothered to try everything.

awarp4 is the magick filter.
just saiyan.

>>60439378
godzilla was boring as fuck.
anno fucked up as usual.
eva 4 is confirmed for shit.

>>60439968
>the frames are basically identical to the naked eye
No, they're blurred. It's a very dumb filter.

>>60430520
UHDBlurays can go to 72mbps. At least that Smurfs 2 copy was.

Does 264 supports HDR?

>>60440226
Not BT2020, but since it supports 10 bit, it can be hacked with the full range of HDR IIRC.

>>60440065
This.

Even HQDN3D which is fast as fuck do a better job than removegrain. But I wouldn't use it either for anything decent archival quality either.

File: Screenshot 04.png (601KB, 1280x736px) Image search: [Google]

601KB, 1280x736px

I like it, whole Naruto Shippuden 720p, 500 episodes in just 50gb.
Gray/darks tend to shit themselves though.

File: 1.png (843KB, 1280x720px) Image search: [Google]

843KB, 1280x720px

Like this.

>>60440352
Apparently H.264 does support rec2020 (bt2020).

https://en.wikipedia.org/wiki/Rec._2020#Implementations

Every day I wake up and wish HEVC will become the new standard for chink cartoon encodes so we can finally be free of the x264 10-bit meme.

File: Screenshot 10.png (400KB, 1280x736px) Image search: [Google]

400KB, 1280x736px

>>60440427
This one looks awful.

>>60440412
>>60440427
>>60440656
>Naruto

>>60440673
>tfw Naruto is older than most people who browse 4chan and probably including you.

>>60440722
Nah, I'm on mid 20s. That shit came out maybe 20 years ago.

>>60440753
It aired for like 16 years, so people who started watching when they were like 13(which seems to be the age most people get into anime) are now almost 30.

Really makes you think doesn't it.

>>60438520
If on windows, MPC-BE.
Otherwise, mpv, I guess.

>>60440933
>MPC-BE
what's BE? I only know HC

>>60441002
Black Edition.

>>60415020
>libvpx based