Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr / vt ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Due to resource constraints, /g/ and /tg/ will no longer be archived or available. Other archivers continue to archive these boards.Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 62 KB, 2000x1110, 2000px-AV1_logo_2018.svg.png [View same] [iqdb] [saucenao] [google] [report]
67582848 No.67582848 [Reply] [Original] [archived.moe] [rbt]

Playlist of videos:
https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS
You can opt-in here too:
https://www.youtube.com/testtube

>> No.67582864

THANK YOU BASED GOOGLE

>> No.67582869 [DELETED] 

>>67582848
Hardware decoding support?

>> No.67582873

>>67582869
GPUs in 2020

>> No.67582995 [DELETED] 

>>67582873
Yeah, I'm sticking with h264.

>> No.67583027

>>67582848
If anime encoders don't adobt it, then it's trash.

>> No.67583041

Plays back in 1080p on my machine. Nice.

>> No.67583042

>>67583027
Anime will ever be stuck on h264.

>> No.67583054

>>67582873
>Transcoding 2 years prior HW decoder come

>> No.67583095

>>67583042
10bit h264 is unironically better than hevc for anime

>> No.67583105

>>67582848
first thing I see is that communist kike talkshow host. fuck off subhuman

>> No.67583122

What’ is this?

>> No.67583136

>>67583027
Anime encoders are terrible. They haven't adopted h265 despite being like half the size as h264 and showing no difference in fucking anime.

>> No.67583138
File: 19 KB, 425x419, 1375773299400.jpg [View same] [iqdb] [saucenao] [google] [report]
67583138

>>67583027
Weebs really are at the forefront of video technology.

>> No.67583156

>>67583105
Imagine being so detached from the real world that your first and only reaction to a technology thread is to screech /pol/ buzzwords in an autistic fit of rage.

>> No.67583160

>>67583136
You can usually find h265 encodes for blu-ray releases.

>> No.67583172

>>67583136
Bait harder

>> No.67583243

>>67583136
Why adopt a format only to be replaced 4 years later? Re-encoding every 4 years archival quality releases is impractical and no one cares about normal releases, so h265 is only used for low-quality/mini-mkv.

>> No.67583249

So this is only for sub-480p videos? This isn't really relevant to me then but it's nice to see improved support for low-bandwidth streams.

>> No.67583256

Youtube must die
the Silicon Valley must die

>> No.67583271

