will this meme codec die already?

>>61393005
AV1 will kill it.

Dont know if UHD BD will adopt it, but streaming services are already onboard to switch. MPEG-LA can go fuck itself with its ludicrous licensing fees.

>>61393005
Why?

All major companies are supporting it and it is a good replacement for H264.

No one gives a shit about "Open Source Codecs".

>>61394421
No it won't dummy.

All BD's now use H264, even though it had support for VC1 or whatever the Microshit version was called.

People don't get it, no one cares about open source shit.

Licensed codecs have better support in general.

Also Intel supports hardware decoding of HEVC and so do iPhone A-Series ARM processors.

>>61393005
How can it die if it was never alive to begin with?

Will H264 10-bit die already?

>>61394456
>No it won't dummy.
>all Intel, AMD, nvidia, ARM and most relevant content providers including netflix and google back it
Do you really think HEVC has a chance? Sure, it might not be entirely replaced but this is a battle HEVC simply cannot win.

>>61394520
>>all Intel, AMD
Dun goof'd

>>61394428
Licensing is retardedly expensive (aka MPEG-LA went full jew mode thinking everyone would accept their bullshit).
Also AV1 already has comparable performance (as in quality per bits) to HEVC. It only needs a (decent) encoder and HW support, and, seeing that many tech giants are supporting it (AMD, NVidia, Intel, Google, Netflix etc), it's only a matter of time.

>>61394590
Who gives a shit, /g/'s opinion doesn't matter.

People said the same thing about MPEG2 and it was the only codec DVDs supported. It was very successful.

H264 is very successful too.
>>61394520
>HEVC
>Having a chance

Lmfao you're an idiot.

It will be THE codec to replace H264. You have no choice, goyim.

File: 4kfuckingcat.jpg (1MB, 3840x2160px) Image search: [Google]

1MB, 3840x2160px

>>61393005
Too late, pleb. It's already been standardized for 4K TV transmission.

>>61394428
>good replacement for H264
stop being delusional, i'd trade that size advantage for better quality all day long

Will certain things die already, sheesh

>>61394520

Broadcast TV uses H265. In Korea all those 4k KPOP videos are H265.

Netflix uses H265.

Apple now uses H265 on iPhones.

Snapdragon/A series apple chips all have H265 decoding.

AV1 is a meme.

H265 won.

>>61394628
>/g/'s opinion doesn't matter
but it isn't /g/ that is trashing hevc. tell me, why would google use their shitty vp9 or vp10 codec on youtube that takes fucking ages to encode instead of hevc, which has better compression and has hardware encoding and decoding support? or why netflix doesn't use hevc, instead going for vp9 (that only is supported on some mobile SoCs)? yeah, licensing.

hevc is twice as costly per device ($0.20 vs $0.10) and caps at the triple (25 million vs 9.75 million) than h.264 avc licensing. this is just retarded.

>>61394733
>netflix uses h265
it uses vp9 on mobile, h.264/avc on desktop.

>>61394769
I don't give a shit desu senpai.

YouTube does support H264, or is forced to, on mobile devices anyway.

>>61394769
>AV1 initial release
>HEVC licensing fees drop to kill it before it gains a foothold
>Some money is better than no money

File: 1499560033941.jpg (192KB, 3921x2539px) Image search: [Google]

192KB, 3921x2539px

>>61393005
>2017
4K x265 video is almost mainstream

>We still have chroma subsampling

It's been almost 40 years, you'd think we'd get proper colors by now. Oh well, at least with 4K we finally get 1080p color resolution.

Jesus christ.

>>61395112
h264 is good though, and at high bitrates it almost matches h265 with the avc profile, the 50% filesize reduction only applies on lower bitrates. also x264 is way better than x265 (and x265 is a godsend compared to the vp9/av1 encoder lol).
h265 could be great too, if mpeg-la weren't retards.

>>61395214
would be pretty funny desu

In Europe there will be HEVC transmissions on TVs...
Here tech companies can't sell TVs without an integrated HEVC decoder by law.
Call it dead

>>61394769

Netflix uses H264 on mobile since every single mobile processor has h264 decoding unlike VP9.

And they use H265/AVC on their 4k streams.

