[ / / / / / / / / / / / / / ] [ dir / asmr / bbbb / canada / cyoa / htg / madchan / polmedia / startrek ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

[–]

 No.799882>>799928 >>799964 >>799965 >>801108 [Watch Thread][Show All Posts]

Has anyone else downloaded and messed around with the AV1 source code and examples? I recorded 9 seconds of a 1080p commercial and converted it to 420 y4m so it would work with the sample encoder. I'm currently getting .76 frames per minute on an i5 Haswell. It says I have 6 hours left on the encode. Of 9 seconds. Even if it does manage to be better than h.265, I don't think people will waste a year to encode a movie.

 No.799928>>799939 >>799964

>>799882 (OP)

With hardware acceleration it won't that much of a problem.


 No.799939>>799964

I get preety good encoding times with vp9 right now. Why should I "upgrade" to av1 when I can convert that

same 9 seconds of video to vp9 in like twenty seconds?

>>799928

>With newer botnets it won't be much of a problem

Fixed. Unless you can find me some non botnet hardware encoder/decoder for vp9 or av1 fuck you. I will stick with vp9's great software encoding and decoding.


 No.799964>>799966 >>799969

>>799882 (OP)

>>799939

It's known that AV1 (and HEVC while we're at that) have a stupid long encoding time, but that's because, for it be open-source and royalty-free, it actually mustn't use any patent and have to circumvent tons of stuff to manage that, causing the slow encoding.

>Why should I use it blah blah

Less storage space, better quality, less downsampling life.

And as >>799928 said, hardware acceleration will end the problems.

Actually, are you aware that AV1 will be a "mother codec" and every subsequent codec from now on will be based on it? It means that no matter what branch/fork of AV1 people/companies choose to use, if the hardware is AV1-compatible, they'll all be accelerated.

>But muh botnet

Everything's a botnet.


 No.799965>>799968

>>799882 (OP)

More on why shit like AV1 is important in this video:

https://youtu.be/IheZzcYUV9w

Google fucked up immensely with WebP and WebM precisely due to the Codecs, which makes them light but prone to disgrace in the long run.

To companies, this is inadimissible as they lose money and band streaming the shit out of these everywhere. This also imperils old/rare archives.


 No.799966>>799969

>>799964

>Actually, are you aware that AV1 will be a "mother codec" and every subsequent codec from now on will be based on it?

OP here. Yes I'm aware its big, or will be big.

I've been holding off re-encoding my library until the bitstream freeze and ffmpeg implementation sometime at the end of the year. Hopefully somebody will write an opencl or cuda encoder soon because it's painfully slow. I'm mean holy fuck the 9 second encode is still going and I'm down to .58 frames per minute now.


 No.799968>>800108

>>799965

Is this a troll video? FLIF is a lossless codec. Who the fuck is going to re-encode lossy images 1000 times until they turn to goo?


 No.799969>>799971

File (hide): b623be8b1c466f1⋯.jpg (51.82 KB, 680x385, 136:77, anime-nuke-awkward.jpg) (h) (u)

>>799966

*autism intensifies*

AV1, if what >>799964 says is true about it being a universal hardware based codec, could be the botnet of botnets.

For example, a virus project bluebeam may or may not use COBRA, a software suit for (((logging))) on all platforms. COBRA uses a encoding/transfer mechanism known as ZeroMQ, a TCP/encryption stack meant to work on all hardware platforms in exsistence and transfer/IPC methods.

ZeroMQ is a extension to ffmpeg. So if google makes it so the only fast implementation of AV1 and all subsequent codecs are only using ffmpeg's implementation of AV*, then feasably you could get a hardware backdoor for sound/video into every single future system with hardware AV* encoding and have network access to it. Even if it was "open source" software all the way down to the blackbox of hardware decoding/encoding in the proccessor.


 No.799971>>799978

>>799969

So the future of AV1 makes you paranoid, but the present where everything has h.264 hardware decode doesn't bother you? Stay consistent at least if you're going to be stupid.


 No.799978>>799984

>>799971

Well yes that is possible too. But much less likely since there are ARM boards out there you could build yourself that have h264 hardware decoding/encoding for FOSS. But with AV1 I doubt jewgle of all people is ever going to let open hardware become a thing for it unless you pay many shekels. Too much for a hobyist or non bribed/blackmailed corperation.


 No.799984>>799988