>>67583136
>they haven't adopted h265
(and that's a good thing!)

>> No.67583275
File: 850 KB, 1826x1795, apustajasmart.png [View same] [iqdb] [saucenao] [google] [report]
67583275

>>67583136
>Anime encoders are terrible. They haven't adopted h265 despite being like half the size as h264 and showing no difference in fucking anime.

Imagine being this brainlet
x265 take like 7x the time to encode an episode for maybe 40% decrease in file size.

guess which resource is cheaper and cheaper? storage

guess which resource is always limited? TIME.

>> No.67583303

Anime encoders are the most inept, trying to encode in non hardware decoding modes to deny people enjoying videos on low power SoCs and power efficient GPU hardware decoding

>> No.67583307

>>67583303
stop watching anime on your phone

>> No.67583318

>>67583303
Anime uses very advanced subtitles so you have to throw out hardware decoding most of the time anyway.
Also, banding is a much bigger issue, so there is much more incentive to use 10-bit.

>> No.67583321
File: 75 KB, 678x381, 05_Mali-V76 Deep Dive_NoWM_22b_678x452.png [View same] [iqdb] [saucenao] [google] [report]
67583321

>>67583307
Go to hell, also 10-bit H.264 hardware decoding is coming anyway, all you inept animu decoders can't stop the hardware decoding revolution

https://www.anandtech.com/show/12835/arm-announces-maliv76-video-processor-planning-for-the-8k-video-future

>> No.67583336

>>67583321
>Go to hell
No U.

I watch anime very comfy on my 4k tv with my Nvidia Shield tv capable of decoding hi10p anime in cpu.

>> No.67583342

>>67583275
>>67583275
Two can play this game:
Guess which component becomes more and more powerful? CPU.
Thus required time gets reduced.

>> No.67583354

if you're over 20 and still watch japanese cartoons you should unironically commit suicide

>> No.67583357

>>67583136
That's great
My X230 does not have hw decoder for h265

>> No.67583358

>>67583275
This.Also with bitrates over 1Mbit/ s hevc loses its edge on 1080p content. I've read that hevc omits the movement of small background objects to save bitrate and that makes it unsuitable for anime at low bitrates.

>> No.67583360

>>67583342
>>Guess which component becomes more and more powerful? CPU.
>Thus required time gets reduced.
you are pretty stupid too.

Moore's Law is already stopped, we see just marginal increases in cpu powers each new gen, and yet a protocol jump can easily kill your gains

again I repeat myself: x265 takes from 7 to 9x the time of h264 h10p TODAY, and it's on its way out

>> No.67583364

>>67583357
>Using outdated, obsolete Thinkpad

KILL YOURSELF FAGGOT

>> No.67583367

>>67583354
If you're on an anime website complaining about anime, you should unironically commit suicide.

>> No.67583377

https://videocardz.com/77895/the-new-features-of-nvidia-turing-architecture

>new NVDEC decoder with HEV YUV444 10/12b HDR, H.264 8K and VP9 10/12 HDR support.

THANK YOU BASED NVIDIA

>> No.67583378

>>67583342
>>67583360
this is not even considering that your argument backfires on its own:

since cpus get better, any shit produced since 2013 can now play hi10p h264 in cpu

thank god your stupid genes won't reproduce

>> No.67583380

>>67583360
Moore's Law works only for a single core.
We just got Threadripper and Epyc, you can encode faster than ever by far.

>> No.67583389

>>67583377
>YUV444
this is good

>> No.67583395

>>67583367
>anime website
it's not 2006 anymore and you should stop pretending you were old enough to go potty back then, let alone to browse dollchan. also you should kill yourself.

>> No.67583401

>>67583380
>We just got Threadripper and Epyc, you can encode faster than ever by far.

and it's still way faster on h264

>> No.67583408

>>67583395
based

>> No.67583412
File: 50 KB, 320x442, 1399960207051.png [View same] [iqdb] [saucenao] [google] [report]
67583412

>>67583395
Whatever you tell yourself, reddit-kun.

>> No.67583415
File: 195 KB, 850x1202, 1519586369511.jpg [View same] [iqdb] [saucenao] [google] [report]
67583415

quick, post anime!

>> No.67583418

>>67583027
The encoding scene has slowed way down ever since streaming services came up. Fansubbing is on life support and so is the encoding that use them.

>> No.67583427

>>67583401
If you spending X time for h264 encoding was acceptable for you three years ago then why spending X-1 for a better h265 encode is wrong now?

>> No.67583429

>>67583418
>>The encoding scene has slowed way down
Category

Name


Link

Size

Date



Anime - English-translated [HorribleSubs] Steins Gate 0 - 21 [720p].mkv 230.2 MiB 2018-09-12 19:32 1067 77 6362

>> No.67583436

>>67583401
And its even faster on mpeg2
Your point?

>> No.67583438

>>67583429
>[HorribleSubs]
That is not the "encoding scene". He's probably talking about Daiz and shit.

>> No.67583446

>>67583427
>for a better h265
it's not better.
at best, it's the same with smaller size and can play on your smelly chink phone

at worst, x265 is very lazy with small movements and can fuck up anime border lines easily

>> No.67583452

>>67583412
>r-rebbit
as expected from a developmentally challenged manchild. at least think of suicide a bit more often. toodles.

>> No.67583454

>>67583243
You don't have to keep re-encoding new ones, just start moving tonit with newer encodes. You can still find old divx encodes of really olda anime. I don't see much demand for it considering there's still a codec war going on.

>> No.67583466

>>67583418
> The encoding scene has slowed way down
Somebody has to encode BDs, at least. I don't really care about TVs.

>> No.67583467

>>67582848
What's so special about AV1?

>> No.67583476

>>67583467
>What's so special about AV1?
royalty free

gets google to save bandwith aka save billions

>> No.67583480

>>67583467
As usual, less bitrate for the same quality/better quality for the same bitrate, compared to H.265/VP9/H.264.

>> No.67583481

>>67583446
>it's not better.
>at best, it's the same with smaller size
It means better. Also you can still get better quality with same size. Unless you only download some super high bitrate encodes, then it's probably hardly distinguishable from BD source anyway.

>> No.67583483

>>67583467
Next-gen video codec.
Royalty free and fully open.

So AV1 + Opus is now the godly codec combination for quality and freedoms.

>> No.67583485
File: 2.13 MB, 1440x1080, outlawstar.png [View same] [iqdb] [saucenao] [google] [report]
67583485

>>67583481
>Unless you only download some super high bitrate encodes,
I do because I'm not trash like you

>> No.67583490

>>67583429
That's horriblesubs, you tard. That's not Reinforce or any number of the dedicated raw encoders out there. HS just rips CR shit.

>> No.67583491
File: 684 KB, 800x800, 1536731913307.png [View same] [iqdb] [saucenao] [google] [report]
67583491

>>67583415

>> No.67583498
File: 107 KB, 1200x800, 1425295800699.jpg [View same] [iqdb] [saucenao] [google] [report]
67583498

>>67583491

>> No.67583501

>>67583483
AV1 is slow as fuck, and opus is just two codecs duct-taped together

>> No.67583508
File: 32 KB, 476x440, Screenshot_20180913-020656__01.jpg [View same] [iqdb] [saucenao] [google] [report]
67583508

>>67583412
>I watch children's cartoons

>> No.67583514

>>67583452
You're like one of those muslims that invade europe and demand sharia law. Adapt and integrate or get the fuck out

>> No.67583516

>>67583485
Then why won't you use better encoded files with half the size and same quality, you elitist scum?
>hurr, I only watch 50 Gbps chinkporn cartoons

>> No.67583518

I prefer .mkv

>> No.67583527

>>67583516
>better encoded files
you keep saying things that are not true.

>> No.67583536

>>67583501
>AV1 is slow as fuck
Every video codec is slow as fuck when it first comes out.
>and opus is just two codecs duct-taped together
So? It's still the best, especially at low bitrates, which is the only place that comparisons are meaningful.

>> No.67583541

>>67583527
better compression with same quality = better encode
How is that wrong?

>> No.67583546

>>67583536
>especially at low bitrates, which is the only place that comparisons are meaningful.

anything under 20 Mbps is not worth watching

>> No.67583548

>>67583518
This is probably bait, but MKV is a container, not a codec.

>> No.67583551

>Av1 encoding will get faster
LOL no it wont.

>> No.67583553

>>67583541
>>better compression with same quality = better encode
>How is that wrong?

Study what x265 does with the grain of 35mm film scanned anime.

>> No.67583557

>>67583546
That doesn't make sense. A bitrate on its own is meaningless without reference to a codec.

>> No.67583575

>>67583551
libavcodec is 1000x faster than libvpx for vp9 devoding

>> No.67583584

>>67583553
Purely academical issue.
Gib specific example with filesize and screen comparison.

>> No.67583603

>>67583584
>Gib specific example

the Evangelion BDs from a couple years ago.
1440x1080 from 35mm scanned film.
you can find torrents for hi10p and x265 encoded at highest settings, the results are clearly in favor of the former.

x265 likes to "average"

>> No.67583604

>>67583557
at some point bitrate vs filesize vs encoding speed gives diminishing returns. It's why audio comparison over 100kbps regardless of codec is rarely done.

>> No.67583609

>>67583575
1 week until faster decoder gets revealed
https://www.videolan.org/videolan/events/vdd18/

>> No.67583617

>>67582848
What is this and why is it a good thing

>> No.67583620

>>67583617
Google is finished

>> No.67583641

>>67583604
>It's why audio comparison over 100kbps regardless of codec is rarely done
Audio doesn't have a "resolution" or any other quality settings that can keep being increased, so it's basically at a cap.
Sample rate is basically fixed at 44100/48000, because humans cannot hear any frequencies above ~20KHz, and there is no point at going above 16 bits per sample, because you rarely need more dynamic range. So basically, it's just now trying to take what we already have and make it smaller.

Video isn't quite the same, because we can keep adding more and more resolution (until we reach some cap), meaning you need to higher and higher bitrate. Saying "I won't watch anything below 20 Mbps" may make sense for 1080p because generally all codecs will look very good, but doesn't mean that saying that makes sense for 4K or 8K content.

>> No.67583648

>>67583156
imagine being so detached from real world that you don't realize there's a war being waged against you with the only aim to exterminate you and your loved ones

>> No.67583661

It's the current year! I mean come on, I thought h264 died in the 60s!

>> No.67583664

>>67583641
>but doesn't mean that saying that makes sense for 4K or 8K content.
there is nothing worth watching at 4k yet

>> No.67583668

>>67583664
That's not my point. I was just being pedantic about pulling arbitrary numbers out of the air.

>> No.67583678

>>67583641
>Sample rate is basically fixed at 44100/48000, because humans cannot hear any frequencies above ~20KHz, and there is no point at going above 16 bits per sample, because you rarely need more dynamic range.

You can probably find a similar upper limit for perfect 10/10 human vision.

>> No.67583686

>>67583668
>That's not my point. I was just being pedantic about pulling arbitrary numbers out of the air.
my point is that 1080p was implied

>> No.67583689

>>67583678
Eventually that will probably happen, but we're not there yet.

>> No.67583690

>>67583095
14 bit hevc is where is it.

>> No.67583695

>>67583641
>I won't watch anything below 20 Mbps
You must take into account if the movie has lots of action going on. Most anime is over 50% stills and that bitrate is placebo at this point.

>> No.67583711

>>67583695
>Watching Jewish propaganda

BOOOM BOOM WOOOSH!!!
wow movies weeeee

>> No.67583730

>>67583711
>only hollywood makes action movies
Seek help. Look under the bed, the jews are out to get you.

>> No.67583745

>>67583664
there are tons of dope nature videos on youtube.
first thing i did when i transitioned from HD to FullHD was watching those. 95% of them have 4K too.

>> No.67583754
File: 381 KB, 568x433, Screenshot_2018-08-21 (3) Twitter.png [View same] [iqdb] [saucenao] [google] [report]
67583754

>>67583745
>youtube """4k"""
yikes

>> No.67583755

>>67583095
It's not better quality-wise, it's only better because they take a tenth of the time to encode.

>> No.67583760

>>67583730
let me guess, you watch korean dog-eating movies?

>> No.67583762

wow 4k 60fps works muuuuch smoother now on my 2200G

>> No.67583764

>>67583760
Wrong again. Kill yourself anyway.

>> No.67583767

>>67583762
because it's even more bitstarved

>> No.67583792

>>67583755
It's better because x265 is still a bug ridden piece of shit

>> No.67583794

>>67583767
but it seem to look slightly sharper than what they currently use.

especially in moving scenes. the current youtube algorythm swallows so much details when shit is moving it's not even funny

>> No.67583808

>>67583794
>inb4 it's disgusting interpolation

>> No.67583815

>>67583641
Different encoders are tuned for different purposes. x264 is not as good at proprietary H.264 encoders at >BD spec bitrates because it was not tuned to be as good at >30-40 Mbps transparency at 1080p. That is why very few professionally authored BDs use x264 and choose pro solutions when encoding BDs from studio masters. The BD spec also forces rate control to not exceed a certain bitrate with the H.264 levels setting for hardware decoders, which x264 is not naturally tuned for. It's not uncommon to see >50 Mbps spikes unless you specifically tell H.264 to obey those constraints. x264 is tuned for transparency from BD/DVD sources while preserving grain / minimal animation from lower frame rate movement with the right settings, with reasonable filesizes.

x265 is not as good as proprietary H.265 encoders at preserving details or grain, and UHD Blu-rays are always encoded with a proprietary H.265 encoder to fix those issues. x265 is also tuned for lower quality encodes from BD/DVD/Web sources that end up delivering superior quality to x264 encoded sources only at low bitrates. It does so by smearing grain and taking shortcuts on low framerate animation to allow the bitrate to drop below the minimally acceptable bitrate that x264 would use for anything resembling the source. If you ramp up the bitrate on both x265 and x264 you can easily see that x265 quality levels off really quick while x264 only gets better with more bitrate. At a reasonable bitrate and not mini-sized encodes x264 eventually starts winning because of x265's shortcomings. This wasn't the case during the transition from xvid to x264 since the x264 quality ramp-up was faster and continously achieved a higher level of perceived quality than xvid at higher bitrates.

>> No.67583818

>>67583808
why do you complain?

it's not like youtube will ever be able to make a source playback, this would take ages to load for some people and would kill the platform

>> No.67583825

>>67583808
Interpolation only adds things where there isn't. It's the compression that swallows small movement.

>> No.67583850

>>67583815
I would clean the sweat off your balls

>> No.67583898

>>67583815
On the subject of rate control, if that were the case for x264, then why is it the prefered encoder for youtube? Surely, a strict rate control would be beneficial for streaming as it was for blu-ray

>> No.67583903

>>67583377
Eh, I'll wait for the next gen. 7 nm and AV1 encode/decode in hardwaree.

>> No.67583945

>>67583898
YouTube bitstarves their H.264 encodes so much the rate control spike becomes much less of an issue. It usually tends to happen more often with slower settings and higher quality preferences - not to mention Google can easily set the x264 parameters to obey constraints since they aren't looking for transparency. Also, was it confirmed that Google uses x264 instead of their in-house encoder? I would imagine they would encode with GPUs or specific hardware encoders so a custom H.264 encoder would better suit their needs.

>> No.67584158

>>67583395
Anime website

>> No.67584269

>>67583754
>that picture
if it doesn't end in snuff: sauce?
if it does end in snuff: no way fag.

>> No.67584405
File: 2.30 MB, 600x428, 1518513082985.gif [View same] [iqdb] [saucenao] [google] [report]
67584405

>>67583648
Top jej.

>> No.67584407
File: 47 KB, 1010x620, 117646-Ozer-AV1-Fig2.png-ORG.png [View same] [iqdb] [saucenao] [google] [report]
67584407

AV1 is so good

>> No.67584551

>>67583136
>h265 despite being like half the size as h264 and showing no difference in fucking anime.
Only for lowbitrate shit encodes, for anything else you get better quality per bit with x264 10-bit.

h265 is also a legacy codec at this stage, if the 'scene' ever leaves h264 it will be for AV1 or a successor.

>> No.67584646

>>67582848
>John Oliver
Could Google be any more onions.

That aside, I've been waiting for AV1 for a long time. It's good to see some progress.

>> No.67584654

>>67583648
Can't wait to put white boys like you in concentration camps

>> No.67584668

>>67584646
Did it just replace "S O Y" to onions? Wtf

>> No.67584745

>>67584654
Accuse us of being rascist and wanting to exterminate an entire group of people yet simultaneously are rascist and want to exterminate an entire group of people.

Ok I guess.

>> No.67584811

>>67582848
>every 4K video (on my 4K 27" IPS monitor) looks blurry and unsharp as fuck

Good thing I didn't wait to encode my TV-shows and Movies with AV1 KEK

H.265 for lyfe

>> No.67584822

>>67584745
Bruh there ain't no racism against wypipo and you guys obviously deserve it.

>> No.67584831

>>67584811

>H.265 for lyfe
>It's dead in the water
LoL

>> No.67584843
File: 282 KB, 692x913, 1524332329797.jpg [View same] [iqdb] [saucenao] [google] [report]
67584843

>using anything but based mpeg2

>> No.67584871

>>67583136
>They haven't adopted h265 despite being like half the size as h264
no, it is about 10% smaller only

and size isn't the problem with animes

>> No.67584875

>>67584822
>Fight fire with fire.
Ok.

>> No.67584878

>>67584668
Newfag

>> No.67584904

>>67584878
Been here since 2012, I haven't ever noticed that.

>> No.67584922
File: 537 KB, 640x360, 1536267208548.gif [View same] [iqdb] [saucenao] [google] [report]
67584922

>>67583395
Anime website

>> No.67584923

>>67584904
>2012
You're eternal newfag.

>> No.67584924

>>67584875
>replying to low quality bait
back to your containment subreddit

>> No.67584966

>>67584405
>doki doki reddit club

>> No.67585715

>>67582848
what is this and why should I care?

>> No.67585737

>>67583815
>x265 is pajeetware
more news at 11

>> No.67585822

>>67583275
what a massive amount of waste you're encouraging there

just you can spend perhaps twice the time on encoding and get half the file-size or everyone can waste twice the bandwidth and storage space because of you stupid.

if you can get half or just 2/3 by doubling the encoding time then it's totally worth it

also, you clearly haven't paid much attention to storage prices. it's pretty much been flat per gigabyte the last decade, it ain't getting cheaper. a 3 TB HDD costs about the same now as it did 10 years ago.

>> No.67585846

>>67584811
There has been no change to 4K videos. Only very low resolutions use AV1, and only on very recent browsers.
>Using a supported browser and choosing the 'Prefer AV1 for SD' setting on youtube.com/testtube, you should see AV1 used for these videos when playing less than 480p, switching to VP9 for higher resolutions.
Did NOBODY itt actually read this?

>> No.67585902

>>67585822
Time is the most precious resource

>> No.67585907

Why does VLC claim AV1 decode support?
It literally can't decode ANY AV1 file.

Last bug tracker post claims it's because there is no standardized mapping for MKV/MP4, but i'm pretty sure MP4 mapping was finalized already, considering that's what youtube is using for their AV1 stuff already.

>> No.67585914

>>67585846
This board is just the shopping guide for /v/
Pathetic really

>> No.67585918
File: 25 KB, 479x156, use this.png [View same] [iqdb] [saucenao] [google] [report]
67585918

>>67584269

>> No.67585926

>>67585907
Why do you use VLC in 2018

>> No.67585936

>>67585846
They have AV1 for the new childish gambino music video up to 1080p. I downloaded the 720p and 1080p AV1 copies yesterday.

>>67585926
I mainly use MPV, but I still want to compare performance between the two.

>> No.67586051
File: 86 KB, 1599x611, 2018-09-13 09_49_28.png [View same] [iqdb] [saucenao] [google] [report]
67586051

Not really much bandwidth savings, at least not on the childish gambino video.

>> No.67586098

>>67586051
Now multiply it for 8 Ettabyte a month

>> No.67586243

>>67586098
If we take the 720p version as an example, we get 26.3MB and 30.5MB for AV1 and x264 respectively.

Lets say the video gets 40,000,000 views

26.3 * 40M = 1,052,000,000MB. Convert to usable unit, and that's 1052TB of bandwidth.

30.5 * 40M = 1,220,000,000MB. Converting to TB gives us 1220TB.

So over 40 million views google saves ~168TB in bandwidth.

Once you account for the encode time and CPU horsepower required, it really only makes sense to use AV1 on only the most popular videos (like music videos) that will almost assuredly get 10's of millions of views.

A youtuber who averages 100,000-1,000,000 views per video would really have no need for AV1, it would take too long to encode and by the time the encode is done, most of the views already happened and you wasted a shit ton of CPU time to encode something that will barely save any bandwidth over it's lifetime.

>> No.67586302

>>67584745
ayo keep yo mouth shut whitboi unless you want to work extra hours in mine

>> No.67586309
File: 8 KB, 224x224, 1536438560080.jpg [View same] [iqdb] [saucenao] [google] [report]
67586309

>>67583395
cheer up

>> No.67586316

>>67586243
> it would take too long to encode
Eh? Based on what? They can even only put the video online once it's encoded, but just as likely they might have a distributed encoder for their encoding cloud...?

>> No.67586350
File: 24 KB, 494x195, 2018-09-13 10_15_40.png [View same] [iqdb] [saucenao] [google] [report]
67586350

>>67586316
Well it took SEVERAL hours for the low res AV1 versions to be put up, and it wasn't until a few days later the 1080p version went up.


That's almost certainly due to AV1 encoding speed, even using a massive cloud, it takes for fucking ever.


It took a quad core Xeon V5 (a mobile workstation CPU, but still respectable) over 62 hours to encode a 5 second AV1 clip. Yes, 62 hours for a 5 second encode.

>> No.67586413
File: 126 KB, 1280x720, 666.jpg [View same] [iqdb] [saucenao] [google] [report]
67586413

H.264 10bit reigns supreme

>> No.67586437

>>67586350
>Yes, 62 hours for a 5 second encode.
Bullshit, AV1 encodes 720p video at 6-8 FPM on typical Core i5 with --cpu-used=1

>> No.67586466

>>67586437
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-First-Look-127133.aspx

>> No.67586625

>>67582848
It shows as not compatible, even though I'm using the latest nightly.

>> No.67586648

>>67586466
Hmm, they used --cpu-used=0.
Even with VP9 it was unadvised and in fact could produce worse results than --cpu-used=1, although I'm not sure if it's still valid with AV1.

>> No.67586730

>>67586350
>62 hours for a 5 second-long clip
That's ludicrous.

>> No.67587197

>What did we learn about testing? You should focus your tests on the data rates at which your video will most likely be deployed. At this point, H.264 and any newer codec should produce near perfect quality at 6 Mbps, making that data rate irrelevant for forward-looking testing. HEVC and VP9 take the near perfect quality level down to between 3.5Mbps to 4Mbps, and AV1 and future codecs should bring this down into the 2Mbps to 3.5Mbps range. For this reason, it makes the most sense to test in the range covered in the second round.

If this is for 1080p, any new codec improvements are literally just for big tech companies to save bandwidth. Storing "transparent" 1080p video in 6 Mbps is literally a non-issue for most people. Assuming you consume an average of 6 hrs of video a day, that's about 2.7 GB (5.4 GB if you want backup), netting 80 GB (160 GB) per month or less than 1 TB (2 TB) per year. Even with the most shit data caps that's easily doable, and to store that data costs less than a streaming subscription per year.

>> No.67587235

>>67587197
That's for 1 hr a day, but for 6 it's still just 5.5 TB (11 TB) per year, which is still a non-issue.

>> No.67587245

>>67587197
Of course it is about THEM saving bandwidth

It was never for the consumer

>> No.67587420

>>67587235
>>67587197
These still are *good* percentages, and also decent absolute numbers.

Most improvements aren't "100% extra". And yet we still managed to make extreme progress by compounding those 5-10% gains that we could achieve.

We just need better hardware/software encoders for AV1 so everyone can encode. Hypothetically the AV1 consortium designed AV1 so these would be possible to manufacture as commodity type hardware [like GPU]. We'll see.

>> No.67587537

>>67583256
Don't forget Hollywood.

>> No.67587578

>>67587420
I get it that it's an improvement. Most streaming sites like YouTube and such will get better quality for lower bandwidth. It's just not an issue for my use case since I'd rather consume content that's transparent than whatever bitrate threshold the new codec allows big companies to use so that the quality doesn't completely fall apart.

BDs cap out at about H.264 25-40 Mbps. UHD Blu-rays are H.265 but have about 55-80 Mbps, with most on the lower side. The end goal of all these codecs is so that companies can slash the quality to shit, save bandwidth, institute bandwidth caps, kill physical media, and then tell you that you're getting a good deal and how great it looks. Netflix 1080p is bitstarved as shit, so when they rolled out 4K everyone lost their shit over it when it looks about the same as a properly transparent 1080p from Blu-ray. A properly transparent 4K from a UHD Blu-ray would blow it out of the water.

Also, 4K Netflix support is limited to certain hardware configurations that support their DRM, or on "smart TVs" that are basically some panel + decoding ASIC for certain formats that you paid for. Don't forget, you have to pay more for that newer model ASIC so that it supports the newer shit, and they're never fully featured anyway. Most of these ASICs have restrictions on what they can play in hardware, which benefits only the tech companies since ASICs can't decode shit in software. They want local media and user control over media to go away within the next decade.

>> No.67587830

>>67587578
Local media is ALREADY dead for the average normalfag who doesn't pirate

BDs sales are plummeting

>> No.67587846

>>67583249
There are also 1080p videos (e.g. https://www.youtube.com/watch?v=F1B9Fk_SgI0), but right now even YT has to spend days to encode them, so it's still a rare sight.

>> No.67587850
File: 21 KB, 328x353, 1517483975801.jpg [View same] [iqdb] [saucenao] [google] [report]
67587850

>>67583275
>encoder takes 20 minutes more
>everyone that downloads saves 1-2 minutes of download
hmmm

>> No.67587869
File: 24 KB, 856x196, 2018-09-13 12_30_18.png [View same] [iqdb] [saucenao] [google] [report]
67587869

>>67587846
I'm not seeing the 1080p version anymore, though i downloaded it yesterday, so i know they had it there at one point.

>> No.67587896
File: 155 KB, 453x466, 1536511190579.png [View same] [iqdb] [saucenao] [google] [report]
67587896

How do I force yt to use av1 if possible?

>> No.67587923

>>67586648
At least for VP9 you're confusing it with the deadline option. -deadline good -cpu-used 0 should be preferred to -deadline best.

>> No.67587927

>>67587850
No you piece of shit
It takes like 7x the time of x264

>>67587896
>How do I force yt to use av1 if possible?
Read the goddamn FAQ on YouTube?
Literally op link you waste of air

>> No.67587930

Anyone who's watched one of their 1080p AV1 encodes, does it look substantially better than the old h264/vp9?

Youtube 1080p looks like a smeary pile of shit to me. Their 1440p and 4K encodes are a lot better, but most content is 1080.

If it looks the same and just has a slightly smaller filesize, why is everyone so excited?

>> No.67587950

>>67587930
>If it looks the same and just has a slightly smaller filesize, why is everyone so excited?

They are smelly neet who watch anime on phone and cry they can't watch hi10p

Which surprises me since most normalfags just stream anime or God forbid pay for Crunchyroll

>> No.67587997

>>67587927
> laptop can encode an anime in 264 in 25 minutes
> laptop can ended an anime in 265 in 31 minutes
You're full of shit

>> No.67588001

>>67587869
Very weird. I also just checked yesterday. No idea why they removed it.

>> No.67588024

>>67587923
Oh, you're right, thanks.

>> No.67588040

>>67587997
Check this table
>>67586350

>> No.67588066

>>67587930
Because we finally get a free video codec that isn't tied to fucking libvpx.

>>67587997
Posting encoding times without context is pretty pointless. What are your settings and what size do the resulting files have?

>> No.67588101

>>67588040
That chart is for a 5 second clip.

If we extrapolate that 5 second clip out over 24 minutes (which isn't particularly realistic, but meh, YOU wanted to use the chart). So for a 24 minute anime that would be ~1.4 hours for x264 and ~22.4 hours for x265

>> No.67588103

>>67588066
But it's really slow and apparently isn't useful for 4K. So it sounds pretty irrelevant to me.

>> No.67588115

>>67588103
>apparently isn't useful for 4K
says who?

it's MORE useful for 4k than anything else. It was literally designed to be the most efficient at resolutions beyond 1080p.

>> No.67588119
File: 17 KB, 605x241, 117645-Ozer-AV1-Table1.png-ORG.png [View same] [iqdb] [saucenao] [google] [report]
67588119

Ahhh c'mon man, I'm only going to be alive for 80-100 years max and I have like 20 4K blu-ray remuxes sitting on a raid 10 4TB setup.

>> No.67588121

>>67588115
Well they're trialling it at 360p not 2160p. I assume that's for a reason. And if it's obnoxiously slow at 1080p then it's going to be a ton slower again at 4K. At that point it seems unlikely that the bandwidth savings would be worth the CPU time. Maybe on videos that get 50 million views, but remember that most people don't watch at 4K at all. I doubt any 4K content is getting that kind of view count.

>> No.67588139

>>67588121
Wait 2 years and then look at it. I bet 4k will still be untenable for most home users, but Amazon, netflix, etc have no issue leaving a cluster of servers encoding for a day or two if it saves them 100TB+ every year.

>> No.67588143 [DELETED] 

So I got nightly 65 and set "media.av1.enabled" to true but youtube still claims my browser is not supported, what am I doing wrong?

>> No.67588144

So I got nightly 64.0a1 (2018-09-13) and set "media.av1.enabled" to true but youtube still claims my browser is not supported, what am I doing wrong?

>> No.67588145

>>67588144
try chrome, it IS jewgle afterall.

>> No.67588147

>>67588145
Works in chrome just fine, weird.

>> No.67588153

>>67588147
Not shocked

>> No.67588163

>>67586051
They are intentionally high bandwidth streams, for performance testing purposes. They should look better than the VP9 encodes in theory.

>> No.67588170

>>67588143
>>67588144
Going on YouTube for a start

>> No.67588174

>>67588103
Encoder optimization takes a long time. It will definitely be slower to encode than HEVC or VP9, but the difference shouldn't be as drastic as it is right now.
Of course it could also end in a total disaster (at least for normal users). It's just too soon to judge AV1's future at this point, but already having an alternative to libaom in rav1e is a good first step, so I keep being optimistic.

>> No.67588216

>>67588163
>They are intentionally high bandwidth streams, for performance testing purposes
This, they say as much in the playlist description. The difference in encoding quality between the h264 and av1 streams is very noticeable thanks to that.

>>67587869
Some of the videos in the OP playlist still have 1080p versions.

>> No.67588269

ytdl support when?

>> No.67588294

>>67588269
already there

>> No.67588300

>>67588269
Since days ago

>> No.67588318

>>67588144
There's a fix that just landed in Firefox, you have to wait until the next Nightly (which should be later today) https://bugzilla.mozilla.org/show_bug.cgi?id=1490877

>> No.67588321

>>67587869
what application is that

>> No.67588331

>>67588321
SVPtube2, included with SVP 4 Pro.

It pops up with any youtube video, and works on various other sites that youtube-DL works with.

>> No.67588400

>>67582848
No support on waterfox REEE

>> No.67588410

>>67587578
> Netflix
This is probably relevant in the USA. Not worth all that much consideration here.

What should get better is YT, pornhub, bittorrent and such.

> They want local media and user control over media to go away within the next decade.
The media copyright lobby always wanted that and unlimited policing and unlimited expiration dates.

I hope we'll manage to inform people that the deal is supposed to be that copyright lasts only for a few years [maybe just 5 or 12 or something] and bring that back to sanity rather than going more down the route to endless profits and power that the media copyright lobby wants us to go.

>> No.67588448
File: 96 KB, 1069x750, screenshot_2018-09-13T19-28-08.png [View same] [iqdb] [saucenao] [google] [report]
67588448

Does not works with firefox nightly on linux.
I'm waiting for chrome 70 in the repos.

>> No.67588457

>>675834764
He watches african premiere releases and bollywood hits.

>> No.67588468

>>67583275
>ignoring download time and bandwidth
Retard

>> No.67588534
File: 246 KB, 1920x1080, Screenshot_20180913-202704.png [View same] [iqdb] [saucenao] [google] [report]
67588534

>>67588448
I checked with newest youtube-dl the AV1 files are bigger

>> No.67588555

I have media.av1.enabled set to true on FF and it's not working.

>> No.67588582

>>67588534
see
>>67588163
>>67588216

>> No.67588593

>>67588555
Did you tried restarting?

>> No.67588594

>>67588555
As has been said, use chrome, FF aint working for most people from what I can determine.

>> No.67588622

>>67585715
I don't know either, its being promoted really hard though.

>> No.67588640

>>67588593
I did but whatever, I don't really care anyway

>> No.67588653

>>67588555
Same. Using Nightly and have the preference set, but it still says this browser isn't supported. Fucking kikes trying to make me use Chrome.

>> No.67588669

>>67582848
what's the benefit?

>> No.67588683

>>67588669
>what's the benefit?
The Jews overlods will save money by serving you bitstarved videos

>> No.67588702

>>67588653
>>67588593
kek, I tried watching a VP1 video and it was stuttering like crazy.
So this is the power of the leading tech company...

>> No.67588714

>>67588683
oh phew... I was very worried about jews overlods not making enough money.

>> No.67588734

>>67584668
It's been doing that for almost a year now, idiot.

>> No.67588739

>>67583136
Do Phones have hardware decoders for it yet?

>> No.67588777
File: 608 KB, 1280x720, 123.jpg [View same] [iqdb] [saucenao] [google] [report]
67588777

>>67588653
use mpv

>> No.67588836

I'm getting a lot of dropped frames on mpv, is my pc shit or should I wait for a new mpv update?

>> No.67588844

i'm using arch repo as youtube-dl source. how often it is updated?

>> No.67588847

Can't wait for AV1 hardware decoding

>> No.67588915

Why aren't there any vector-based codecs?

>> No.67588969

>>67588844
Last update was on the 1st of september, Youtube-DL was updated for AV1 4 days ago. So probably in the next few days.

>> No.67589185

Just tested with two computers. Old Lenovo Ideapad S210 drops about 1 frame per second on 480p, on 720p a few frames more and 1080p is unwatchable. Second machine, Ryzen 1600, shows 480p and 720p nicely but 1080p stutters a bit. CPU usage is about 50% on Ideapad and 6-8% on Ryzen. I used ffplay 4.0.2.

>> No.67589321
File: 57 KB, 736x881, makoto.jpg [View same] [iqdb] [saucenao] [google] [report]
67589321

>>67583415
here you are, have some cute tomboy

>> No.67589355

supposedly vlc 4 has a very fast av1 decoder, has anyone with a shitty pc tried it?

>> No.67589390

>>67589355
I'm gonna try it right now. I'll report back findings soon.

>> No.67589523

>>67589355
>vlc 4
Much faster than MPV.
MPV was hitting 12-15% CPU use for me at 720p

VLC 4 hits 8-10%.

MPV when trying 1080p AV1 would hit 20% CPU use, but would stutter and drop frames.

With VLC 4 1080p AV1 uses 15% CPU use but has no frame skipping or stutters.

>> No.67589527

>>67583136
You know that x264 would never be a thing (like 10-bit) if it weren't for animefags, don't you?

>>67583755
It is, tho.
x265 do a pretty worse job at high-action scene. Which means macroblocks and artifacts.
Not really hard to test it by yourself, if you ever want to.

>> No.67589565

>>67589523
Maybe you have some fancy upscaling config for mpv?
Do you compile from git?

>> No.67589594

>nightly 64
>WebRender enabled by default for Desktop NVIDIA GPUs on Windows 10
Noticeable?

>> No.67589601

>>67589565
My MPV is configured through SVP, but I didn't have SVP running when playing it back, so not sure exactly what they would do since it isn't frame interpolating.

>> No.67589638

>>67589355
>>67589390
Okay after a short bit of testing, here are my findings. All three programs I've tried drop frames. FFplay performs the worst to the point where it outright freezes. mpv performs the second best but drops about between 2-8 frames per second. VLC 4's nightly from today does indeed perform the best for me, only dropping between 1-4 FPS. Decoding seems to only utilize one core on each program tested. Tested using this video https://www.youtube.com/watch?v=F1B9Fk_SgI0 at 720p with an AMD A8-6500 CPU from 2013.

I'm just gonna wait until Nvidia updates their drivers to provide accelerated decoding support for AV1. For now it is clear the codec can't really run well on a CPU this old.

>> No.67589737

>>67589638
>For now it is clear the codec can't really run well on a CPU this old.
To be fair, I believe currently it's decode is only running on a single CPU core no matter your hardware.

In MPV @ 1080p it keeps sending a single one of my 5820k cores to 100% then back to 50-80, then back to 100% and it stutters.
With VLC 4 @ 1080p it is steadily 30-70% on the same single core but it doesn't hit 100% use on that core and it doesn't stutter at all or drop frames.


When/if multicore decoding gets supported it should allow a wider range of older hardware the ability to decode without dropping frames.

>> No.67589754

Do you need to do anything special in order to run it on youtube ?
I'm still getting VP9 when I look at the video stats.
Also are all video's going to be recoded to AV1 now ?

>> No.67589786

>>67589754
read the page from the OP
>https://www.youtube.com/testtube
> For full support, use Chrome 70 or newer, or Firefox 63 or newer with the media.av1.enabled pref set.

Though many people in this thread report firefox doesn't work even with the newest nightly. But chrome does.

>Also are all video's going to be recoded to AV1 now ?
No, encoding time is far too long.

>> No.67589815

>>67589786
>Though many people in this thread report firefox doesn't work even with the newest nightly. But chrome does.
I Just updated chrome but it only took me to 69, So i'll have to wait a while I guess.

>No, encoding time is far too long.
That's a shame

>> No.67589826

>>67589786
Next Firefox Nightly will have the fix. The issue is that Firefox is still only reporting support for the beta AV1 MIME type instead of the final MIME type.

>> No.67589837

>>67589754
Not sure about Chrome but if you download the videos with yt-dl you can open and play them with Firefox Nightly. Changing the settings on Youtube itself doesn't seem to work.

Also don't forget to enable av1 encoding in about:config

>> No.67589862
File: 9 KB, 624x123, 2018-09-13 15_58_41.png [View same] [iqdb] [saucenao] [google] [report]
67589862

>>67589815
>I Just updated chrome but it only took me to 69
Because 70+ is the nightly. Chrome canary.

>> No.67589874

>>67589786
You can play the video in current Nightly if you downloaded it with youtube-dl. Just open it in Firefox like a regular file.

>> No.67589878

>>67589862
ah that could be it

>> No.67589900
File: 21 KB, 683x291, 2018-09-13 16_01_22.png [View same] [iqdb] [saucenao] [google] [report]
67589900

>> No.67589968
File: 161 KB, 625x560, bait jojo.jpg [View same] [iqdb] [saucenao] [google] [report]
67589968

>>67583395
Anime website

>> No.67589990

>>67583395
reddit as fuck... cringe...

>> No.67589999

>>67583476
>gets google to save bandwith aka save billions
So its a bad thing.

>> No.67590009

>>67589999
>>gets google to save bandwith aka save billions
>So its a bad thing.
Indeed

>> No.67590021

Make sure to buy new hardware for AV1 playback so we can save money on bandwidth goy!

>> No.67590098
File: 36 KB, 1190x281, 2018-09-13 16_15_51.png [View same] [iqdb] [saucenao] [google] [report]
67590098

>>67582848
>Playlist of videos:
>https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS
Halo infinite announcement trailer really has a significant bitrate for the AV1 stuff, overshooting the x264 encode bitrate by a fair margin.

>> No.67590177

>/g/ actually gave serious replies to the people who think media of panning cartoon drawn backshots with 4 frame mouth movements needs a higher quality formats.

its like that one audiophile picture of that old with $100k system setup listening to 90bps nig music

>> No.67590199

>>67590177
Ask me how I know you were born after 1990

>> No.67590327

>>67590177
>/g/ is actually interested in the advancement of technology
I know for some people this is a weird concept, but there's more to technology than screen/neofetch threads.

>> No.67590344

>>67590098
See: >>67588163
They likely just want to get analytics out of how well people's computers can handle the videos right now, so they have a good idea of when to and not to load AV1 for users.

>> No.67590359

>>67583160
And they're bad.

>> No.67590360

>>67590344
They've really spread the gamut, they've got AV1 streams below x264, bitrate, almost identical bitrate, a bit above x264 bitrate, fairly high above x264 bitrate, then WAY beyond normal x264 bitrate.

I agree, they're seeing how different hardware can playback different bitrates.

>> No.67590374 [DELETED] 

>>67583136
https://bitbucket.org/multicoreware/x265/issues/266/banding-problem

>> No.67590554
File: 41 KB, 620x350, johnny-carson-and-ed-mcmahon.jpg [View same] [iqdb] [saucenao] [google] [report]
67590554

AV1 encoding is soooo slow...
How slow is it?
It's so slow the Youtube example posted the first time this thread was on /g/ like a week ago, when the highest res AV1 was 480p, is finally available as 720p.
https://www.youtube.com/watch?v=F1B9Fk_SgI0

>> No.67590556

>>67590327
thats not what my post implied. read it again but carefully

>> No.67590580

If it's not being used on HDBits, it's shit.

>> No.67591441
File: 1.91 MB, 1920x1080, [ReinForce] Shigatsu wa Kimi no Uso - 18 (BDRip 1920x1080 x264 FLAC).mkv_snapshot_07.24_[2018.09.11_21.44.15].png [View same] [iqdb] [saucenao] [google] [report]
67591441

>tfw don't know what any of these buzzwords mean

>> No.67592578

>>67589874
Let MPV do the playback

>> No.67592622

When I try to playback with mpv or ffmpeg it doesn't work:

Error while decoding frame!
[ffmpeg/video] libaom-av1: Failed to decode frame: Bitstream not supported by this decoder
[ffmpeg/video] libaom-av1: Additional information: Buffer -1 does not contain a decoded frame
Error while decoding frame!
[ffmpeg/video] libaom-av1: Failed to decode frame: Corrupt frame detected
[ffmpeg/video] libaom-av1: Additional information: Keyframe / intra-only frame required to reset decoder state

I tried aom-1.0.0 and the latest git, both fail. What you guys are using to decode it?

>> No.67592638

>>67592622
Which video?

>> No.67592684

>>67589786
>Though many people in this thread report firefox doesn't work even with the newest nightly. But chrome does.
Firefox nightly had a bug that was fixed earlier today. If you don't build from source, wait until the next official build which should be out tomorrow.

>>67590554
The 720p and 1080p versions for that video were already up last Monday, but for some reason the 1080p version was deleted. Some anons (me included) downloaded it before that happened.

>> No.67592763

>firefox nightly
> AV1 decoding is not available on this browser yet

>> No.67592801

>>67592763
see >>67588318

>> No.67592824

>>67592801
Danke. I almost downloaded chome beta.

>> No.67592853

>>67592638
The childish gambino one d/l with youtube-dl

>> No.67592868

>>67592853
Make sure you have a recent ffmpeg, youtube-dl might have muxed it together incorrectly at the end.

>> No.67592949

>>67592622
updated ffmpeg

>> No.67592959

>>67592763
>>67588318
>>67592801
DL with youtube-dl and playback with MPV or VLC 4, why would you waste time with a web browser?

>> No.67592963
File: 417 KB, 847x720, 1536700407540.png [View same] [iqdb] [saucenao] [google] [report]
67592963

Does AV1 even support 7.1 surround sound or are we never going to get streaming videos with 7.1 surround sound.
t. Just installed Dolby Atmos

>> No.67592978

>>67592853
>>67592868
>>67592949
I have the latest y-dl and ffmpeg 4.0.2

$  ffmpeg -version 00:36:13
ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8 (GCC)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' --extra-ldflags='-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' --extra-cflags=' '--enable-libaom
libavutil 56. 14.100 / 56. 14.100
libavcodec 58. 18.100 / 58. 18.100
libavformat 58. 12.100 / 58. 12.100
libavdevice 58. 3.100 / 58. 3.100
libavfilter 7. 16.100 / 7. 16.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 1.100 / 5. 1.100
libswresample 3. 1.100 / 3. 1.100
libpostproc 55. 1.100 / 55. 1.100

>> No.67593001

>>67592868
>>67592949
>>67592978
What version of libaom do you have?

>> No.67593002

>>67592978
Use ffmpeg git head

>> No.67593009

>>67592963
AV1 is a video encoding format. It is not a container. Your like a boomer that asks about his "CPU" when talking about the entire computer. Fucking neo /g/.

>> No.67593012

>>67592978
did you try to stream or DL and then playback?

>> No.67593013

>>67592963
AV1 is a video encoding format, not a container.

>> No.67593023

>>67592963
>The absolute state of /g/

>> No.67593062

>>67592978
>ffmpeg 4.0.2
Use latest ffmpeg from git re-download the video using y-dl with it. ffmpeg 4 is old by now and probably muxing crap.

>> No.67593063

>>67593012
d/l then playback

I'll try FFMPEG head

>> No.67593103
File: 97 KB, 1460x732, file.png [View same] [iqdb] [saucenao] [google] [report]
67593103

>>67593063
werks on my machine

>> No.67593223

>>67593103
what's your version of libaom?

>> No.67593704

Compiled ffmpeg head and it's still not working :|

>> No.67594150

>>67593704
Use latest everything, mpv head with ffmpeg head, latest y-dl with ffmpeg head, etc, then delete all the videos you downloaded and created then redownload them. If that doesn't work then you're doing something wrong.

>> No.67594272

https://gist.github.com/sparrc/026ed9958502072dda749ba4e5879ee3
Googled as a verb this and just did the three sections one at a time using checkinstall to build 3 deb packages. That was yesterday and I noticed there's already another git commit on libaom as of this morning.

>> No.67594297
File: 1.61 MB, 500x281, gtfo.gif [View same] [iqdb] [saucenao] [google] [report]
67594297

>>67583354
if you're over 20 and still think kys meme is cool, you...

>> No.67594400
File: 154 KB, 360x360, sadwolf.gif [View same] [iqdb] [saucenao] [google] [report]
67594400

>>67583467
on one side, AV1 uses more brute strength than even HEVC, so it has a potential to improve compression actually, unlike VP9 which was just subpar copy. Also it has grain modelling, potentially nice feature. So it COULD be good.

on the other hand, it is massively overhyped by freetards and zealots that are autistic about somebody somewhere getting money from patent royalties although in practice it never hurt anything. These retards know nothing about video and just cheerlead whatever google or other me-too compression wannabe throws at them. They will merrily accept shit or claim it is state of the art, Or they will just fail to notice. The end result is that progress in video compression suffers because these shitters draw talent and money away from the better solutions - because instead of judging on merit, they just ideologically follow whoever waves the libre banner.

Problem is that the #2 freetard group never managed to write good encoding software or achieve anything (unlike the "money grubbing" MPEG), so there is a risk that the potential from #1 won't get realised.

>> No.67594456

>>67594400
>on the other hand, it is massively overhyped by freetards and zealots that are autistic about somebody somewhere getting money from patent royalties although in practice it never hurt anything.
The problem with HEVC is not that you have to pay, otherwise H264 would have not gotten the massive adoption it got. The problem is that you have to pay to like three or four different pools of patent holders, and even then you couldn't be sure you're good to go. So every big player that's not in the movie industry said fuck it and made their own codec with blackjack and hookers.

>> No.67594459

>>67594400
>unlike the "money grubbing" MPEG
Well, technically it was open source developors writing encoders for MPEG formats (x264).
Sodly now open-saucers all root for VP9/AV1, so for example HEVC suffered although it is superior to VP9. We'll see if anything good comes out of AV1, but Google never managed to write a good encoder. Neither did Xiph. Mozilla is completely new at it. Rav1eor libaom is not done by people with experience with x264 or even x265 or similar outlook. I expect the encoders will be failures much like libvpx.

>> No.67594507
File: 28 KB, 534x440, Horo.jpg [View same] [iqdb] [saucenao] [google] [report]
67594507

>>67594456
>The problem is that you have to pay to like three or four different pools of patent holders
I decode it with ffmpeg (LAV filters, VLC, MPV) and I never paid anything. I also can decode it with my TV which only had very modest price (the premium for it being smart VS plain display was ridiculously small).

This OMG you have to pay thing is such a bullshit and exactly that freetard crap I complained about.

It doesn't matter one small bit to us people. It only matters to money grubbing tech giants like amazon, netflix and google who have neough money anyway. You clueless freetard cheerleaders just enable those scrooges to push inferior technology on us and reap profits from it.

>> No.67594520

>>67594507
Can you be any more retarded, anon? I'm sure you can make the effort.

>> No.67594548
File: 131 KB, 285x287, 1437520119752.gif [View same] [iqdb] [saucenao] [google] [report]
67594548

>>67594520
Prove me wrong retard. The fact that you just called names without even trying to dispute anything only shows I am completely right. Cretin.

Enough wasting time on dummies for me, good night.

>> No.67594568

>>67594548
Good night, anon. Don't let the freetards in your closet eat you while you sleep.

>> No.67594580

So the future is pure cloud encoding???

>> No.67594745
File: 1.01 MB, 1920x1080, vlcsnap-2018-09-14-09h39m33s435.png [View same] [iqdb] [saucenao] [google] [report]
67594745

Halo Infinity 1080p

>> No.67595078

>>67594507
what waifu is that?

>> No.67595293

youtube-dl didn't pick up sound tracks until i updated to the latest git.

>> No.67595320

>>67595293
oh, wow, the perf on my T420 is really bad. the 1080p one drops more frames than it loads.

>> No.67595367

>>67595320
t420 can barely play youtube 1080p60fps when it uses x264

AV1 1080p would never play on that thing

>> No.67595534

>>67594150
>>67593704
I forgot I had an old version compiled in .local. It was superseeding the global package -_-

Only 6-7% CPU used, that's great.

>> No.67595616

>>67595367
yeah but then it's using 100% cpu. here it's barely using 15%.

>> No.67595658
File: 8 KB, 318x318, 1464879175360.jpg [View same] [iqdb] [saucenao] [google] [report]
67595658

>>67585902
>one encoder spends twice the time to encode a video
>everyone who downloads it spends half the time downloading

>> No.67595712

>>67595658
more like you save 30 seconds downloading and need twice the cpu power

>> No.67595735

AV1? What's wrong with GIF?

>> No.67595957

>>67589900
ya I'm sure all that money you save on data offsets having to buy an 8700k just to play fucking sd video

>> No.67596255

>>67586413
sauce plox

>> No.67597325

>>67583553
>Study what x265 does with the grain of 35mm film scanned anime.

You can tune x265 for film with --tune grain

>> No.67597406

>>67586350
HEVC encoding was pretty slow in the beginning too but people tend to forget that.

>> No.67597477

>>67597406
x265 is still shittier and slower than x264

>> No.67597585

>>67596255
whatanime.ga

>> No.67597693

>>67583136
Fuck off you bald midget

>> No.67597860

>>67583156
This

>> No.67597923

>>67597477
x265 is more efficient though. If you hate x265 so much, I would suggest you use VP9 as I like the quality of it more but the encode time is usually worse.

>> No.67597933

>>67588534
>AV1 files are bigger
Also better quality.

>> No.67597968

>>67582848
The logo is shit thus it's shit.

>> No.67597976

>>67583156
Imagine being such a pathetic piece of shit traitor that you literally volunteer to be an astroturfer and patrol websites like /g/ to counter "problematic" discussion

>> No.67597995

>>67597923
Neither is needed if you don't watch or encode bitstarved garbage. If the video's on a streaming site there's no need to encode anything, so just pick the newest codec. If you're encoding just double the bitrate and pick H.264. It's transparent at reasonable bitrates already, and sub 6 Mbps 1080p shouldn't be shared for people to watch.

>> No.67598018

>>67597976
You'll never be white, amerimutt.

>> No.67598030

>>67583156
t. communist kike talkshow host

>> No.67598049

>>67598018
Whiter than you, traitor piece of shit astroturfer

>> No.67598102

>>67597933
Aren't they just transcodes of the AVC 1080p version?

>> No.67598204

>>67598102
Everything viewed on youtube is a transcode of the source. What the source is can be anything, including H.264. Just depends on what the uploader uploads.

>> No.67598209

>>67585822
>a 3 TB HDD costs about the same now as it did 10 years ago.
u wot
prices have been flat for like.. 5 years tops.

>> No.67598219

>>67597995
>doing bitrate based encodes
>TM 2006
Just use CRF already and don't worry about the bitrate.

>> No.67598222

>>67598204
I thought they just junked the source after the first set of encodes for the end user.

>> No.67598278

>>67598049
https://www.youtube.com/watch?v=mLGPeXINe4A

>> No.67598349

>>67585822
>>67598209
https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/

>> No.67598368

>>67598222
No, they hold onto the original in anticipation of transcoding everything in the future to the next big thing. Like AV1 or VP9 years ago. There are ways to actually get your uploaded sources back from YT.

>> No.67598414

>>67598368
Theres no way you can rip the "lossless" files with youtube-dl, is there?

>> No.67598553

>>67598414
You have to be the uploader, as in logged into the account that uploaded it.

>> No.67598773

It's slow as molasses, hevc is still better.

>> No.67599238

>>67595616
Because the decoder is single core currently

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
Captcha
Action