>>61396142
they seem to use vp9 for downloaded episodes (or at least from what i've searched).

>And they use H265/AVC on their 4k streams.
with exclusive playready(tm) and hdcp drm bullshit. also i think most processors would have a hard time sw decoding vp9 real-time at 4k.

>>61395214
>HEVC licensing fees drop to kill it
But AV1 is open and royalty free, so unless HEVC is made free they can't compete.

H.265 survives as the video standard for BD and 4k television.

Our only hope is that google shills AV1 hard enough. Stuff like not allowing hevc uploads to youtube and forcing av1 should help it. Intel and AMD and Nvidia are all already on board with AV1, but apple seems to be pushing hevc as more than a stopgap between 264 and av1.

>>61393005
>>61394421
t.google pajeet

>>61399820
Fuck Apple. They don't have the dominant position they once had to throw their weight around like that. HEVC needs to be died right now.

File: mpv-shot_60fpsvp9.2-test_00:00:22.672-0001.jpg (2MB, 2560x1440px) Image search: [Google]

2MB, 2560x1440px

>>61396429
>i think most processors would have a hard time sw decoding vp9 real-time at 4k

Not really. At peaks, this uses 3/8ths of my 1700x, usually closer to 1/4 (3.9GHz with memory running at 3200Mhz), that's including the overhead of my filter-chain.

>>61393005

It's already dead, it's been available for ~5 years and it has had zero impact on the web, physical media or even pirated content.

h264 is good enough while waiting for royalty free AV1 which in turn is being supported by major web/hardware companies, Google, Microsoft, Netflix, Amazon, Mozilla, Intel, AMD, NVidia, ARM, Broadcom, Cisco, Adobe etc.

HEVC is DEAD

>>61394733

LOL what a retard

>Netflix uses H265.

Netflix also use h264 and VP9, Netflix is also a core member of OAM, the alliance of companies creating AV1 !

>Apple now uses H265 on iPhones.

Which means jack shit, Apple does not deliver content, all the major web content providers, Google, Netflix, Amazon are all working together on AV1.

>Snapdragon/A series apple chips all have H265 decoding.

All the major chipmakers are onboard with AV1 you moron, Intel, AMD, ARM, Broadcom, NVidia, Realtek etc are all members of OAM and are adding AV1 to their hardware.

>H265 won.

It's over for h265, it's already a legacy format.

I get 100% of my pirating needs encoded in HEVC.

Comfy as fuck.

>>61394647
I watch this stupid video in loop everyday.
I work in satellite STB business and I can tell you every major STB chipset vendor embeds HEVC right now.

>>61394733
>H265 won.
>reddit spacing.
Yeah because netflix and and alll other content providers wont switch to the codec that they back and intel, amd, nvidia and arm wont implement hardware support even though they back it too amirte guise?
>>61394628
>HEVC having a chance when all major players back AV1

Daiz
Commie
H.264
H.265
10Bit
HEVC
madVR
MPC-HC
Underwater
Nyaa

>>61401189
No Nigga you don't know what you're doing

>>61396119
Did you just try to memetext without the meme arrows?

>>61394733
Yes.
My phone with snapdragon processor supports native H265 Decoding.
H265 is here to stay.

Pirating in H265 is comfy as fuck.
Who mobile poster here?

File: 1494171315505.jpg (73KB, 425x312px) Image search: [Google]

73KB, 425x312px

>>61401605

>>61394647
>>61394733
>>61395267
>>61396119
>>61396142

The bitstream of AV1 will be frozen Q3 or Q4 of 2017. Before that happened, nobody will (nor can) implement it in hardware.
It's not about "h265 won, therefore no hardware support for av1". HW support is not possible until AV1 is fully defined. It will see hw support once that happened.

i never used this codec. everything comes in x264. h.265 is the mp3pro of video codecs

imagine what beast codecs we would have without all these pantents

H265 10-bit :)

>>61393005
Does H264 can do HDR?

>>61402574
:))

>>61394421
Is there a standalone, freely available, cli encoder or can I encode AV1 with ffmpeg yet? Last time I wanted to try it out, I found no resources. I just did a lot of h.265 losless encoding as a result, coming from lagarith.

And what's the deal with daala?

I use HEVC all the time and I find this thread absolutely ridiculous.

HEVC videos are pretty much the same quality at 60-70% of the file-size. Encoding speeds are fast enough with ffmpeg. Mobile phones got hardware support for it years ago, any MediaTek or Qualcomm SOC that's not ancient has hardware decoding. If you have a newer AMD GPU or Intel CPU and you type VDPAU info then you'll probably see HEVC_MAIN and
HEVC_MAIN_10 which means you've got hardware decoding on your PC too. Do you see VP8 or VP9 in your vdpau output? No, you won't.