>>799978

Uh uh NO the reason, dear boy, it's called HARDWARE decode is because it's IN THE FUCKING HARDWARE. You don't get access to it in ARM FUCKING BOARDS because ARM FUCKING BOARDS aren't FREE OPEN SOURCED OR SOFTWARE


 No.799988>>800002 >>800854

File (hide): aaf64cdd95c3373⋯.png (180.52 KB, 600x264, 25:11, ZOGnet.png) (h) (u)

>>799984

No you faggot. There are design sheets for ARM boards on the internet right now you could download to make yourself. Hence FOSS and hardware built yourself.

Stay mad. Not like anyone would beleive such a thing could happen anyways with AV1.


 No.800002>>800012

>>799988

>hardware built yourself

Yeah, you and whose chip fab dipshit?


 No.800012>>800014 >>800019

>>800002

The one you built yourself faggot. You don't think there aren't howto's on such things? Or hell the fucking ability to figure it out amongst the goyim? Gas yourself kike.


 No.800014>>800015

>>800012

okay, you're clearly mentally deficient. Opinion discarded.


 No.800015

File (hide): 9bc564793b3b035⋯.gif (278.49 KB, 373x373, 1:1, REALLYMAKESYAThINK.gif) (h) (u)

>>800014

>mentally deficient

>able to build your own chip fab

Really makes one think.


 No.800019>>800021

>>800012

Go back to /pol/ you dumb faggot. Holy fuck you are dumb.


 No.800021

>>800019

Explain how I am dumb and how I can improve myself then.


 No.800064>>800135

Fuck this shit where's Daala?


 No.800108

>>799968

FLIF can do both lossless and lossy.


 No.800123>>800138 >>800441


 No.800126

1. lurk moar on doom9.

2. the bitstream isn't even frozen, any performance comparison is retarded beyond belief.

3. it's gonna be slow anyway.


 No.800135

>>800064

This is based on Daala's work. Everybody is joining forces to work on this. Except Apple of course.


 No.800136

I know jack shit about working with video rendering, but if it's at all trivially parallelizable, you could just slap some arrayfire on the relevant loops to make at least some of it render on graphics cards.


 No.800138>>800163 >>800164 >>800165

>>800123

Off topic rant.

How is this considered beautiful by today's standard? Those soulless eyes, childlike nose, alien shaped face features. If she didn't wear eye liner she would look really weird, like something is missing. I hate it, because it feels like I have been brain washed to think eye lashes should be that prominent. She looks like she was created in factory with other almost the same looking clones that were given few distinct "features". What happened to people having some kind of defining quirks about them.


 No.800163

>>800138

>She looks like she was created in factory with other almost the same looking clones that were given few distinct "features".

>looks like

It's called "beauty industry" for a reason.


 No.800164

File (hide): e4259a4b908834f⋯.jpg (65.18 KB, 790x1053, 790:1053, hat.jpg) (h) (u)

File (hide): 6353c8fe967656d⋯.jpg (689.5 KB, 1920x1080, 16:9, messy.jpg) (h) (u)

File (hide): 56131eccc850a21⋯.jpg (65.21 KB, 640x480, 4:3, phone.jpg) (h) (u)

>>800138

More for you to judge.


 No.800165

File (hide): b0e2b79f15f588c⋯.jpg (429.71 KB, 1260x1945, 252:389, 1910.jpg) (h) (u)

>>800138

Straight from 1910, a real woman.


 No.800433

Am I correct? I was really hoping I was wrong about it being a fucking botnet of botnets. But this is being slid by mad by those fagoli posts. Which is to say streiserand effect.


 No.800441>>800444 >>800606

>>800123

It's shipping next year:

>It looks like the bitstream will freeze around December 31, 2017, which has been the consistent target for the last three or four months.

>both Chrome and Firefox will enable playback support within days (if not hours) after the bitstream freezes

>In the shorter term, Srinivasan also shared that software decode optimizations, an Ittiam specialty, should appear within six months of codec freeze. These optimizations will make software decode much more palatable on a range of consumer and mobile platforms.

Quality is 20%-30% more efficient than VP9

>Netflix's director of video algorithms Anne Aaron reported that AV1 was about 20% more efficient than VP9

>Matt Frost, head of strategy and partnerships, Chrome Web Media, at Google, added that AV1 was 30-35% more efficient than VP9 in their tests

