/tech/ - Technology★

>Codemumkey still hasn't added AV1 support to 8chan

It's not viable yet. You get a better quality video at the same bitrate and encoding time at VP9 than with AV1 atm.

Let's wait until the war is over and there are actually solid encoders and decoders instead of rusted rav1e and so on.

who cares

I just want my Daala.

>>1038684

>solid decoders

dav1d recently added some SSSE3 optimizations and can now decode 8-bit yuv420p at 1080p30 with relative ease on non-AVX2 CPUs.

>>1038727

just ignore them. they use full botnet phones anyway so the autism with computers is pointless

>>1038705

This. It would probably be better to make a solid video codec decodable by software than to make some half assed we-have-to-beat-x-until-xx/xx/xx.

AV1 4k+ is unplayable on my machine.

I hope it doesn't become a standard, I don't want to be forced into upgrading to botnet just to be able to watch videos.

>>1038679 (OP)

AV1 already won this battle, it just needs hardware acceleration to start being deployed, as decoding (and encoding) it with software is simply prohibitive.

>>1038807

>(((hardware acceleration)))

I don't wanna buy new (((shit))).

VP9 and h264 10-bit decode just fine with software on my PC.

Software decoding is the future. Imagine what would have happened if hardware decoding was done for images?

You would buy your image accelerators for all kinds of formats instead of people writing good fast decoder implementations and inventing new formats.

Hardware decoding stops progress.

>>1038808

Because you're not decoding multiple keyframes per second when loading a single image. Though when displaying photo's and images taken and stitched from Nasa's telescopes I would rather have a much faster experience rendering millions of pixels. Not to mention the enormous power reduction from hardware decoders compared to software. Remember apple's macbook(?) draining battery because their 4k screens didn't come with a 4k VP9 decoder because Intel didn't implement it in their processors? Apples solution was to disable software rendering and called it a day. Hardware decoding doesn't stop progress either. There are plenty of people working on AV1 that will no doubt use non-meme machine learning and new algorithms to come up with the next version. And if you suggest that adoption rate sucks because it will take a while before everyone has new hardware with the new decoder then might I ask you wether the old computers, laptops, tablets, phones were ever able to use software rendering on the old or new format without their users complaining about power draw/battery life or stuttering due to underpowered arm socs.

>>1039024

>4k screens

Having 4k screens on a laptop drains the battery very quickly independent of software or hardware decoders for video.

I don't want to buy shit nor be stuck with half assed AV1. We already know it's just VP10.

>might I ask you wether the old computers

Old computers don't have hardware decoding and software decoding VP9 worked on a dual core centrino laptop.

>phones

Fuck them. Phones are for making calls. People misunderstood the concept.

>>1038808

>I don't wanna buy new (((shit))).

That's because you were retarded enough to buy things at the wrong time.

>VP9 and h264 10-bit decode just fine with software on my PC.

You can't even compare them with AV1.

>Software decoding is the future.

Only that it isn't.

>Imagine what would have happened if hardware decoding was done for images?

We would fix loads of problems, specially for professionals.

>You would buy your image accelerators for all kinds of formats instead of people writing good fast decoder implementations and inventing new formats.

No, that's happening right now and still need them because things don't go in only one way.

>Hardware decoding stops progress.

No, it is a necessity of higher complexity.

>>1039044

You're retarded, it seems.

>>1039024

>Contesting planned obsolescence

I guess we should make the scales for video files, image, games and the internet be all the way compatible with those early 800x600 Windows 95 PCs then.

>>1039049

thats not the same thing tho. there has now been a new video format almost every year and none of them work with existing hardware decoders so the only option to get support is buying a new gpu or laptop if you use those

>>1039048

>That's because you were retarded enough to buy things at the wrong time.

When was the right time? 'Cause I've been buying hardware for 3 decades now. Oh you mean I'm a retard for not updating to the botnet just to watch shitty hollywood propaganda?

>You can't even compare them with AV1.

99% of the population can't see the difference between DivX 3.11 ;-) in widescreen SD and H.264 in 720p. 99.9999999% can't tell the difference between H.264 in 1080p and AV1 in 4K.

>Only that it isn't.

Hardware decoders have always become obsolete pretty much overnight after release while software decoding has been the go-to for pretty much all applications going back to the 90s. The only place with hardware decoding makes sense for the average consume is set-top devices. 99% of people aren't going to notice any difference between AV1 and whatever they're streaming now. They might pretend to but like audiophiles they just get the latest standard to brag about it to their friends.

