[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y ] [Search | Free Show | Home]

I'm encoding a video from raw to H265 10-bit, its taking

This is a blue board which means that it's for everybody (Safe For Work content only). If you see any adult content, please report it.

Thread replies: 187
Thread images: 22

File: Untitled.png (81KB, 1015x675px) Image search: [Google]
Untitled.png
81KB, 1015x675px
I'm encoding a video from raw to H265 10-bit, its taking ages and is going to take 40 hours to encode a 4min video file. Using my 4790k, what is the best processor I can use to encode at a much much faster rate?
>>
>>62365127
1950X
Also stop encoding in 10bit you mongoloid
>>
>>62365276
Nope, encoding in 10-bit allows me to increase the RF value futher and thus lowering the file size
>>
>>62365296
t. Retarded placebofaggot
Fuck off Daiz
>>
Threadripper or buy more 4790K and some glue
>>
>>62365336
You don't seem to like my opinion, but remember what you learnt in your English class, an opinion is neither right nor wrong.
>>
>>62365401
No daiz, you're just a cunt. Kys
>>
>>62365401
Stop ruining anime pls
>>
>4 core mainstream cpu
>h265 10-bit
>custom windows theme
>handbrake

top fucking kek you retard
>>
>>62365336
>>62365433
And here you have a prime example of what is called a "brainlet".

Someone who holds an opinion and defends it almost religiously, but has no actual facts or logic behind his religious belief, so rather than responding with logical arguments, he responds with insults and bile.
>>
File: diff-presets.png (8KB, 924x493px) Image search: [Google]
diff-presets.png
8KB, 924x493px
>>62365127
>placebo
>>
>>62365508
This chart is presenting the speeds, I don't understand what else you are trying to say
>>
>>62365528
nothing, i'm telling you that you should expect it to go slow as shit on 'placebo'
>>
What's the source file?

Why are you using x265 anyway? x264 might be larger file size, but the quality is better, and it's faster to encode.
>>
>>62365276
>Also stop encoding in 10bit you mongoloid

He's using H265, so no one will be able to watch it anyway.
>>
>>62365543
Because I can have better compression efficency, lower filesize while having the same quality as an 264 encode
>>
File: 1503853016627.jpg (56KB, 645x773px) Image search: [Google]
1503853016627.jpg
56KB, 645x773px
>>62365474
>t. Projecting brainlet
>>
>>62365554
You can watch it but you just need a good cpu and gpu to decode the video
>>
>>62365557
>same quality as an 264 encode
yeah, no
stop dreaming
>>
>>62365557
h265 doesn't add much when making high quality output, it's strength is watchable low quality video
it's usually not worth it for high quality video
>>
>>62365557
>same quality of 264 encode

Nope, 264 is STILL better quality than 265, even at similar bitrate.
>>
>>62365127

You're doing placebo preset you idiot. Go with Slow.
>>
>>62365572
The CPU he has can do 4K H265 10bit at a decent bitrate
>>
>>62365586
No way, if you google it you'll know thats ain't true. Give me a source. If you get a RAW file that is like 400GB large and use the same bitrate that is low, for h265 and h264 you'll see that the h264 looks worse
>>
>>62365609
ehhhh, idk about decent bitrate. Maybe 50mbps. But true 4k 10bit bluray bitrate is 100-140mbps.
>>
>>62365623
Fuck off kid, you have no idea what you're talking about if you're trying to pretend x265 looks better than x264.

x264 is used for quality, x265 is used for small file sizes, especially for streaming content or similar low bitrate delivery.
>>
>>62365127
It's not the processor, you just don't know what you're fucking doing.

Download the latest stable staxrip: https://github.com/stax76/staxrip/releases

Download the latest 10-bit x265 encoder: builds.x265

Replace the stock x265 in the staxrip directory and replace it with the newest one and rename it back to "x265"

Use the following settings for video: CRF 22, faster preset

And for Audio: 128 vbr Opus