Encoding complexity will remain substantially higher than VP9 or HEVC even after optimizations:

>Bitmovin showed real time encoding of a single stream of 1080p video into AV1 format, which required up to 200 cores. However, Bitmovin CTO Christopher Mueller predicted that these requirements will drop to 8-32 cores, "sooner than later."

>expect encoding times to increase substantially over HEVC and VP9.


 No.800444

>>800441

Can't be worse than VP9 that never got well done multithreading.


 No.800453>>800525

>>Bitmovin showed real time encoding of a single stream of 1080p video into AV1 format, which required up to 200 cores

At .5 frames per minute, I believe it.


 No.800525>>800572 >>800873

>>800453

That's not what real time means (unless the video is 0.5 frame per sec, of course).


 No.800572

>>800525

Spotted the grade schooler.


 No.800606>>800820

>>800441

> these requirements will drop to 8-32 cores

Better stock up on those Ryzen Threadrippers


 No.800820>>800832

>>800606

Or start buying ARM based phones to run in parallel in the future.


 No.800832>>800856

>>800820

Video encoding isn't embarrasingly parallel, you know.

https://x265.readthedocs.io/en/default/threading.html#frame-threading

Entropy coding takes most of the time, anyway.


 No.800854

File (hide): 48895fdac5d4f67⋯.png (266.84 KB, 770x460, 77:46, ClipboardImage.png) (h) (u)

>>799988

>There are design sheets for ARM boards on the internet right now you could download to make yourself

The board is the least of the issues. The chip, anon, the damn chip. that square block in the middle of your NormiePi. That's not open-source and won't be because ARM is not open source.


 No.800856>>800877 >>800927

>>800832

I don't see why it couldn't be.

Split the video into several minute or second long parts encode each of them individually and stitch them together at the end.

The only two downsides would be that for one you couldn't reference any previous frames at the beginning of each segment, and on the other hand, you need a bit more disk space for the stitching (sum of all parts + size of the current part).

Encoders should definitely have this option, because unless you are streaming the encoded video it would definitely improve the performance.


 No.800873>>801013

>>800525

I'm the OP. I was getting .5 frames per minute with a 4 core Haswell. I'm saying I believe them when they say you need 200 cores to get 24-30 frames encoded per second. Encode time is fucking unbelievably slow.


 No.800877

>>800856

>The only two downsides would be that for one you couldn't reference any previous frames at the beginning of each segment

This is done anyway (each keyframe is a new boundary which can't be crossed by further reference frames, otherwise seeking wouldn't work with reasonable speed)

And good keyframe detection can be done easily, so it won't be a big efficiency loss.


 No.800927

>>800856

Then your bottleneck is memory bandwidth. And entropy coding is still taking too much time.


 No.801013>>801110 >>801113

>>800873

I see. There wont be any optimization before the bitsream freeze, anyway. NONE.

>Haswell

Bonnet.


 No.801108

>>799882 (OP)

>designed for streaming

>proprietary javascript video players in the browser

dead on arrival


 No.801110>>802432

>>801013

In order to have real time 24fps encode on this hardware, they would need to get 120 times speed increase in 3 months. They've already stated hardware acceleration wont be around until the end of next year. If you've ever played around with VP9, you would know encode times were bad. The only bright side of all of this is that decoding isn't nearly as resource intensive. Otherwise AV1 would be DOA.


 No.801113>>802423 >>802433

>>801013

>I see. There wont be any optimization before the bitsream freeze, anyway. NONE.

Any arguments to back that up?


 No.802423

>>801113

Jewgle is greedy is one.


 No.802432>>802445

>>801110

VP9 encode times aren't bad actually. Compare it to x265 and the only bad thing is the threading, not the actual computational power.


 No.802433>>802458

>>801113

Common sense and doom9 lurking. Why do optimizations if you potentially will have to strip them? Plus, they're simply focused on getting gains at this point.


 No.802445

>>802432

Compare it to something people actually use instead of a shekel-grabbing meme codec.


 No.802458

>>802433

>if you potentially will have to strip them?

???




[Return][Go to top][Catalog][Screencap][Nerve Center][Update] ( Scroll to new posts) ( Auto) 5
50 replies | 7 images | Page ?
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / asmr / bbbb / canada / cyoa / htg / madchan / polmedia / startrek ][ watchlist ]