>We would fix loads of problems, specially for professionals.

I notice you didn't list them.

>No, that's happening right now and still need them because things don't go in only one way.

You okay anon? 'Cause you're looking like a real baka right now.

>No, it is a necessity of higher complexity.

Go on...I want to know how hardware decoding is more complex than software decoders when the past has shown that all hardware decoding does is produce a worse result with the inability to update the software.

>>1039024

>apple disables software decoding which means no video without the right hardware

>Hardware decoding doesn't stop progress either.

hmmmmmmmmmmmmmmmmmmm...

>>1039093

based

>>1039044

>Having 4k screens on a laptop drains the battery very quickly independent of software or hardware decoders for video.

Dont strawman, the point I made was that hardware decoding was vastly more power efficient than software. Hence becoming a problem on a laptop. Wether the 4k retardation exists or not.

>software decoding VP9 worked on a dual core centrino laptop.

>This one particular codec was lightweight enough for a potato therefore all codecs and computers shouldn't have a problem.

Hardware decode ALWAYS saves power and CPU cycles for something people use on a daily basis.

>Phones are for making calls.

Figured you would go for low hanging fruit. The market disagrees with you. People use their phones like they used to use PC's and Laptops (Which I am not advocating for) therefore their interests are important. Though being able to stream av1 to low powered Socs will be usefull somewhere other than phones.

>>1039093

>can't tell the difference between H.264 in 1080p and AV1 in 4K.

Its almost like this was already well known. All compression schemes have their limits due to entrophy. AV1 only offers "marginally" better compression in relation to quality compared to the last codec. It's not a silver bullet. Increasing bandwidth is the only way you'll truly increase quality.

>all hardware decoding does is produce a worse result with the inability to update the software.

You're right in that a hardware decoder is out of date the second its released due to the massive amount of resources poured in to the development of better codec's. Though hardware decoders ARE being updated as a result of new products saturating the market. Which is somewhere around 10 years depending on the product.

>>1039048

Anon you replied to here.

>That's because you were retarded enough to buy things at the wrong time.

Why? I have enough processing power and I can't watch multiple videos at once anyways.

GPU acceleration is also a possibility. Why does no one ever use that?

>You can't even compare them with AV1.

Why? They are all video codecs. What does AV1 have over VP9? Developers: MORE

They are pretty similar.

>Only that it isn't.

>because

>...

>specially for professionals.

I'm no professional, so why should I care. Professionals should use a method specialized to their use case.

>No, that's happening right now

So where can I buy my PCIe JPG accelerator or a GPU/CPU with hardware decoding for JPG?

>No, it is a necessity of higher complexity.

>necessity

Why? There is no MS Windows accelerator and no Google Chrome accelerator even through they are the most complex clusterfucks in the software world. Through modern CPU power they still run fine, through.

H264 10-bit and VP9 also decodes just fine without any hardware accelerator.

>>1039120

>The market disagrees with you

The market isn't a person.

>People use their phones like they used to use

They don't do anything productive on there. Try using a spreadsheet program on a phone.

>usefull somewhere other than phones

Do I look like a Youtube datacenter?

>All compression schemes have their limits

We are far away from the point where we have the most efficient solution.

>Increasing bandwidth

Half truth. Depending on the content there is lots of artifacts that can simply be compressed away (H264 hi10p and anime) and as above:

Current solutions are very rudimentary and only describe pixel changes and left right up down movements.

If something on the screen rotates it can't be well compressed.

There are many other common things to compress but that one alone should suffice.

>Though hardware decoders ARE being updated

You can't make any fundamental changes to them. Only slight improvements can be added on.

>>1039180

>why are GPGPU video de- and encoders so rare?

For several reasons. First and foremost the codecs that were popular in the past were patent encumbered which means NDA's and huge costs to get the copy+pastable library. Secondly because GPU's are essentially a CPU of varying artchitectures heavily optimized for much fewer commands, a reduced instruction set if you will. So the codec library must be implemented with either special instructions in hardware or by having access to the ISA of the GPU. The problem with this is unless you are talking about ancient GPU's or nvidia gpu's on nouveau prior to the 900 GTX series no one gets access to the GPU's ISA. Except via intermeditary layers that are blobs loaded at runtime such as AMD's microcode or nvidia's signed firmware. So implementing the newer codecs requires knowledge few but the NDA signers have, which work for the companies, who get kickbacks from codec producers who they already implemented for not to implement newer codecs.