Let it RIP!
>>
>>62365649
>faster preset
No I want placebo because it allows for better quality at a higher CF value
>>
File: crowd_run-PSNR.png (19KB, 1172x506px) Image search: [Google]
crowd_run-PSNR.png
19KB, 1172x506px
Also pic related is why you never use anything slower than the faster preset OP
>>
>>62365643
Provide a source, x265 have better compression effciency than x264. There's a reason why it has better quality at the same bitrate mate
>>
>>62365681
That's not how it works dumbo. Both faster and placebo presets will get you the same quality (look up what CRF does). The only difference is placebo will shave like 5% off the total file size.
>>
File: a.png (110KB, 1024x752px) Image search: [Google]
a.png
110KB, 1024x752px
>>62365649
>faster preset
man, i hope you're joking
>>
>>62365691
Except it doesn't



Like we've been telling you.

x265 is fine for low bitrate files. But at high bitrate the x264 either looks identical or even better.

>I’d say, if you can stand some quality degradation, then x265 might be the way to go, as it can give you much smaller file sizes at lower bitrates with slight degradation.

>If you’re aiming for high bitrates and quality, it might not be worth it right now, at least for 1080p.

http://wp.xin.at/archives/3465/comment-page-1
>>
>>62365695
Okay firstly I compared a very fast to placebo at CRF 30. The placebo video file was much much clearer like day and night, the very fast present looked like shit with noise all over the place. Wish I kept my tested video files so I could show you
>>
Just wait. By the time you're finished AV1 encoders will reach maturity and you will have something else to waste time on.
>>
>>62365643
>>62365623
>H265 looks better than 264 at small file sizes
>No you kid retard, 265 is better at small file sizes
Agreement looks so cute.
>>
>>62365728
Its for a RAW 4k avi video file, a 4min file that is around 400GB large
>>
>>62365744
So it's so fucking high bitrate you 100% should be using x264.


God damn retards.
>>
>>62365749
Alright fine I'll do a comparision at a high birate and prove you wrong retard. The h256 will look obviously better in the end
>>
>>62365724
Compare actual file sizes. In the end the placebo just shaved ~5% off a 1 hour episode for me.

>>62365729
Now compare faster to placebo. Of course using anything faster than faster will look like shit no matter what.

You're still using hex motion estimation in very fast.
>>
>>62365127
> what is the best processor I can use to encode at a much much faster rate?
You may not believe it, but it's Ryzen and Threadripper. Maybe a server motherboard with a bunch of Chinese Xeons.
Also I am unsure of how much cores are used by Handbrake.
>>
>>62365765
Good luck with that kiddo.

I've got 15TB of my own encoded content that i've done with my 5820k.


if you had an FTP with 1gbps I'd tell you to host your shitty 400gb file and i'd do it for you. punk ass.
>>
>>62365769
>Compare actual file sizes. In the end the placebo just shaved ~5% off a 1 hour episode for me.
that graph is at a constant bitrate, the file sizes are all the same
>>
>>62365769
My point still stands that going for placebo gives higher quiality video file
>>
>>62365788
Okay well I did 2 CRF 22 encodes. One with the faster preset and one with the slow preset. Both LITERALLY looked the same and all I saved was about 5 MB off 140 MB for 1 hour of video.
>>
>>62365296
> (BTW, h.265 gets less benefit from 10-bit encodes for 8-bit video because it already has more precision for motion vectors. If there is a benefit to using 10-bit x265 for 8-bit video inputs, it's smaller than with x264. So it's less likely that the speed penalty will be worth it.)

source: https://video.stackexchange.com/questions/14656/why-processor-is-better-for-encoding-than-gpu
>>
Just a last thing to add, if you want the best video quality video you should always use only 1 core 1 thread due to the way H264 and H265 is being encoded
>>
>>62365828
they should look about the same, as you used CRF, that's the point of CRF
if you're doing 140MB encodes of hour long videos, you'll probably want to stick with x265, because unless that's super low resolution, that counts as low quality video, h265's strength
>>
>>62365814
No, it doesn't at least compared to the faster preset.