>>61394456
>Intel supports hardware decoding of HEVC and so do iPhone A-Series
Its not just the eyephone toy, every single phone and tablet made the last few years supports it.

>>61394590
>many tech giants are supporting it
I personally don't care about "supporting it", whatever that means. I do care about devices actually having support for it. Nothing has AV1 hardware decoding, everything has HEVC hardware decoding. That's the support that matters.

>>61394628
>You have no choice, goyim.
You're right, probably for other reasons.

I've tried encoding in VP8 and VP9. ffmpeg doesn't even manage to do multi-core on that shit. We're not talking twice the encoding time compared to HEVC, it really does take so long to encode even a short kpop music video in VP9 that its not worth bothering. If ffmpeg is suddenly able to encode AV1 faster with higher quality then great. Don't care about it until then.

Would it be insane for all devices to come with an FPGA-like module that can be flashed to handle things like migrating from 1 hardware decoding implementation to another? This seems like it would solve the problem of adoption/support. Even if you couldn't have more than 1 decoder at once you could just flash whichever you encounter the most.

What prevents this, cost, complexity, technical or physical limitations? If it's cost I wonder if it might be owrth it anyway since the alternative is buying new hardware.

File: 1488964704775.jpg (99KB, 640x640px) Image search: [Google]

99KB, 640x640px

>>61404647
>H.265
>lossless

>>61404821
>x265 can encode HEVC bitstreams that are entirely lossless (the reconstructed images are bit-exact to the source images) by using the --lossless option.
Bit exact is good enough for me, as long as I can transcode it later to something else without losing quality.

>>61404844
Nigga what are you doing?

File: inxi-partitions-Screenshot_2017-07-16_11-52-06.png (66KB, 827x172px) Image search: [Google]

66KB, 827x172px

I want AV1 so badly. Can't wait to download all of my shit yet again.

>>61404905
What are you curious about or implying? Try using your words.

>>61404821
https://x265.readthedocs.io/en/default/lossless.html

>>61401189
Nah nigga, just call out Fakku on their bullshit and he will sweep right in.

>>61404942
Why would anyone ever use lossless h264/h265? What's your source?

>>61393005
I transcoded all my porn to it. So I hope not.

>>61404995
>Why would anyone ever use lossless h264/h265?
Why would you not take advantage of losless encoding? That'd be like storing wavs when FLAC is currently fine, not migrating from wavpack to take advantage of the reductions.

>What's your source?
>>61404647
>coming from lagarith
Take a guess, I'll give you a hint (it's Lagarith).

I don't care what codec they use as long as it's not a cpu monopolizing heap of pigshit like vp8/9

>>61405056
>cpu monopolizing heap of pigshit like vp8/9
To be fair HEVC is also extremely CPU-intensive. This doesn't matter because everything's got hardware decoding, all phones have it and so do PC's that got a newer Intel CPU or a AMD or Nvidia GPU. 1080p HEVC was barely playable on my old CPU/GPU system.

>>61405041
Yeah but lossless encoding requires a lossless source and I have no idea where I would even find lossless video. That's why I asked what kind of source you were using.

>>61405159
I'm not gathering lossless video, I'm producing it then encoding it to save space, I imagine that's what most people do for archives. It would get out of hand fast if I stuck with the raw video and pcm audio. I transcode it from losless to whatever the target can handle, usually h.264/aac in an mp4 but the resolution might change depending on devices.

>>61405189
I still don't understand. Why would you make a lossless copy and then encode it instead of directly encoding from the source?

>>61405280
Output support and real time concerns. Almost everything supports raw output, not everything supports *hottest new meme format of the year* output support. Even if they do, can they sustain encoding it at the same rate as just a raw dump?

Most importantly, reliability. Raw is raw, you have 100% of the information 100% of the time, if something fucks up, you lose only what you lost and can recover everything else, if an encoded chunk gets fucked, enjoy all kinds of mysterious hard to triage problems with your archival copy.

>>61404801
That's not how FPGAs work. You cannot program it to be x86 and excel at x86, then reprogram it to amd64 and have great amd64, to later reprogram it to arm and have top tier ARM. They allow you to emulate hardware, but at performance cost. The other costs are also not small, shit's not only expensive to make, but also power hungry.

>>61405159
>lossless encoding requires a lossless source
Incorrect. By encoding lossy stuff with lossless codec, you get benefits of the other codec, while not compromising the quality of the original encode.

>>61404647
>And what's the deal with daala?