Say you wanted MP4 acceleration on a GPU, you just implement it at the ISA level just like a modern CPU via a library calling instructions. But you have to be able to program those instructions which most modern GPU's will not let you do.

Third the patent encumbered codecs want to stranglehold the industry in order to get more liscensing shekels. Jewgle allows vp8/9 only because it benefits them so much in electricity costs saved for youtube streaming and bandwidth costs.

The only way out of this mess is someone developing a codec that uses the best of the best of the algorithms, including the patent encumbered ones, and just making the best software possible for implementation. Then publishing and updating a implementation anonymously using p2p software so that patent trolls can't fuck them over with cease and dissists. Then on the GPU's with access to the ISA of said GPU's GPGPU offload could be implemented.

But few have knowledge of the codecs to make a better codec. Even fewer would know how to upload a thing without getting a cease and dissist. Much much less fewer then that would have the knowledge to implement GPGPU offload, and the few that do already are in the hands of corperations or are blackmailed into doing nothing and or are too busy with irl survival.

>>1039219

Case and point to my post, see a anon like this that understands why a encoder/decoder needs to do what it does and who doesn't give a shit about copyright. He could implement a codec maybe and upload it anonymously because scenefag but then has none to little knowledge about gpgpu stuff.

>>1039221

I understand as much about gpgpu as publicly available. As you said anon the problem lies in the fact that modern GPUs are so locked down. It's impossible to learn when you can't even make them say Hello World.

>>1039232

>hello world

You can, just RTFM for AMD/ATI and intel here https://archive.fo/fnnaH and for nvidia/nouveau here https://archive.fo/3TUnY . It's just theres alot of fucking GPU's that would need an implementation all using different ISA's and features i.e mmu or no mmu.

>>1038705

...4 years later...

>>1039180

>de- and encoders

transcoders

>>1039218

>Secondly because GPU's are essentially a CPU of varying artchitectures heavily optimized for much fewer commands, a reduced instruction set if you will. So the codec library must be implemented with either special instructions in hardware or by having access to the ISA of the GPU.

What about OpenCL? Is it a meme?

>>1039242

For sure, I guess I put it badly. The problem stems from a lack of standard between the major GPUs and them being so closed off. I have found in my experience working with video that the GPU produces worse results or is very limited in what it can do in my tool chain. I would off-load what I could to the gpu but often would have to choose to do things on the cpu because the results weren't acceptable to my eye. In filter chains there were only specific things that could be off-loaded to the GPU without causing issues of quality.

Also as the years roll on I've found less need to off-load to the GPU while doing final encodes simply because when the goal is quality waiting a bit longer isn't as much of an issue. CPUs are really fast now compared to when I started doing this years ago. Gone are the days of waiting 24 hours for 25 minutes of video to finish being encoded. Now in an area where time is crucial, say live streaming or moving lots of video around in real time like in a studio I could see where the trade off might be worth it. Even then the GPU decoder needs to be a lot faster than the CPU to make it matter enough to be worth the degradation of the quality.

These days I'm sure the days of making filters through scripting and tuning the encoder by hand are long past. I get the impression that most people are copy/pasting ffmpeg commands or using a full fledged GUI to do production work. Which is fine I used plenty of GUI based software too but there was always a script there to glue the various tools I used together. I feel like the proper entry to this stuff was lost in the last decade or so as well. I know in the various fansub/warez scenes it's rare to find groups doing anything but ripping a show off a streaming service or doing basic Blu-ray/DVD rips. Folks aren't working with old sources of material that need to be cleaned up much anymore.

>>1039508

OpenCL is like C for GPU's. Developer writes a opencl libray for a GPU and then a user can call opencl functions after importing opencl header files. Just like a developer writes a C library for a CPU and then a user can call C functions after importing opencl header files. Its just middleware to the assembly code, but it is standardized middleware to the assembly code making it easier to call for a bunch of different GPU's. But opencl is a unoptimized peice of shit because AMD has paid professional solutions for opencl so they don't optimize the FOSS solution. Nvidia is the same as they have CUDA. The nouveau/redhat developers haven't even implemented opencl publically for nvidia gpu's anyways. Intel has a semi-decent opencl implementation but its not optimized as well as it could be and of course intel IGPU's are slow unless you get the newer botnet/blobbed ones.

>>1039514