Are you also gonna tell me the placebo preset gives better quality at 0 CRF?
>>
>>62365836
>it's smaller than with x264
Yeah and thats why I'm using 10-bit, same quality with 8-bit but lower filesize
>>
>>62365859
it does when using a constant bitrate
>>
>>62365870
But the time it takes is not worth it. You're literally spending $5-10 on electricity for this bullshit placebo.
>>
>>62365853
It was a 720p rip of a well known tv series. And it looked just fine on my 1080p 24" monitor.
>>
>>62365859
Placebo will always give better quality looking video file than all other presents because it is more efficent when making use of the bitrate
>>
>>62365877
Well we're talking about CRF lad. Why in god's name would you ever use a constant bitrate?
>>
>>62365879
>clearly lower filesize
Psssh I can't see the differences in numbers
>>
OP, I recommend GCE or Amazon. As many cores as you can afford.

You might as well go full out if you're going to insist on using placebo.
>>
>>62365908
wew, so you're just retarded.

You don't care that it's an insignificant amount of file size difference, you just care because x265 is "better" and you of course NEED the "best"
>>
>>62365890
Yes but CRF mode accounts for that M90

My point is a 1 hour video encoded with CRF 22, faster preset and CRF 22, placebo preset will both look visually the same. Try it out and stop being so god dammed ignorant and spend weeks instead of hours encoding shit for a meager 5% reduced overall file size.
>>
>>62365923
>insignificant
thats subjective, and doesn't everyone want the best if they can get it?
>>
>>62365946

Best isn't always better in the end.
>>
>>62365942
>visually the same
not if you look closley, compare them in photoshop and you'll see the the faster present contains more noise. Okay if you want to see more clearly do CRF 50 at faster and placebo, now you will see faster looks like grandshit while placebo looks clean and nice still
>>
>>62365977
no one is comparing frames in photoshop.

You're making more work for yourself because you're being retarded.
>>
File: a.png (78KB, 1256x924px) Image search: [Google]
a.png
78KB, 1256x924px
i was suckered into h265 as well, was pretty impressed by how well it could hold together very low bitrate encodes, but i soon found out that this doesn't scale linearly with higher bitrate encodes
when doing high quality encodes, h265 has little advantage, and to get that advantage, you're going to have to spend a lot more time encoding compared to x264

so then answer? use both. x264 for high quality archival/masters/etc, and x265 for things like internet streaming, where low rates are more important than high quality
>>
>>62365977
It won't. If what you say is true than CRF has failed to use the proper QP which unless you're using the first x265 encoder is fucking impossible.
>>
>>62366023
The graph still shows that x265 contains a higher quality than x264 still at both lower and higher bitrates. If you can show a graph that goes up to 20000 kbps
>>
>>62366059
you're right, the problem is that x265 takes several times longer to get that result, unless you use faster presets, which throws away that small advantage
>>
>>62366091
Well I guess that guy who said x264 has higher quality at higher bitrate than x265 is wrong then
>>
>>62366112
>i'm technically correct despite the fact no one would ever actually use x265 in the way i'm describing because the time it takes, the lack of discernible benefit, and complete and the increased requirements for playback.


tldr; you're a retard. Go LARP somewhere else.
>>
>>62366133
yup, just the way you noggins like to act when someone is correct you change from talking about you being right to "lol no one would do that anyways even though you proved me wrong"
>>
>>62366112
perhaps, though at the time time, objective tests like SSIM aren't perfect, human vision is a complex thing, and slightly lower SSIM might not always mean humans will judge that result to look better
being technically closer to the source overall isn't always a perfect measurement, it can't account for things like annoying motion errors which humans are sensitive to, but aren't 'seen' by objective, still-frame comparisons
>>
>>62366149
Reported for troll thread
>>
>>62366160
Don't have time for making troll threads, I'm actually busy making money off my day-trading off crypto actually. People here just wasting my time, giving false information and then posting graphs and quotes that proves that they are wrong, its like they're retards when they can't look at the technical side of things, better means better not better means worse
>>
>>62366192
The problem is you're being disingenuous on purpose. You already know exactly why it's taking so long, you set it for the most retarded settings possible.