All Daala research will end up in AV1 (same with VP10 and Cisco's Thor) .

>>61405159
Lagarith is lossless.
https://en.wikipedia.org/wiki/Lagarith

>>61394456
You realize nearly every company backs it.. right?

apple, microsoft, loonix, google, netflix, cisco, hulu, intel, amd, nvidia, amazon, ADOBE, mozilla, realtek, broadcom, arm, etc?
fucking retard
it's literally called the ALLIANCE FOR OPEN MEDIA and it literally has FUCKING EVERYONE on board.

>>61394733
netflix doesn't..

>>61404647
aomenc, but it's only a reference encoder, so enjoy absolutely no multithreading (even though it says to support it) and awful encode speeds (~50 frames per minute on a decent processor). once the bitstream freezes we'll see some progress, probably with ffmpeg (as they did with vp9, it was even slower than it is now).

if you're still interested, look at this:
https://nwgat.ninja/test-driving-aomedias-av1-codec/

>>61404685
>I personally don't care about "supporting it", whatever that means. I do care about devices actually having support for it.
it has no support because it isn't finished yet. seeing all the names behind the alliance, i doubt hw support will be a problem.

>>61405952
And like a hundred companies support the Khronos Group yet Direct3D remains the dominant graphics API and CUDA remains the dominant GPGPU platform.

Oh and dozens of big names were behind AMD's HSA initiative and it's dead in the water. Wow, so amazing. Those names really helped.

>>61406368
huh? direct3D is about 5% of the market for graphics acceleration

File: fmj3.jpg (50KB, 550x363px) Image search: [Google]

50KB, 550x363px

>>61404928
>tfw vietnamese cartoon lovers are the main driving force in video compression area

>>61406368
3d rendering APIs are abstracted by every engine out there, the difference is not relevant

>>61406368
>CUDA remains the dominant GPGPU platform
njewia got academia locked on their solution while ayymd was sniffing glue, the result is industry-wide monopoly

this is not the case with h265, almost nobody uses it

File: h.266_status.png (100KB, 1874x579px) Image search: [Google]

100KB, 1874x579px

H.265 is the near-term "future" for all HD content. It's almost 50% more efficient than h.264. Acceleration in hardware is already out there. You can't fight it.

The nice goal of AV1 having royalty free licensing is a wet dream for many content producers, but AV1 is still in the weeds when it comes to algorithms. If they do actually freeze development as they claim to do, it will be a few years before we see it baked into chips. By that time the JVET will be done with JEM (H.266) as the standard will be pressed in stone around October 2020. If Mpeg and Fraunhofer sort out their horrible licensing costs by that time then VC1 will be as outdated (in terms of compression efficiency) as h.264 is today.

By the way they are aiming for another 50% reduction in file sizes with h.266.

>>61405734
enjoy your file sizes :^)

>>61406601
I wonder if private trackers/the scene will ever move on from H.264

>>61400193
>h264 is good enough while waiting for royalty free AV1
This is the big thing
I just wish that we had H.264 Hi10 hwdec to make the wait more tolerable but oh well

>>61406733
They're waiting for something actually good

10-bit H.264 is a meme pushed by autists
H.265 is a sad flop
VP9 requires too much CPU to be feasible
VP8 a shit

8-bit H.264 is the only suitable thing for now

File: 1499537806107.png (1MB, 1280x720px) Image search: [Google]

1MB, 1280x720px

>>61393005
No I just converted everything into x265. I'm not spending another month transcoding video again.

>>61406836
Are you stupid or retarded?

VP9 uses very little CPU thanks to VP9 hardware decoding

>>61406368
direct3d is the dominant api and cuda is the dominant gpgpu platform, but opengl and opencl are still supported by all mainstream gpus. support is what matters here.

>>61406897
>meanwhile it takes 10 years to encode anything using VP9

>>61406897
>VP9 uses very little CPU
>if you have hardware decoding
Oh, good point. I forgot that my phone consumes no power while charging, too.

(Nevermind the fact that you need a fucking latest-gen Intel Integrated Graphics, specifically to even have hwdec for it)

>>61406836

How is H.265 a flop? ALL new 4K content and HDR content is h.265 now. Also the "just wait for X" is a dead meme in the industry.

http://www.streamingmedia.com/Articles/Editorial/Short-Cuts/Video-How-Do-You-Choose-a-Codec-With-Technology-Always-In-Flux-119030.aspx

>>61406871
>all of that time and energy wasted to transcode

probably cheaper to buy a bigger hard disk

File: no.png (483KB, 720x527px) Image search: [Google]

483KB, 720x527px