There's plenty of gigakikes into the transcoding scene as youtube has ways of detecting the slightest changes in a banned video and banning videos. So its a rat race between noobs discovering tricks, or the man page, of ffmpeg and varying codecs. Or things like encoding a video in one format but making it turn into a completely different video encoded in another format. Your a scenefag you should know this stuff.

>>1039529

>OpenCL a meme

Does Vulkan have any hope of offering a proper GPGPU compute standard with non-gimped implementations at some point in the future?

Are fully fledged video decoders running almost entirely on the GPU with no decoding ASIC present science fiction?

>>1039537

>Does Vulkan have any hope of offering a proper GPGPU compute standard with non-gimped implementations

It depends on how good the assembly to library implementation takes advantage of the hardware. Technically there is already a way to go from assembly > opengl/vulkan > whatever. Just convert it to SPIR-V and then go wherever the fuck you want as long as it goes back to hardware via something. See mesa's clover and LLVM's SPIR-V for implementations http://llvm.org/devmtg/2017-03//assets/slide/spirv_infrastructure_and_its_place_in_the_llvm_ecosystem.pdf https://archive.fo/RLpAS . Anything that has a assembly > gallium implementaion in mesa can do opengl/vulkan > spir v > whatever you want which will make GPGPU offload possible for anything a reality for FOSS. You could do something obscure like opengl/vulkan > spir v > javascript Why the fuck would you do this? if you really wanted too, and it can go in reverse too.

Just make sure to use it correctly as some instructions are better left to a x86/dedicated cpu such as single threaded apps with x86 specific math instructions. Some assembly to *insert library here* implementations are going to be better then others. Like the botnet AMD GPU to vulkan implementations being better then their opengl.

>>1040420

That picture tells your nothing of how it works. Picture goes in magical bullshit engine and something comes out as data of the other side.

>What you're talking about here is fixed-function ASIC SIP cores like Quick Sync, NVENC, or VCE.

What you neglect to mention is that those functions are not always using dedicated hardware functions and it gets generalized to the GPU somtimes because the hardware dev wanted to save money and the customer can't see the difference as long as its 1% faster then the last generation due to software optimization of the same exact hardware rebranded several times.

>SIP cores

Now I know you are larping and a troll, system in package, also known as a spread out SOC has nothing to do with dedicated math functions in hardware. Just because you put out a buzzword doesn't mean that buzzword is actually using dedicated hardware. You have to prove it does or doesn't like you can with FOSS software.

Enter every GPU made past 2012, just rebranded shit that is the same hardware underneath with minor changes or with software changes for respective vendors.

>>1040429

>Now I know you are larping and a troll, system in package, also known as a spread out SOC has nothing to do with dedicated math functions in hardware.

It does if said functions are hidden behind proprietary firmware.

>>1040506

How does it compare quality wise to the reference AV1 encoder?

>>1040506

>That last benchmark

How in the world did that happen?

9900k behind TR and the i9 three times as fast.

Netfux will adopt AV1 for livestreaming now that Jewntel's SVT-AV1 encoder has managed to encode AV1 at 1080p60 with abhorrent visual quality.

How would HEVC have performed as general Interwebs streaming codec in alt-timeline where it had a much less kiked patent licensing scheme?

It should've completely trashed VP9 for encoding 16mb mp4s given its better quality/speed tradeoffs at settings above placebo.

>>1038679 (OP)

People are working on applying deep learning techniques to video and image compression.

AV1 will be obsolete by 2020.

http://cs231n.stanford.edu/reports/2017/pdfs/423.pdf

https://arxiv.org/pdf/1703.01467.pdf

>>1050738

>buzzwords

Haha very funny. How do you want to decompress that without a format that has strict rules?

>>1050678

>Xvid

Hi grandpa.

>>1050674

>kikeflix

Who cares? They also require some DRM bullshit in browsers.

I love Donald Trump! Heil Israel MIGA 2020!!!

I love Black women. They are so dominant and masculine!

I love eating bagels. Why do you guys want to kill the Jews?

Daily reminder that NEET-Socks deserve the rope.

>>1039048

>>Software decoding is the future.

>Only that it isn't.

Only it is.

FPGA require software to configure the hardware, therefore software decoding is the future.

>>1057783

They're way too busy bumplocking meaningful threads (such as >>1057834) the moment they appear. What did you think?

>>1057845

>meaningful threads

>not a thread = meaningful thread

For cuckchan /g/ perhaps, not here.

>What is QTDDTOT?

..and don't say the thread doesn't fall under QTDDTOT because it does when the OP makes zero effort.