You know exactly why it's taking so long, and you know exactly how to do something about it, you're choosing not to because of Muh autism.


You're technically correct to the point it's obvious this entire thread was just an excuse for you to interact with people online.


I fucking hate scum like you, go back to LARPing about your shitty "day trading" and pretending you'll ever actually make money.
>>
>>62366240
Ye. The only presets worth using are the faster or ultrafast (streaming).
>>
>>62365127
RX VEGA 64 water cooled in crossfire using compute acceleration.
>>
>>62366192
if you want to spend several times longer making something only slightly smaller, that's your choice

i personally couldn't get x265 to perform how i wanted for my preferred quality level, it tends to smooth things out a bit too agressively, and by the time i managed to tweak to to about the same appearance as x264, the bitrates were no better than x264

now, for things where i'm not fussed about small detail, x265 is great, it can make stupidly low bitrates watchable, but they don't look nearly as good as the source
>>
>>62366240
No, not for real. He hasen't shown the graph that shows the file size, placebo will contain a lower filesize in turn for longer encode
>>
>>62366282
no, the filesizes will be about the same, as that is a CBR encode, not a CRF encode
>>
>>62366282
see >>62365828

The only reason I can see the placebo preset being remotely worth it is encoding huge tv serious like House MD.
>>
>>62365127
Nvidia 1000 series can hw encode 10-bit hevc, get 1050ti or something
>>
>>62366296
hardware encode is fixed settings and is never actually used in practice for anything but streaming.
>>
>>62366296
I am talking about the presents not CRF retard. Also CRF value will be the most biggest factor of the file size
>>
>>62366312
>is encoding huge tv serious like House MD.
why?
>>
>>62366331
meant for
>>62366313
>>
>>62366312
NO IT DIDNT LITERALLY LOOKED THE SAME, go into photoshop and compare, did they look literally the same? IMPOSSIBLE, you don't know what literally means, GOD DAMN THESE DUMB SHITS ARE SHITTY UP MY THREADS. THE PIXELS ARE DIFFERENT COLOURS SO NOT ITS NOT LIERALLY THE SAME
>>
>>62366333
CBR encodes will by definition be the same size regardless of preset
>>
>>62366353
>go into photoshop and compare
holy shit...its a retard.

Are you watching a movie in photoshop?

Fucking kill yourself already.
>>
>>62366336
Because then that 5% will start to shine.

Instead of the total file size being say 1000 GB it will only be 950GB.
>>
>>62366360
No its the fact that this line "Both LITERALLY looked the same" is LITERALLY incorrect
>>
>>62366353
>watching movies frame by frame at 400% zoom in photoshop
Are you mentally and physically retarded?
>>
>>62366361
>Because then that 5% will start to shine.
no, it'll still be 5%, regardless of how much video you're encoding
>>
>>62366338
I use it frequently myself, it's perfectly adequate for personal use.
>>
>>62366379
But they do look identical when watched at normal framerates.


Comparing in photoshop is retarded and we all know it.
>>
>>62366379
While playing the fucking video at 100% zoom and 1X speed yes they LITERALLY will fucking look the same to your eyeballs you fucking downy.
>>
>>62366392
Not if you care at all about how your encodes look.