>>61393005
>currently the most advanced codec both in terms of coding tools and compression strength AND in combination with the encoders available (x264 is better encoder, but H.264 is less pwoerfull format)
>I want it to die because I'm a freetard

Very wise and forward-looking, /g/igolo.

File: sawtooth-with-display.jpg (23KB, 640x480px) Image search: [Google]

23KB, 640x480px

>>61399863
>Apple
>Not having a dominant position

lmao you're an idiot.

Between the iPhones and iPads and Apple TVs, not to mention iTunes, they most likely have a big say in the industry.

They literally created desktop publishing in the 80s. They literally revolutionized and made iTunes a viable option for record companies after Napster took a huge chunk out of their record sales.

You're an idiot if you think otherwise and your fanboyism and anti-Apple hate is clouding your judgement.

>>61393005
Why can't I play this without turning down my scaling quality?
Ree

File: 1496827503428.jpg (217KB, 660x690px) Image search: [Google]

217KB, 660x690px

>>61406963
This was for long term archival storage. I was also downsampling so it was worth the huge 80% saving in disk space.

>>61400350

So we lost the battle already?

>>61399863
>Apple
>not having a dominant position

They control somewhere between a quarter to a third of the smartphone market and the tablet market in terms of active users. What they say regarding content consumption matters a little more than your feelings on the matter.

>>61407111
can Apple create great things?
sure.
does it have a large marketshare? no.

>>61407274
[citation needed]

>>61405159
Xiph has lots of uncompressed video for testing purposes.
https://media.xiph.org/

>>61405337
You do understand the larger the file the more error prone it is? And there are dead simple formats that allow for added redudancy if you so wish, like Mxf.

>>61405742
Stop this meme. AV1 is only getting 2 experiments from Daala. Lapping is impossible to implement
.

>>61406601
>By the way they are aiming for another 50% reduction in file sizes with h.266.
Over what?

File: ZuXVYT4.gif (523KB, 256x512px) Image search: [Google]

523KB, 256x512px

>>61407516
Are you fucking retarded dude? There's literally over 1 billion iOS devices out there.

They literally were the first to ever put USB in a consumer device and revolutionized FireWire and DV capturing. Not to mention consumer non-linear editing with final cut.

Try harder. Try cleaning your rose colored glasses. Your hate for a company is clouding your judgement, go slap yourself.

>>61407906
[citation needed]

>>61408018
https://www.theverge.com/2016/1/26/10835748/apple-devices-active-1-billion-iphone-ipad-ios

For the USB part, the Bondi Blue iMac from 1998 was the first ever consumer computer in the 90s that removed the floppy disc, added a CDROM/DVDROM and a USB port and FireWire for DV capture.

https://en.wikipedia.org/wiki/IMac_G3

Want any more proofs idiot?

>>61407649
Segmentation would handle any issues with large files if there were any, remember I'm dealing with raw video, NOT encoded video and not even in a container, the encoding and packaging is done later for archival where it's verified, no redundancy is needed at the format level, only at the FS level and only after an archival version is made. Syndication is handled by something else entirely which automatically does whatever it needs to depending on the broadcast target(s), this happens at broadcast time.

source
|-> archival array -> (post broadcast) software muxer/encoder -> (after a new lossless format comes out) -> software muxer/encoder
|-> muxers -> relays/hubs -> hardware encoders -> wires -> broadcast relay facilities

File: Hope.png (15KB, 353x606px) Image search: [Google]

15KB, 353x606px

>>61406509
It isn't so bad after all.

File: 1490396260760.jpg (79KB, 720x569px) Image search: [Google]

79KB, 720x569px

>>61406871
What do you niggas do? Do you rencode your current releases into the new format or just download BD releases and go from there? The latter looks extremely tedious, but doesn't the first one fuck the quality up?

>>61408775
For me this was all news broadcasts, intereviews and other shit where I don't care about quality so much. I don't touch my anime collection, even CoalGirls stays 100% bloat.

>>61408893
Makes sense. I hope someone will rise to the challenge and encode with the new formats. I'd do it with the 1700 since it's great at this stuff, but my upload is shit. Maybe by then Zen2 TR will be out.

>>61407693
Over h.265 you goofball.

File: a30.jpg (24KB, 400x400px) Image search: [Google]

24KB, 400x400px

>>61407171
>This was for long term archival storage

>Archiving transcodes of transcoded transcodes.

File: 4KtqxA8.png (50KB, 960x892px) Image search: [Google]

50KB, 960x892px

>>61406956
>He doesn't have Intel Kaby Lake or Nvidia Pascal GPUs