CPU encoding with software is ALWAYS the method used unless you're just a retard or uploading to youtube where higher bitrate wouldnt matter.
>>
>>62366395
NOT IT WONT, they won't look literally the same, its just you YOUSERLF interpreting as its the same. So no, my statement stands true.
>>
>>62366386
No shit, but 5% of 1000 GB is 50GB, that's a lot. Though in most 1GB encodes it will reduce the file size by 50MB which is honestly not that much desu senpai.
>>
>>62366414
Just so you're aware, we are ALL laughing at you here.
I'm sure even some lurkers are getting a chuckle out of this shit show.
>>
>>62366414
Jesus christ man, just stop posting. Now you're just engaging in maximum damage control at this point. It's cringeworthy at best.
>>
>>62366402
Always used by meme animu encoders you mean.
>>
>>62366427
Yes while you're all laughing at me I am making money by sitting my ass all day and sleeping doing investments online while you shitheads work 9-5 looking like crackheads in the morning. I find it very funny how you can laugh when you're in that state
>>
>>62365276
10bit with HEVC is pretty normal, they even tried to make it the smallest value possible in the beginning. You can still do 8bit now though and go above 10 in most cases.
HEVC 10bit hardware decoding is a thing like it was for 8bit h264.

>>62365554
Are you running an ancient toaster or what?
Hardware decoding exists on all non-shitty phones of the last few years. My father's iPad could software decode it with VLC without any issues and my Broadwell mobile i5 can do as well. It's really not a big deal unless you go 4K 60fps where it's pretty much impossible without hwdec.

>>62365127
x265 or whatever this is using is unoptimized and slow as fuck. You can't compare it to x264 which was optimized for more than a decade.
It will improve but this will take time.
>>
>>62366465
As someone who does encoding for animebytes on occasion, fuck off you moron.

Maybe on shitty public trackers, but actual anime encodes are done just like everything else, with software and a CPU, not hardware encoders.
>>
>>62366416
it's literally the same thing
saying "50GB of 1000GB" is "a lot", while also saying "50MB of 1GB" is "not much" is nonsense, as they're both exactly 5%
why am i even replying to you, fuck.
>>
File: download.png (1KB, 259x194px) Image search: [Google]
download.png
1KB, 259x194px
>>62366465
That slowly kills me inside man. Fucking shit.
>>
>>62366434
>maximum damage control
You don't know what damage control acttually means, I am literally beating you all down while you guys try to lie to my face with false facts.
>>
>>62366479
You okay man?

>>62366486
lol
>>
>>62366486
yeah, having to keep telling us about your amazing day trading skillz sure does make you seem like you're "winning".

Face it, your life sucks, you make no money day trading, and you probably still live at home because you can't afford your own place.
>>
>source is 8-bit
>encode to 10-bit
Facking hell.
>>
>>62366492
>lol
is all you have now, reduced you to fucking ashes. I win, stop talking now you're destroy my thread
>>
>>62366492
>You okay man?
let me rephrase what you said;
my guess is that you're thinking "50GB is pretty significant compared to 50MB", which is true
you know what else is significant? 1000GB vs. 1GB.
so then, which is more significant? neither. the relative difference between the two examples you gave is nil.
>>
>>62366506
>Spewing lies like everyone else in this thread
Guess you're one of them too then
>>
>>62366508
RTFM

http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf
>>
>>62366477
>As someone who does encoding for animebytes
You are in no position to insult other people.
>>
>>62366059
keep in mind, this is with x265 and x264 both at 'veryslow' preset
for x264, veryslow, with modern cpus, it's quite feasable to use
with x265, veryslow is slow as all fuck, and hardly usable at all, unless you're doing 1 minute clips or have a cluster of machines to work with
>>
>>62366647
Why? I'm not doing some bullshit placebo 40GB encode for a single season of anime like some of the retards on AB.
>>
>>62366649
I already know that, you're compremising time for quality which is fine by me, I want quality
>>
>>62366666
enjoy your 0.1 fps, then, penta-satan
>>
>>62366666
>which is fine by me
and yet this entire thread is started by
>encoding a video from raw to H265 10-bit, its taking ages and is going to take 40 hours to encode a 4min video

so which fucking is it? Are you okay with the extra time and therefore this entire thread is pointless. Or you're not okay with how long it takes and you're a retard for refusing to change your encode settings.

In either case this thread has run it's course. You have your answers.
>>
>>62366666
then you should be using veryslow, not placebo
placebo is often very slightly worse in quality compared to veryslow, i don't know why they even have that option, maybe so they can spot newcomers in forums
>>
>>62366023
This doesn't represent the latest x265 encoder.

day 1 x265 encoder was only 20% more efficient
year 2 x265 encoder was only 35% more efficient
today it's at least 50% more efficient
>>
>>62366686
>>62366706
This is why I asked for a RECOMMENDED CPU, but a bunch of faggots came to make a shit show.
>>62366721
>slightly worse
It really doesn't, placebo is always the best expect it requires more time
>>
>>62366749
>This is why I asked for a RECOMMENDED CPU, but a bunch of faggots came to make a shit show.
i recommend a cpu made 10 years from now
>>
>>62366749
You got a recommended CPU on the first post.
Go away now.
>>
>>62366779
My thread, I can stay as long as I like. Stop making useless posts like these please
>>
>>62366601
>http://x264.nl/x264/10bit_02-ateme-10bit_kills_hardware_compatibility_never_use_it.pdf
>>
>127 posts
>23 posters
>this thread is one of the worst on /g/ right now
really activates my almonds
>>
>>62366833
>404
>>
>>62366833
Ohhhhhh, you fucking cum drizzle. I hope your cock rots off.

Anyway hardware decode only matters on phones but even $200 chink phones with snapdragon 820 and up have 10-bit HEVC hw decoding so your argument is null.
>>
>>62365127
For your autistic and placebo need, you'll need at the very least a Ryzen 1700. Threadripper is recommended for such heavy workload.

Otherwise, compromise in more rational settings and a better encoder.

Now fuck off.
>>
>>62366725
sure, at low bitrates/quality, and with much more time spent encoding
it's not as simple as saying "you'll get 50% savings, so use x265 for everything"
i really wish it were
>>
>>62366833
that's for h264, keep in mind 10bit h264 is pretty non-standard, but 10bit h265 IS standard, it's far more common for h265 decoders to support 10bit than h264 decoders
>>
>>62366925
But it is
>>
>>62366981
... you don't actually believe that...right?

I mean, no one is this dumb.
>>
>>62366925
I guess but I don't see the point in storing CRF 10 HEVC 4:4:4 encodes for archival purposes when humans can't tell that and CRF 22 HEVC 4:2:0 encodes apart at 100% zoom and 1x speed.
>>
>>62367002
some people got good eyes
>>
>>62366981
it's not
if i'm making a low quality encode that takes several times longer to make, then i'll get the most out of x265
but if i'm making a high quality encode, i'll only get a marginal improvement, still several times slower

and if i don't want to spend much more time on it, x265 struggles to be advantageous with anything but the lowest quality encodes

i only get ~6fps doing high quality, veryslow 720p x264 encodes on my overclocked fx8320, this i can deal with, but if i'm to move to a codec several times slower, i want a worthwhile difference in efficiency, which i simply do not get with x265
>>
>>62367048
Hmmm, are you that guy that believes 96Khz 32-bit audio sounds superior to 20Khz 320k MP3 audio?
>>
>>62367112
It's a bigger number, obviously it's better, regardless of if anyone would actually be able to tell, it's still better.
>>
>>62367112
Contains more information = Better
You already answered your question
>>
>>62367123
Gotta love purified autism.
>>
>>62367002
>"just make lower quality encodes then"
where it makes sense, i will
like last year i made a set of dvd-r's with a very large (>100 episodes) show on them to give to an overseas friend with scarce internet access, i used x265 for that, as i could get away with less discs while still making watchable video, low as fuck quality, but watchable
>>
>>62367142
At that point you should've just used a bluray, or BDXL.
>>
>>62367157
1. i don't own a bluray drive, never have
2. he doesn't either
if we did, then sure, assuming the discs needed didn't cost much more (i haven't looked into bd-r costs, as i have had no reason to)
>>
>this thread
>>
>>62366013
the fuck? Anyone who is offering himself up for a position that requires video encoding should do this. Doing these sorts of comparisons is what sets apart the "self proclaimed videographer and director" from people actually working in the industry. If you are delivering a video that cost several thousand if not tens of thousands of $$ you better know your fucking video codecs in/out
>>
>>62367157
>>62367182
ps. i didn't use the biggest dvd's, either, for that matter
i used plain single layer 4.7GB discs, i could have halved the count with 8.5GB discs, but;
a. i had a bunch of 4.7GB discs on hand
b. while i haven't checked in some time, last i did check, they cost more than twice as much, making them less cost-effective per GB
call it penny-pinching if you like, i got the set down to 8 discs, which is fine, no reason to go out of my way to reduce it more in this instance
>>
File: 01f.jpg (335KB, 676x485px) Image search: [Google]
01f.jpg
335KB, 676x485px
>>62367223
>>
>>62367274
oh, you were just pretending this whole time?
>>
at least we could attest that threads with high replies/poster ratios are objectively shittier
>>
>>62367302
past maybe the 50 posts mark, yea
several times i've had threads where it's basically just me and op where i guide him through a problem and no shitposts at all
though those usually only get maybe 10-30 posts and there's nothing left to discuss
>>
>>62365474
>rather than responding with logical arguments, he responds with insults and bile
>brainlet
Funny how hypocrisy ruins any point you would've had.
>>
>>62367355
threads with objective conversations and no shitposts are so damn rare, but so damn good