http://images.anandtech.com/doci/10944/dxva-checker.png

>>61408223
USB was on motherboards for Pentium MMX and K5 CPUs, fanboy.

I download x264 1080p anime releases and convert to hevc because it's visually lossless on my PC monitor anyways

Fight me

>>61404928
I'm praying heavily filtered DVD encodes will make it to AV1
Will AV1 have any worthwhile improvments to 480p video?

>>61408893
I'd like to recode all my FHD JAV
Is this a worthwhile goal?

Encoding x265 at max quality takes roughly 10x the time of x264 at the same settings. It literally encodes at 0.5 fps. Re-encoding to x265 is retarded, as you spend more in electricity than the cost per MB of a bigger HDD.

>>61394428
>>61394456
>>61394628
>>61394647
>>61394733
>>61395112
>>61395267
>>61395315
>>61396119
>>61396142
>>61398002
>>61400294
>>61400350
>>61401189
>>61401577
>>61401605
>>61404685
>>61405032
>>61406509
>>61406601
>>61406733
>>61406871
>>61406958
>>61407017
>>61407111
>>61407171
>>61407274
>>61407516
>>61407906
>>61408223
>>61408893
>>61412037
>>61412202

Don't answer shitposting weeb chinese shill Apple thread.

Why does everyone say it's bad? It can encode pretty 720p clips in a really small filesize. What alternatives are better that can do what HEVC does while keeping the same file size as HEVC?

VP9 is already better and AV1 is even better.

Rip

File: SS9Dt3W.jpg (23KB, 960x539px) Image search: [Google]

23KB, 960x539px

>>61394421
>AV1 will kill it.
Have you ever encoded with it, it measures encoding speed in frames per minutes. And on my FX-6300 it's like 1, @1080p. It has a ways to go.

I have a site that needs to encode thousands of vids daily, i tried x265, the file sizes are way smaller, but it's more than twice as slow as x264.

for example a 500mb vid encoded with x264 takes 2 mins and ends up being 300mb

the same vid takes 6 minutes on x265 but ends up being 100mb.

so since storage is cheaper than processing power I'll stick with x264. there's also the fact that x265 isn't well supported yet

>>61414844
>VP9 is already better
>vp9 encodes at 3 fps
>x264 encodes at 800fps
it's fucking SLOW..

>>61412037
Was considering this but idk how to quantitatively decide what the new quality setting should be when transcoding to hevc to get minimal loss but get the better compression of hevc

>>61394475
x265 12bit is the future

>>61414850
Of course it's fucking slow.
It's unoptimized and the bitstream hasn't even been frozen yet.

>>61415233
What site?

>>61407214
What did you expect? They have money to push a new standard.

>>61401818
tl;dr: AV1 missed the train. Again.

>>61415233
>so since storage is cheaper
Prepare to have autistic meltdown coming your way.

>>61393005
>HEVC 10 bit in all Pascal Nvidia GPUs and latest Intel CPUs even before H264 10bit.
>Will it die


HAHAHAHAHAHAHAHA

But seriously, HEVC is here to stay.

>>61415254

just buy a threadripper.

[GCC 7.1.0][64 bit] 12bit
Encoding settings : cpuid=1173503 / frame-threads=14 / numa-pools=12 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=3 / input-csp=1 / input-res=1600x900 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=5 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=120 / lookahead-slices=5 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=7 / merange=64 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=0.30 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=abr / bitrate=1139 / qcomp=0.75 / qpstep=6 / stats-write=0 / stats-read=1 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=4095 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0

>>61407906
> revolutionized
That's how I know it's an Apple fan.
> revolutionized FireWire
You mean "reinvented the wheel and set a prohibitive license pricing"
> consumer non-linear editing with final cut.
And killed it 15 years later.

>>61404801
Modern intel CPUs can be extended regarding their hardware decoding capabilities. E.g. Intel added hwdec for vp8/9.
However, that's not as power efficient as traditional hardware decoding. It's kind of a glorified shader program.

265 isnt going anywhere, eventually nothing new will be x264

>>61417825
>psy-rd=0.30
>rc=abr / bitrate=1139
It doesn't matter how good h265 is when it's being encoded with those settings.

>>61420787
>psy-rd=0.30
what is wrong?
>rc=abr
it is 2pass vrb encoding
>bitrate=1139
it is low bitrate encode, so?

>>61420646
not until the encoder is not shit.

>>61421138
What do you mean by shit, its slower? It will always be slower than x264