I wish we had more of these
>>
This thread didn't need to get to this point but people just don't understand.
>>
File: 6f3acaa83433e4049a404ffd5e877c16.jpg (217KB, 682x1000px) Image search: [Google]
6f3acaa83433e4049a404ffd5e877c16.jpg
217KB, 682x1000px
>>62367377
yea, though at the same time, the fact that there's so much more shit than good just makes the good ones seem even better
>>
File: graph.png (4KB, 340x150px) Image search: [Google]
graph.png
4KB, 340x150px
>>62367392
Not only that but 4chan is now officially TOO popular.

https://www.alexa.com/siteinfo/4chan.org
>>
>>62367392
it's a complicated subject (both in the number of things to understand and learn, and also in the number of variables when it comes to any particular set of requirements and circumstances), and it involves a strong element of subjectivity (quality, can't have too much quality, but exactly how much is not enough?)
>>
File: s.png (243KB, 636x421px) Image search: [Google]
s.png
243KB, 636x421px
Is this audio quality good?
>>
>>62367685
No. That is a re-encode from a 256-320 kbps mp3 or something like that.
>>
>>62365127
>encode to 10bit hevc
you absolute donkey
>>
File: 12_banding-1.png (10KB, 392x202px) Image search: [Google]
12_banding-1.png
10KB, 392x202px
>>62367758
This. Color banding is beautiful. Who vape and listen to vaporware here? XDddd---;
>>
>>62367800
but is your source material also 10bit or 8bit or drillbit you donkeyboner
>>
>>62367838
pass the video through a debanding filter before encoding it
>>
>>62367838
see
>>62366601
>>
>>62367800
that picture is bullshit.
>>
>>62367928
Nope, it's 100% true. 10-bit encoders get 1024 levels of accuracy for each RGB value and 8-bit encoders get 256 levels of accuracy for each RGB value.

Because x265 creates artifacts due to lossy compression a higher color selection increases precision of the original color significantly.
>>
File: nalle.png (2MB, 1280x720px) Image search: [Google]
nalle.png
2MB, 1280x720px
>>62367887
"save bandwidth"
isn't you encoding to playback offline?
is you streaming 10bit video pornography why should you care about bandwidth?
also how about that playback hardware compatibility?
>>
>>62367958
But that's not what the picture shows.

It takes a section from slightly darker green to slightly lighter green. (say, 40% to 60% or thereabout)
And then it CHANGES those colors so now it's suddenly black to 100% green???

>black to light green in 7 steps will show banding
no shit, Sherlock.
But 8 bit isn't 7 steps, it's 256.

Hell the section it samples isn't even 7 levels.
It's way more than that.

This is also ignoring the fact that most screens can't even show 10 bit.

10bit is useful for post processing.
My camera even shoots in 14bit which is awesome.
But as an output format it's pretty much pointless.
>>
>>62368036
It means file sizes are reduced by 5-20% by using a 10-bit encoder alone but in addition to that little to no color banding will be present across all bitrates.

Also SD 420 phones have 10-bit hevc hw decoding and can be had for as low as $200.
>>
>>62368036
>playback hardware compatibility
>what are software decoders

Oh right I forgot you lot are mostly phoneposters.
>>
ryzen because handbrakes actually uses multi threading to encode shit
bet you are kicking yourself for not getting on the ryzen hype now eh intel fag btfo
>>
>>62368059
>This is also ignoring the fact that most screens can't even show 10 bit.
The screen can be 8-bit. The reduced-no color banding will still be very noticeable.

See
>>62366601
>>
>>62368078
handbrake is still trash for encoding

staxrip till the day I die
>>
File: vlcsnap-4742-12-27-10h59m15s566.png (442KB, 712x540px) Image search: [Google]
vlcsnap-4742-12-27-10h59m15s566.png
442KB, 712x540px
>>62368067
>phones
>>62368073
hardware accelerated h264 is the tits, mane
u watch on laptop 'n' shit, the playback goes on like forever
play meme format like hevc or 10bit titrot.mkv and playback stop in like 5mins

pic related, is space ghost in glorious 8bit x264
>>
File: vlcsnap (2).png (432KB, 720x540px) Image search: [Google]
vlcsnap (2).png
432KB, 720x540px
>>62368093
what settings to ensure banding? tune animation and grain b4 avisynth sharpening?

pic related, is harvey birdman in glorious 8bit x264
>>
>>62368112
We've had 10-bit hevc hw decoding for a while on laptops now m8.

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
>>
>>62368112
>>62368165
fuck off with your children's cartoons, go watch game of thrones like an adult
>>
>>62368112
>>62368165
You may want to encode a gif to show the grain movement.
>>
>>62368239
>intel
>>62368250
tsing-tsong say u no get of succ if u watch incesto porno on hbo family channl
>>
File: turri666.png (2MB, 1280x720px) Image search: [Google]
turri666.png
2MB, 1280x720px
>>62368315
>encode a gif
dunno how
sucks 4 me 'n' u 2
>>
>>62368320
Are you even 18 years old?
>>
File: nalle gets the succ.png (1MB, 1280x720px) Image search: [Google]
nalle gets the succ.png
1MB, 1280x720px
>>62368386
sí senõr
i've also a big peñor
>>
>>62368320
Wait for raven ridge then you mong. Intel with their "HD" graphics is trash on laptops anyway desu.
>>
File: Hopeanuoli - Vol. 1.mkv.png (712KB, 690x566px) Image search: [Google]
Hopeanuoli - Vol. 1.mkv.png
712KB, 690x566px
>>62368432
>raven ridge
or bumbag binner
i's not gonna buy new hw just to watch transcoded cartunes with headphones
when i's watching encoded cartunes rite now, with headphones
saves lots of €£$ dinero
>>
File: hysst.png (2MB, 1280x720px) Image search: [Google]
hysst.png
2MB, 1280x720px
>>62368105
>staxrip till the day I die
don't let them know
>>
>>62366200
Satania Dropout was a good show
Thread posts: 187
Thread images: 22


[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y] [Search | Top | Home]

I'm aware that Imgur.com will stop allowing adult images since 15th of May. I'm taking actions to backup as much data as possible.
Read more on this topic here - https://archived.moe/talk/thread/1694/


If you need a post removed click on it's [Report] button and follow the instruction.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com.
If you like this website please support us by donating with Bitcoins at 16mKtbZiwW52BLkibtCr8jUg2KVUMTxVQ5
All trademarks and copyrights on this page are owned by their respective parties.
Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
This is a 4chan archive - all of the content originated from that site.
This means that RandomArchive shows their content, archived.
If you need information for a Poster - contact them.