/tech/ - Technology★

>>936698

Epic, you must be quite intelligent, posting xkcd comics and all! Too bad you have to go when summer comes to an end, we'll surely miss your valuable input.

>>936703

>he can't handle the truth

>>936697 (OP)

There was no (free and efficient) encoder for VP9.

By efficient I mean reaching at least the same ratio of (file size, quality, used watts) as in x264 but targeting VP9 bitstream.

Will there be one for AV1? Can it really be called free and open if the encoder is effectively not open for everybody?

If you don't fall for the 4K meme, x264 is already the best there is. The only reason to wait for something else would be indeed the royalty free aspect of AV1 and HDR support (and hardware decoding for 10-12bit, if you're a normie watching stuff on his jewphone).

I'm way more hyped for a replacement to JPEG and maybe PNG.

>>936708

AOMedia group behind AV1 is pushing hard to have even hardware based decoders ready on chipsets by 2020. It's much bigger interest group now than what was for VP8 and VP9.

>>936698

Do you even understand what topic is? Can you read? Are you that completely illiterate communist polish child? Fuck off.

>>936711

>maybe PNG

It's called FLIF

>>936697 (OP)

Nope because whatever happens AV1 will be late to the market. h265 is already out and already supported.

In 10 years when we're talking h266 maybe whatever else the free software community is working on will have a chance.

>>936714

Sadly, it's kind of abandoned (all the last commits are build system stuff).

>>936718

The problem is that it is who accepts the codec that matters. Look at who's behind AV1 (https://en.wikipedia.org/wiki/Alliance_for_Open_Media).

>>936697 (OP)

How does it perform for animation? I've always felt 2D animation would benefit from a custom compressor vs live action video.

Maybe a PNG-like compression format?

>>936723

>I've always felt 2D animation would benefit from a custom compressor vs live action video.

That's what tuning is for. x264 has `-tune animation`, for example.

AV1 will be a thing because the companies involved are terrified of having to pay streaming royalties.

Reminder that x264 is the encoder software, and h.264 is the codec.

Reminder that Xvid l produces better results than h.264 at Bluray rate (>2500 kbps).

Reminder that the .mkv container can virtually anything (including Xvid encoded video with multiple subltitles/audio streams).

Your codec choice will ultimately be dictated by Google and Apple. Is Joe Phone user very concerned about the codec that plays his videos? No. He doesn't know what that is. What incentive would Apple have to switch to AV1?

>>936730

>xvid better than x264

>MPEG-4 ASP better than MPEG-4 AVC

Why don't you try to prove your bullshit, brainlet?

>>936731

To help answer my own question, I found this.

https://www.cnet.com/news/apple-online-video-compression-av1/ Interesting.

>>936697 (OP)

There is plenty of reason to use other things. AV1 is great for ahead-of-time encoding, but the encoding performance is really fucking heavy. It's useless for real-time video (for streaming and video chat).

>>936723

Flattened animated .SVG

But many animators are still using frame-by-frame bitmaps.

>>936739

What you said has no value until the encoder is optimized. I mean, come on, the bitstream spec was frozen only 4 days ago.

>>936711

>If you don't fall for the 4K meme, x264 is already the best there is.

x264 is not that good, is the best because compatibility.

4K is not a joke, human eyes can focus their vision up to 7K IIRC, so 8K IS a joke and will be forever.

But yeah while I do admit official encoders suck ass compared to some actual torrent pros Like Grym or RARBG which can keep quality while reducing size by 17%, depending on the movie it will start to suck below from there but I've seen some good looking 1080p movies from BDRips at 4GB but they're usually light on special effects or cartoons.

x265 is slightly better though not as good as advertised maybe 33% tops.

vp8 is a joke, it looks like ass, even if you copy the freaking bitrate or render above it which makes me paranoid about AV1.

vp9 I haven't tried, I'm a poorfag and I'm afraid my shitty PC will implode.

The real fucking joke here is Level 6.2 for h.264, like, who thought of that, or they made it for x265 and they just realized they could use it for 264?

>>936713

>hardware based decoders

how about encoders?

>>936752

Encoders are a different story, they're actually useful.

There's a capture card market, but there isn't a decoder card market. Encoding is usually too heavy to be done in real time well, but hardware decoders in GPUs nowadays can make lossless video with good compression, and they benefit from being integrated into the GPU.

>>936748

>I honestly don't know why everything doesn't just use ffmpeg as its backend for playing video/audio. It's good, and it just works. Every unix-like OS tries to do its own snowflake thing but they can just use ffmpeg already.

Well I use Microshits Windows and while is true that ffmpeg can do pretty much all you need is really annoying to use, is better to have three GUIs (xmedia recode, mkvtoolnix and handbrake). Might seem like it's more of a hazzle at first but is easier to correct and spot user mistakes.

>>936753

>but hardware decoders in GPUs nowadays can make lossless video with good compression, and they benefit from being integrated into the GPU.

You mean workstation GPUs?

>>936735

The whole reason behind creating h.264 is to produce better results for low bitrate videos. Any other debatable improvement is just a bonus. H.265 at least adds something meaningful for high bitrate: HDR and 8K support. But h.264 is only good for collecting royalty fees if the video used commercially.

>>936737

SVG is a piece of shit format.

>>936755

ffmpeg is also a library for encoding and decoding.

A lot of video players like mpv and vlc use it as a backend, and the user doesn't need to touch the terminal program. What I'm saying is we have whatever faggoty way codecs work on Android, garbage like gstreamer and developers manually implementing every single codec they want their program to have.

When using a single thing for everything is a really fucking dumb idea like with Systemd it happens, but when there's only one true answer in a sea of trash as is the case with ffmpeg it doesn't become the norm. It's a fucked up world.

>>936757

No I mean every AMD/Intel/nVidia GPU in the last 5 years.

>>936704

>Real codec and mpeg was enough, why aren't people happy with that

>>936698

The key sentence in your pic is

<[…] We need to develop one universal standard that covers everyone's use cases.

That's a far cry from developing a new standard because the previous ones didn't fit your need or were burdened with patents. That said, Opus might have disproven the theory that it's impossible to develop a standard that covers 95% or more of people's use cases.

>>936720

>Alliance for Open Media

>Governing members: Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel, Microsoft, Mozilla, Netflix, Nvidia

>General members: Adobe, Allegro DVT, AMD*, Amlogic, Argon Design, Ateme, BBC Research & Development, Bitmovin, Broadcom, Chips&Media, Hulu, Ittiam, iQiyi, NGCodec, Polycom, Realtek, Sigma Designs, Socionext, VeriSilicon, VideoLAN, Vidyo, Vimeo, Xilinx

That's a lot of pozzed companies and orgs right there.

>>936748

/thread

>>936760

Even worse, you can embed JS inside SVG: https://www.safaribooksonline.com/library/view/javascript-cookbook/9781449390211/ch15s05.html

>>936748

Really, I just wish the entire world could be like the anime rip scene: Fresh new codecs whenever computers get faster, new resolutions, chroma formats, etc.

>>936760

Sure, SVG is corpulent XML "human readable" bloat that has to be compressed separately, and it has (OPTIONAL) stupid features like scripting and remote transclusion, but it's still the only widely supported format to kill off the cancer of gratuitous bitmap images, especially now that Flash is dead.

>>936761

>developers manually implementing every single codec they want their program to have.

I guess because some of those codecs have royalties (like almost every MPEG codec), if you're doing some freeware app like ffmpeg itself then there's no trouble but if you wanna be hosted in an appstore or have legit (not scammy) ads to win shekels and shit then you have to invest and be careful with what you put in there and that means adding codec by codec as you grow making sure having the most compatible ones scratched down first. Besides big companies love it as they can be smug about their devices having more codecs than the competition Buy a good android box with VLC at $100, not that Roku bullshit.

>>936728

>AV1 will be a thing because the companies involved are terrified of having to pay streaming royalties.

This, Netflix already uses VP9 for their own shows in 4K and x265 for every other thing. So I can see them swapping to AV1 the second is out if they haven't started yet.

>>936775

Few years ago I've read about Sharp Extended Vector Animation format (.eva) which had some very good properties svg still lacks. I don't know what happened, can't find anything about it today. Maybe some japanese anon here knows more about it...

>>936790

>Why does every retard encode anime in 10 bit color when not a single studio has ever put out 10 bit color anime?

FUCKING THIS

Nothing fuels my insides like having to recode an episode for 70 minutes just because the retard put it in 10-bit and I can't watch it on my big screen.

>>936790

>Why does every retard encode anime in 10 bit color

https://gist.github.com/l4n9th4n9/4459997

tl;dr: Because it increases compression efficiency even for 8-bit content, especially flat/gradient-heavy/banding-sensitive content such as anime.

>When is 4:4:4 chroma subsampling becoming the standard

Couldn't agree more. Using simple chroma subsampling (just delete entire lines!) inside of a lossy image encoder is just as ridiculous as if we were still doing interlaced-scan. It made sense in the analog days, but it's totally superfluous today.

On a related note, though, even the preliminary step in a 4:4:4 YCbCr encoder of switching colorspace is typically done in a fashion that needlessly throws away heaps of bit-depth in all three channels, just because of a need to save RAM in encoders during the 1980s.

>HDR supposedly tells the display what the black and white averages are and adjusts the screen's brightness to better display each frame

No, HDR actually dedicates additional bits to encode extra "whiter than white" and "blacker than black" tones/shades so that material can adjust to your postprocessing chain, display device, and viewing environment, without clipping.

>>936794

Only problem is h264 is too blurry to preserve sharp patterns, even at bluray bitrates, any grain generally being compression artifacts. Leave the debanding to be done by the player. This is misinfo spread by "golden-eyed" people with no pseudovisual or visual simulation benchmarks to back it up. Any and all compression improvements come from the encoder's limits being extended and features being added by the profile, and this is also why new profiles are not backwards compatible. At most they have a shitty video player that can't do debanding in real time and they looked at the image they proudly smeared with vaseline and thought "Hey, I don't see banding!".

>HDR actually dedicates additional bits to encode extra "whiter than white" and "blacker than black" tones/shades so that material can adjust to your postprocessing chain, display device, and viewing environment, without clipping.

That's just a wider color gamut, which is an obligatory part of the "HDR10 Media Profile". The poo-in-da-loo insanity is the part where it needs to specifically tell the display the brightness average of each frame, when the screen is displaying the frame and can calculate it alone without requiring any adaptation on the film maker's side.

That's where "HDR+" by samsung comes in. They realized the obvious, that they can just let the monitor do that alone and play back any material ever in "HDR", and they released this new cool marketing babble that basically means the monitor is calculating brightness averages in real time instead of relying on some stupid metadata baked in.

>>936792

Chances are even at 8 bit color if the profile is hi10p it would still be incompatible with your screen. The profile is more than just allowing people to use a higher bit depth.

>>936804

>Only problem is h264 is too blurry to preserve sharp patterns

You can disable deblocking without problems. You xvid fanboys never fail to amuse me, thinking x264 is the same as ten years ago. Protip: it's not, it doesn't care about retarded metrics like PSNR since a long time now (and defaults to deblock=1:1 now).

>Any and all compression improvements come from the encoder's limits being extended and features being added by the profile

You clearly don't know shit. The problem is that x264's internal precision is tied to the bit depth; internal precision used when computing the motion vectors.

Honestly, all of your complaints are the ones x264 users say about x265 and its SAO retardation.

>>936792

Kill yourself for being that ignorant on a technology board, please.

>>936818

To add a bit more, this thread on doom9 is pretty good https://forum.doom9.org/archive/index.php/t-163182.html (I used to use -3:-3, but I only force it to -1:-1 for cel anime these days).

>>936788

Thanks for the Wikipedia link, it was really-really helpful and answered everything why was it discontinued...

>>936830

No need to be a sarcastic prick I think.

No idea, external links are dead and there isn't a Japanese Wiki article despite the alleged popularity, not even jap Youtube videos.

>>936804

>h264 is too blurry to preserve sharp patterns

Read the link I gave you again. The key point is that h.264 can store sharp fine patterns such as dithering, but it works best with smooth gradients and flat colors. By interpolating 8-bit dither into 10-bit gradients, it allows the encoder to produce smaller files of equivalent size.

>That's just a wider color gamut

No, it's a nonlinear colorspace. Think of the way a meatspace HDR photograph works, taking multiple exposures of the same scene, but with the iris dilated to different f-stops unless you're using a lightfield camera, but that's beside the point. That isn't just relatively "brighter" or "darker", it corresponds precisely to certain absolute levels of illumination in the actual scene.

>"HDR+" by samsung

...is the color equivalent of HD blowups, 24Hz-120Hz smoothmotion, surround spatialization, bass boost, etc. Missing bits can't be magicked up from thin air.

>>936818

>You xvid fanboys

Not an Xvid fanboy, but the situation for HIGH BITRATE* videos is something like this:

Buy disks and pick a lossless codec.

Pick Xvid if you are sane.

Pick h.264 if you want to require asic for playback/encoding, want to use the advanced settings for every scene differently (which most users don't do it), or want to pay royalty fees

Pick VP9 if you want to hammer someone's hardware.

Pick VP8 never.

*With high bitrate I mean the quality from the original video source is insensible (not just small).

>>936844

Sorry, pick VP8 and VP9 if you use your browser as a video player.

>>936844

Now, I suggest you prove your claims, with a recent enough build of x264. What you said WAS true.

>>936737

>>936748

>decoding on hardware level is the devil!!!!11

Baking in support for certain codecs inside SoCs and chipsets has been done for a long time, it's nothing new, your GPU supports some formats already (most likely h264). It helps with battery life by making it more efficient which is why it's crucial on mobile chips. Expanding encode/decode to AV1 is not a bad thing at all.

>>937084

It's a retarded practice that needs to die. Including hierarchical support for features common to various popular codecs, along with API access to build codecs that use it, is somewhat acceptable. But just dumping an entire bitstream in, getting a fully decompressed one out, and puking up your guts if something as tiny as a profile-level feature changes, dumping you on your ass back in pure software? That's unacceptable.

>>936746

2x 1080p screens > 4k

>>936737

Too late. The entire computing world is ebbing back to the bad ole days. Most people are already back to mainframe/thin client architecture on mobile.

>>937144

> mainframe/thin client

That is good and inevitable. The problem is that user processes aren't truly isolated in current architecture.

The solution is to just own your own server you remotely log into. Maybe in the future there will be a provably secure cloud with homomorphic encryption tech so that the cloud providers can't snoop on your data/computations.

On my 4690k, it took slightly longer than two days to encode the twelve minute long 1080p Buck Bunny using --cpu-used 8 which is supposed to be the fastest option for encoding. Decoding in real time on this machine with VLC 4.0 wasn't an issue at all. They need to heavily optimize their code, or this wont get much use until hardware encoders become available.

>>937163

>cpu-used 8

>fastest encoding time

There's no speed increase whatsoever past cpu-used 5 on an 8350, dunno about jewntel specific optimizations.

>>937163

Actual solution is doing that with GPU and that requires hardware level support. For example https://en.wikipedia.org/wiki/Nvidia_NVENC and its Intel and AMD equivalents. Doing h.264 conversion is ridiculously fast compared to VP9 and AV1 really needs that level of hardware support, and it really looks like it will get it: https://www.anandtech.com/show/12601/alliance-for-open-media-releases-royaltyfree-av1-10-codec-spec

>backers of the AV1 want the codec to be ubiquitous across devices and platforms, therefore expect it to be supported not only by major chipmakers, software designers, and service providers, but also by leading makers of consumer electronics.

Support for Opus is already there, with even iFag systems supporting it now.

You fags shit up every thread when codecs are discussed.

>hardware encoders

NVENC is shit and so is all baked in hardware encoding. Most of the time it doesn't even support most of the standard

>XviD in cy+3

The first-gen AMD thunderbirds can decode standard definition h.264 using just the CPU. XviD is only useful for 90s-early 2000s set-top boxes and the Nintendo Wii. It's only kept around for fags with ancient hardware. If you need to support this just set-up a transcoding server on something more modern.

>>937196

>>937194

Better question: When are we going to see something with Vulkan support to offload more of this to the GPU?

>>937194

Only gnewfags don't know that hardware encoding looks like dogshit since it's simplified to the max compare to software.

>>937196

>The first-gen AMD thunderbirds can decode standard definition h.264 using just the CPU

You didn't read the thread, didn't you? The point of the xvid fanboy is that it's better than x264; which is almost true: it WAS better because x264 had too strong in-loop filtering leading to loss of detail. This was before all the psy opts.

This is the exact same reason x265 is shit for now: it cares too much about metrics and low bitrate results.

>>937218

better than x264 for transparent encodes*

>>937218

>>937218

>Only gnewfags don't know that hardware encoding looks like dogshit since it's simplified to the max compare to software.

got any proof to back that up? codec ic's are quite accepting of user inputed parameters.

>>937220

>got any proof to back that up?

Yea you've obviously never done much video encoding.

>>937218

>The point of the xvid fanboy is that it's better than x264; which is almost true: it WAS better because x264 had too strong in-loop filtering leading to loss of detail.

I'm sure he totally believes he can see the difference on video running 24-30fps too. I can't stand faggots that use old stuff just because it's vintage. Shocker that he doesn't profess his love for DivX 3.11 ;-). Probably because no one encodes anything in it anymore. They'd drop Xvid just the same if they weren't concerned about street shitters being able to make bootlegs.

>>936703

He is right, though. As long as there is a way to do something, someone else is going to want to do it differently.

>>937232

Not proof. Show something concrete.

>>936844

>Pick Xvid if you are sane.

How much of a turbo-autist do you have to be to use Xvid in fucking 2018? Do you play all your videos on your PS2?

>>936714

>>936711

Why PNG?

>>936834

>not even jap Youtube videos

Only a few (some might be taken down by copyright enforcers).

https://hooktube.com/watch?v=50qPT0h9Vr0

https://hooktube.com/watch?v=vzz30MB83Xg

https://hooktube.com/watch?v=47KRct-Lulw

>video link embedding is not available for this board

>>937090

but that also gets (((them))) more money.

and pollutes the earth more, too.

>>936834

>not even jap Youtube videos

Odd. I'll take your word for it, but I was able to find videos created with EVA Animator pretty easy on niconico. They even have an article on their part of their site which is kind of like wikipedia about EVA Animator http://dic.nicovideo.jp/a/evaアニメータ

>>937283

1) Because it's a bitmap format designed for flat color synthetic imagery that almost always originates in a vector editor, so a vector format would be infinitely more efficient.

2) Because it was written in 1996, around the DEFLATE algorithm used by contemporary zip files, and hasn't broken compatibility since then. As a result, it's fallen into the same trap as JPEG, where lossless compression with a modern archive format yields double-digit percentage savings on a single image.

>>937304

>ASIC efficiently decoding outmoded codec that consumes colossal amounts of storage and bandwidth

>flexible hardware inefficiently decoding cutting edge codecs that conserve storage and bandwidth

Tough to say which is better for the environment, honestly.

>>937250

Don't have a jewvidia GPU to prove you wrong. Test it yourself.

https://trac.ffmpeg.org/wiki/HWAccelIntro states the same thing.

>>937166

After messing around with this for awhile, I'm not even sure it's passing options given. This is what it says every encode.

Stream #0:0: Video: av1 (libaom-av1) (AV01 / 0x31305641), yuv444p, 1920x800 [SAR 1:1 DAR 12:5], q=-1--1, 200 kb/s, 24 fps, 1k tbn, 24 tbc (default)

I can change crf and cpu-used to minimum and maximum setting and the video still looks like shit.

>>937455

Okay, I guess unless you specify -b:v it's going to use 200k everytime. I think constant quality mode is not working in FFmpeg.

>>937344

I am not talking about using stupid shit GPU's. I am talking about ASIC's.

Fuck AV1, I want my Daala.

>>937465

Software encoders have too much branches to be implemented efficiently (performance:cost ratio wise) in hardware. It'll always be gimped.

>>37472

Yeah, too bad about Daala. The "good" news is that AV2 will probably integrate more of it.

>>937473

Prove it.

>>937319

There's no point to replacing PNG as file size isn't an issue anymore. We'll only need to scrap it when we switch from RGB to a luminance-based model. IIRC, while PNG can be forced into working that way as it supports 16 bit luminance sampling with a customizable transfer function, none of that shit actually works correctly in any PNG library so it's like it doesn't exist.

>>937495

>file size isn't an issue anymore

And that's where you're wrong! A 7MB PNG isn't cool to have around.

>>937516

Who cares? If you need 7MB, then you have the bandwdith.

>>937210

Dunno but programming against regular hardware compute API sounds like a cool idea. Why isn't it done already? At least I haven't heard of such. Why not make encoder target OpenCL?

>>937516

Are you in India or something? 7MB is nothing. I have a few thousand pics in Canon RAW format sitting around at about 50MB each and I still don't care.

file size isnt an issue only if it provides fast access like wav

otherwise its still an issue

>>937495

>There's no point to replacing PNG

See the lossless table here: https://wyohknott.github.io/image-formats-comparison/speed_results.html

>codec: vp9

>avg. compression ratio: 2.905

>avg. space saving: 65.58%

PNG is a 21 year old format.

>>936697 (OP)

AV1 isn't in the same league as Opus. Xiph took a look at the audio codec landscape and how it was shaped by a triangle of needs: bandwidth, complexity, and latency. Anyone else would pick two but they said "fuck it" and delivered a scaleable low latency low bandwidth audio codec that can decode and encode in realtime on even the shittiest SBC. AV1 is anything but efficient, both encode and decode.

Will AV1 be ever ready to use or it's even more of vaporware than VP9?

>>937636

It's the only way for the big internet video companies involved to keep their balls out of an eventual licensing fee vice, but they're all largely webshit companies who have no experience in writing optimized code, so dunno. They might never get it fast enough to be useful.

>>937566 (checked)

>Canon RAW

>keeps pictures in uncompressed proprietary dataformats

REEEEEEEEEEEEEEEEEEE that's worse than BMP

You sound like my /tech/ illiterate family.

Just keeping them on a 500GB hard drive with no copy waiting for it to fuck up

>>937636

If avif becomes a thing we at least don't have to deal with GIF, jpg, WebP, APNG, MNG and all that other crap anymore.

I mean having a cost free standard that's better than JPEG would make me happy. I'm kind of tired of still seeing jpg everywhere.

Can some of you experts tell me why video codecs don't just use Vulkan when available?

Wouldn't that save us from producing new hardware decoders all the time?

>>937651

It keeps them in the format of the data retrieved from the sensor. It's a good way to handle it. The conversion to a regular image format discards a lot of data. I have them backed up online via Amazon as they store an unlimited amount with prime and I have gigabit internet to upload them with. Be less of a peasant.

>>937657

>I have them backed up online via Amazon

how does it feel to share everything with CIA?

Answer to the bitstream freeze:

https://youtu.be/64FRE9L40oI?t=1118

>>937516

Archive.org's Panoramio archive weighs 269,673 GB. Even jpegs add up at scale.

>>937676

Not only that. They also don't look as good as a picture in for example H265/BPG/HEIF

Not to mention the eternal non-solutions for GIF

* converting to lossy video looks shit

* converting to APNG means you can never tell that they actually contain an animation

* converting to MNG means nothing can play it

* converting to video means you'll have a fucking UI around it

I WANT AVIF

>>937677

>you'll have a fucking UI around it

nope it doesn't. it's optional

>>937678

However you'll have it on by default and no one detects if it's soundless and how long it is and disables it based on that which would be retarded too.

>>937661

>If you convert them to PNG 16bits

PNG doesn't support mosaiced data, or any sensible form of metadata which tells the color filter array layout, color primaries, etc.

You probably just don't know jack shit about digital photography.

>>937680

It's trivial to detect if it's soundless. It's always in the beginning of the file, in headers.

If you use shit browser, it's your problem.

>>937684

I don't even care, I only play videos in mpv.

(and I blocked everything *.gif in uBO, too)

>>937685

>and I blocked everything *.gif in uBO, too

Why? (using uBO uM and uBOE at once btw)

>>937686

>uBOE

?

>Why?

The expected value (in probability theory sense) of the quality(value) / file size is extremely low for an unknown gif file. Mainly for 2 reasons:

1: the format is shit

2: people usually convert worthless crap into it

I added a few exceptions for when some underhanded websites use it for actual design (where PNG should be used), there aren't a lot of them fortunately.

>>937688

>782.08 KB

probably not

>>937690

At least look at it before you decide it's shit!

>>937694

>1.51 MB

>Real animation

Kek

>>937691

>At least look at it before you decide it's shit!

Fool me once…

>>937698

Kek

IT IS YOU RETARD. GIF IS JUST THAT BAD AT COMPRESSING

>>937701

>GIF IS JUST THAT BAD AT COMPRESSING

I know, that's why I'd rather not have to waste my bandwith

>>937460

>encoding AV1 with ffmpeg

Use the aomenc reference encoder if you can, ffmpeg is missing many of its advanced features/options at the moment.

Has anyone here tried rav1e? Is it any good?

>>937708

>Is it any good?

>omitting most AV1 features to gain speed

probably has no point over x264

>>937651

>GIF... APNG, MNG and all that other crap anymore.

I'm gonna venture a guess that AV1 doesn't use delta frame compression, and that once again a confused anon thinks a dedicated video codec is a replacement for lossless animation formats. It's not.

>>937717

AV1 have a lossless encoder so I think it can encode lossless but I'd be happy to be proven wrong

>>937704

>waste my bandwidth

Don't tell me you have to pay per transferred data unit

>>937721

*has

>>937708

The source video must be converted to yuv in order to use aomenc. I'll probably just wait awhile longer until ffmpeg support has improved.

>>937721

>AV1 have a lossless encoder so I think it can encode lossless

What matters is how though. There's a lot of lossless video codecs but almost none use delta frame compression, which prevent them from competing with the file sizes attainable by dedicated animation formats.

>>937725

AV1 uses reference frames from which the image is changed (the last 8 of them have to be kept in memory) if that is what you mean

>>937728

Delta frame compression is when you create animation by overlaying successive frames, each frame having the image parts that were identical to previous frames cut out and replaced with transparency.

>>937730

Thanks for explaining.

So like GIF or APNG?

I think they had features stolen from dalaa which take care of that but I'm not sure. We'll see when it's out.

>>937730

It doesn't do delta frames what I meant was that I think they had a feature that took care of it.

>>937717

>256 colors is lossless

kek

>>937809

GIF actually can do more than that, but file size explodes because you lose compression. The bigger issue is that GIF's frame display times are stuck in 10 ms increments, meaning your options are 100 fps, 50 fps, 33.3, 25, 20, etc. You can try to simulate other frame rates by with variable display times but it doesn't really work that well.

>>937812

>because you lose compression

As if it could compress something well to begin with. just trolling, of course there's a difference, but for real life video footage it's absolute shit tier

>>937266

Not much, especially if you care about open codecs. (or as Stallman would say: H.264 is open-source, Xvid is libre)

H.264 is popular because:

- most of the normie content is optimized for small size

- it is used by the studios, and "don't re-encode" is like a number 1 p2p rule

There is no technical reason to pick H.264 over Xvid for your own content when you wish to compress without visible artifacts.

>>938891

For someone who cares about open source, not necessarily libre, is there any reason to use Xvid over baseline H.264? It's my understanding that Xvid is based off an early version of MPEG4 spec. What are the minimal system requirements to play back 480p?

>>938910

>Now show me a proof

The proof is only YOUR eyes. Encode videos with settings where YOU can't tell the difference between the source and the encoded ones in a blind test.

Or just say that you can't see a difference between a 0.2Mbps H.264 encode, a 6Mbps H.264 encode and a 1080p fast action source. Then you will have the full right to shill for H.264.

>H.264 scales

Yes it does. So what? For the use case we are talking about it doesn't matter: to achieve a perceptually same quality compared to the source it requires about the same bitrates as Xvid, with no real technical or political advantage.

>>938943

ASIC chips for both Xvid and H.264 cost pennies today, so the playback system requirements don't really matter now. But as I remember the latter required 4-8 times of CPU power to decode (really depends on the encoding settings).

>>938946

>to achieve a perceptually same quality compared to the source it requires about the same bitrates as Xvid

this is what you didn't prove, dinghole (and can't prove)

>>937680

>>937684

You can easily do this shit server-side. Why even bother doing it client-side?

>>938946

You sound like the audiophools who think that WAV sounds better than FLAC.

>>939525

The sentence you referred to has context around it. The guy literally said he can't prove it in the same post.

>>936737

>codec wars

As long as there are jews trying to squeeze (((royalties))) out of everyone involved and freetards that don't want to pay a single shekel, we willl suffer this shit.

>browsers ignoring system-level codecs

You really, REALLY do not want random codecs in your system being exposed to web content. That would be a security nightmare.

>fixed-function asics

They're an order of magnitude more energy efficient than equivalent software implementations. Desktops notwithstanding, anything mobile will benefit from extra battery life while playing media.

>>936748

>I honestly don't know why everything doesn't just use ffmpeg as its backend for playing video/audio. It's good, and it just works.

It's not secure though. It aims to include every codec and its dog, but does not audit them for security bugs. In fact, auditing hundreds of codecs present in ffmpeg is a sisyphean task that even the wealthiest of companies could not realistically achieve. With an attack surface of such size and complexity, there are bound to be arbitrary code execution bugs galore waiting to be discovered and exploited. Doubly so since it's often the kind of code that cuts all kinds of corners for performance.

You don't want to run ffmpeg on untrusted media that the web throws at you.

>If the asics were more versatile they could be adapted for a multitude or standards and do hybrid software/hardware decoding which would be overall better.

Fun fact: technically, they are! Every modern video "ASIC" is really a gaggle of specialised DSP processors with esoteric ISAs that can invoke a lot of small attached fixed function hardware blocks for common tasks like FFTs, convolutions, bitstream parsing and shit --- that are running proprietary firmware that actually implements the codecs. Of course, since everything is proprietary, undocumented and highly unique, good luck reverse-engineering it to write Free firmware replacement.

>>937112

nigger eyes

I'm still going to use x264 because of the hw accel

I'm already using FLAC and Opus for all my audio needs, Opus in particular is amazing and well supported at this point and doesn't use a lot of CPU. There is no reason to use MP3 or AAC for anything. I ripped my mom's audiobook CD's for her in 48kbit/s opus a while ago and it's perfectly good bitrate for listening spoken word, no difference to CD audio on casual listening. Less than 30MB audio CD rips!

Read this to get an idea how good it is by version 1.2: https://people.xiph.org/~jm/opus/opus-1.2/ people who wrote that claim

>When originally designing Opus, we were amazed that we were able to encode fullband (48 kHz) speech at just 32 kb/s. We thought with some tuning we could get down to 28 kb/s or maybe even 24 kb/s, but we never considered going as low as 16 kb/s. Yet here we are 5 years later and 16 kb/s fullband speech is becoming viable.

48kbit/s VBR opus is ridiculously small and very listenable, these dudes say I should have used even less bits.

>>940138

48kbps is ok even for songs with a lot of distorted sounds and noise (whatevercore, can't remember).

>>940360

Then you must have shit gramophone/soundcard/headphones/stereo/ears. Even 320kbps quality-encoded mp3 sounds like a shit.

>>936697 (OP)

AV1 has been already surpassed by VVC (HEVC successor) and purported by big content players (nothing less than BBC and Fraunhofer to mention some). Netflix already considered VP9 over HEVC and concluded that HEVC is the shit.JEM, based on VVC, blows AV1 completely out of the water even if the specs freeze is due in 2020.

I've skimmed through this thread and people were still talking, in the current year, about "blind tests" on media content, when we have the VMAF score (that is, de facto the only relevant metric).

VP8-VP9-AV1 will deliver "freely streamable content" for players involved in the web-browser industry (and for content delivery to low performance networks, VP? may hit a sweet spot there as recent Netflix research showed), everyone else will follow H264-H265/HEVC-H266(?)/VVC since the trade off in quality and size is RELEVANT, not to mention that VP? is badly accelerated hardware-side partly due to its own specs.

Anyone who ever bothered to study this field and read the relevant forums knows that H264/HEVC is here to stay and it's the best choice for anything non-youtube and not on-the-go. I'd double dare you to reach the same VMAF score >96% from genuine sources using HEVC and VP9, or H264 and VP8 at comparable bitrates.

But this cesspit went to shit more or less like halfchan, I'm seeing that Tor users still can't upload files on this board for no reasons at all and on top of that every single media element is served via clearnet. Incompetence can't be saved

<<940366

double bait: not only it's untrue that you need an exceptionally good equipment to get codec-induced distortions, but you're more likely to hear poor performant codecs if they enhance the defects or the limits of your headphones or whatever.

On top of that, rest assured that even if you have golden ears you'd fail a 320kbps MP3/FLAC ABX test. It would be credible between the official transparency point (128) and, say, 224. At 256 is already unbelievable and at 320 there are no validated ABX tests.

>>940373

Ok, which cesspit do you hang out in then big shot?

Please tell me I want to escape this place ;_;

>>940366

>he fell for the audiophile memes

You can't tell the difference you're just trying to justify spending a years wage on some headphones. This doesn't mean things like FLAC aren't useful it just means you're an idiot.

>>940373

Finally someone else that knows what they're talking about.

>>940373

what's your username on doom9

>>940373

Quality doesn't matter. Remember when the web video revolution was postage stamp trash and shit in flv? What mattered wasn't quality, it was that it could get out to people and fill a new niche. VP8 is hot garbage but webbums are all over the place because we could actually use it. Everyone's now streaming to twitch via open source obs and a format that tries to Jew them for royalties will be DOA.

>>940425

No, really, there's a massive difference between lossy and lossless music, in this case, between 320MP3 and FLAC.

What is bullshit though, is when you start going farther such as 192kHz and uncompressed shit.

>>940444

>flv

Surprisingly, a lot of flash animations still look pretty good today.

>>940376

>exceptionally good equipment to get codec-induced distortions

more like exceptionally bad, when distortion causes changes in certain bands to affect other bands.

codecs are modeled for perfect equipment, so after some point, the better the equipment, the harder time you'll have to ABX lossy encoding.

>>940083

Great, now he can officially go fuck himself in ass for this bullshit.

>>940456

>in this case, between 320MP3 and FLAC

Interesting. How about proving that?

Also try Opus@140k, should be better than mp3 at any bitrate in case you tripped on an mp3 encoder bug.

>>940459

vector animation in swf and flash video codec are totally different things.

>>940425

Are you jealous poorfag?

My headphone cable alone costs more than the full studio equipment used for recording the sound.

When I download from YouTube the first thing I do is to convert it to FLAC, and there is a huge improvement.

>>940474

Obviously, if you have $50 headphones with phone/integrated sound card, it's hard to tell. Watching 720p videos on 4k screen isn't going to make much difference either.

>>940425

>didn't ignore audiophile

are you new? those are commies of techworld, no matter how much proof contrary they continue believing their retarded beliefs. Let them listen to their WAVs.

>>940360

I use 96kbit/s for music.

>>940373

Interesting but no sources on anything so discarded.

>>940537

>are you new?

No, just been dealing and scamming them for years and thought he'd like to know how he's getting fucked without lube. You have to call them out on their bullshit or they just continue to spread their cancer.

>>940521

Oh, I'm not saying it's worth it, I'm saying that unless you actually have/had proper 4k monitor, proper 4k content and good enough eyes, you're not qualified judge merits of watching films in 4k. The problem is, most music recordings are nowhere near good enough to justify very expensive equipment. But unless you're gonna claim that there's no discernable difference between 320k mp3 and live symphonic orchestra, there's obviously room for improvement over 320k mp3.

>>940537

I listen to flac, I have ath-m50x and some others from at, which are all for poorfags, regular chink dap for the same price as the headphones, and I can hear the difference. Now what? You'll tell me I don't? I did some testing before I bought into "flac meme", and could tell the difference, it's quite hearble if you listen to classical/noise/metal music and use equalizer.

For the gramophone I don't know which exactly I have, but I have old one czech-made, because they are very accesible, cheap and wayyy better than 6x times more expensive new ones.

>>940521

Wasn't me, will reply.

I listen to music like 6 hours a week, mainly on stereo. I prefer live performances, on which I go about 5-6 times a year.

>>940543

>>940560

A live performance is always going to sound better. Keep in mind the entire venue is designed around sounding as good as possible and in the case of electronic music everything is going to be tuned for the performance. I've set up venues before and you'd be amazed how much work goes into making everything sound just right. Getting the levels correct after setting up takes many hours.

I'm not saying 320kbps mp3 is perfect but for most people it's certainly good enough. Like one of you said the masters are not done well these days (insane amounts of clipping) so the source isn't even good in most cases. Also most idiots are listening to music on subpar setups even if they paid through the nose for it. I know when I did car audio most clients only cared about how loud they could make the subwoofers go. They'd sacrifice everything for a little more ump from the woofer. Almost without fail they'd fuck with the gain settings I'd spent hours tuning in for them and blow their woofers within a few months of buying them. Which was fine by me because they'd always come back for another one. Sometimes they'd tried to claim I sold them a bad speaker but it was pretty obvious because I always marked the amplifiers when I turned them in. I loved clients that would request a remote for the gain in the cab because I knew they'd blow the woofer within a few weeks. Ironically that's how my last system bit the dust because my retarded friend would fuck with my volume/gain when I left the car running. He ended up having to come out of pocket for blowing one of my woofers.

BTW if any of you are considering a loud system for a car my suggestion is to not get it. It's a money pit, you will constantly be tweaking it, you will worry about it getting stolen, eventually some asshole will tear your car up for it and do a ton of damage. Last but not least it'll beat the shit out of your car and it'll rattle like hell at highway speed after a few days of using the stereo. It just isn't worth it. Also it'll cause hearing damage and will most likely attract every cop within a 10 mile radius. There is a reason you only see teenagers with that crap outside of DB drag contests (which are also very retarded).

>>940560

>gramophone

Its probably about time to upgrade and join the 21st century.

>>940588

Ah, so. I can see when you're coming from with your distain for "audiophiles". I wouldn't be at all surprised if vast majorty of people who buy expensive audio equipment were mostly illiterate in the matter. Though that's probably true in most areas. How many people are there who buy brand new computer for $2000 every two years instead of just upgrading the relevant parts, or who shell out $60 for games like SW Battlefront....

>>940560

I did A/B tests as well before ripping all my CDs to FLAC. The easiest one for me to pick up the difference was brushwork on cymbals. Lossy compression smeared it together.

>>940117

>Fun fact: technically, they are!

Then why are even very slightly older SIP blocks incapable of partially accelerating newer profiles, let alone whole new codecs, that share 60-90% of their single-thread stages?

Given the amount of blood and sweat the x26x team and Doom9 have poured into attempting to get more useful work out of humble hardware, if it were possible, I can only imagine they would've done it at least once.

>>940508

So how do you do that then? Yeah if you say something uncommon like being able to ABX mp3@320, show us some logs.

And if you actually wanted to ask about it, I have $300 headphones with full coverage of human hearing range and virtually nonexistent harmonic distortion.

Speaking about sound cards, I can see where you came from. The DAC differences are for the most part bullshit, as even the cheaper ones are more than enough for human hearing (you won't be able to hear the distortion). Setting up a blind ABX test for hardware is quite a lot more involved than a codec test, but yeah if you want you're free to go.

Audiophiles are the most ridiculous little shits who make wild claims and every time one gets shot down they just move on to the next wild claim like nothing happened. They're a cult.

I dealt with one like that in college who insisted the limited bit depth of digital music meant it could never beat his vinyl which had 'infinite' depth. I did the math and showed him that even if he had an impossibly precise record player where the needle could produce a clean signal for groove depth changes of a single hydrogen atom that records are not thick enough to match the bit depth of existing digital formats.

He brushed that right off and switched to claiming the 'blocky' nature of sampled digital data could never match his vinyl's 'smooth' signal. I thought about going back to thought experiments with atoms again but instead decided he was a faggot.

At least they don't seem to argue much about vinyl anymore, but they're still very much into speaker wire, "warm", and a fear of anything digital.

>>941164

This. They don't even know anything about /tech/. Had to deal with one who saw it on TV.

TV is cancer ruining our society. Basically same stuff you described.

In addition: vintage

>>940588

>A live performance is always going to sound better.

Not when they've blasted out the volume because everyone else around you can't hear shit after years of listening to blasted out volume.

>>941211

Analog is analog, say what you want, but to my ears it sounds more lively; even if it's just emotion, attachment to vinyl or just very simple prejudice against digital, anachronistic look at world at all.

>>941252

It got somewhat better with online streaming services because they normalize volume, so there's no point in loudness wars any more.

>>941248

>Analog is analog

I_don't_know_the_Nyquist--Shannon_theorem.opus

>>941262

Normalization doesn't remove clipping like this. And pop shit will always be compressed as hell; sounds better for normalfags listening to "music" on their shitty phone/car speakers or shit bluetooth headphones.

>>941272

>Normalization doesn't remove clipping like this.

Only a problem if they rip their audio files from the CDs (but why would they).

>And pop shit will always be compressed as hell; sounds better for normalfags listening to "music" on their shitty phone/car speakers or shit bluetooth headphones.

But it's more strenuous to the ear over hours even for normie ears. With less compressed recordings, playback devices can apply compression as required by the environment and listener.

>>941252

Most of my vinyl collection is quite old, mainly classical and that little jazz I have. As I somewhat said before, lot of old stuff is easily accessible in europe.

>>941272

>bluetooth headphones

Did this meme originated in murica or are you from europe too?

>>941291

bluetooth noise-cancelling headphones are superior

>>941212

This. Ever since the shift from acoustic genres to rock+pop, access to electric amplification, combined with the temptation for larger crowd sizes, has been a power most performers and venues have proven they shouldn't be entrusted with.

>>941272

His point wasn't that normalization fixes mixes that have already been brickwalled from the past, but that it removes any incentive for producers to brickwall them in the future.

>>941294

>it wasn't until the release of 2.0+edr in 2004 that bluetooth could theoretically just reach the 1.5mbps needed for pcm

>basically all bluetooth headphones still reencode audio to far lower bitrates

>>941252

bullshit, digital doesn't imply dynamically compressed, nobody forces artists to do that and some don't.

>>941248

how about you prove that you can hear the difference? and yeah, vinyls are pressed from digital recordings since long time ago.

>>941262

stupid dumbfuck producers still compress their shit to DR5 and below go figure

>>941272

it removed the need to do that shitty compression job. but of course if you got a shit record, it won't be possible to magically recover all the lost information, and even automatically detect which samples are in fact damaged.

bluetooth is only shit if the most common format is some crap like SBC. otherwise you won't be able to ABX it.

>>941290

>Only a problem if they rip their audio files from the CDs (but why would they).

WAT

>>941212

this is somewhat countered by using earbuds (the hearing protection thing)

>>941500

>bullshit, digital doesn't imply dynamically compressed, nobody forces artists to do that and some don't.

That was exactly my point. Digital can sound as good or even better as analog. Unless you listen to specific genres majority of musicians will decide to make their song sound as loud as possible, destroying any natural variations in amplitude of the signal. If it's going to be played on the mainstream radio it will be compressed, so yes some artists are forced to do that or they risk making their song sound "weak" and lose positions on charts which means they lose money. Looking at popular songs I don't even know how shit music can get this popular in the first place. I'm convinced (((they))) must be behind this. https://pudding.cool/2018/06/music-map/

>>941500

Analog is generally more amenable to volume/balance/EQ/companding/etc, where doing the same with a digital signal will generate more artifacts. And yes, there are still a small number of labels with a full analog signal chain.

Regarding headphone amps in mobile devices, it's true most of them are designed to be incapable of playing anything that isn't brickwalled.

>>941511

>Analog is generally more amenable to volume/balance/EQ/companding/etc, where doing the same with a digital signal will generate more artifacts

pure, unadulterated horse shit.

>>941511

>Regarding headphone amps in mobile devices, it's true most of them are designed to be incapable of playing anything that isn't brickwalled.

only if you are half deaf and need a shitload of sound pressure to hear something. (or use headphones with absurdly big impedance)

>>941512

>pure, unadulterated horse shit.

Try digitally increasing the volume of a file, even just 200%. The clipping will be obvious to any layman.

>only if you are half deaf and need a shitload of sound pressure to hear something.

Or if you have something like a typical modern smartphone (with the included 1st-party earbuds!) and are trying to listen to quiet sections in something with actual dynamic range.

>>941513

>Try digitally increasing the volume of a file, even just 200%. The clipping will be obvious to any layman.

Same will happen with analog if it's not all below -6 dBFS.

with digital btw I can use floating point format and it'll be okay. checkmate.

>>941513

>Or if you have something like a typical modern smartphone (with the included 1st-party earbuds!) and are trying to listen to quiet sections in something with actual dynamic range

I have no such problem with Nexus 5X and Sennheiser PXC 480 (with ANC turned on).

>>941514

>$300 full-sized headphones with their own battery, amp, dac, & dsp from a specialized audiophile brand

Yeah, that would probably do okay

>>941515

They are wired and don't have a DAC because they don't need it. Don't confuse them with their wireless bro.

And anyway, it counters the point about phones being too weak. If these headphones work equally well with any reasonable source, perhaps that just means that phones' stock earbuds are shit, but it doesn't follow that phones themselves are shit.

>>941517

>>941515

…and yeah of course, if headphones are connected digitally (BT, USB or whatever), then all of the amplification burden is moved to the headphones and the source would be completely irrelevant. (the only problem being the selection of transport codec that isn't shit; it's kind of fucked up for BT at the moment because the only mandatory-to-implement codec, SBC, is shit).

>>942957

>Why is Jewgle's official AV1 encoder such a fucking joke?

Just as with VP9, they will probably never release the good encoder to the public.

How else would they have a huge advantage against competitors?

>Was vpxenc this bad backwhen VP9 got its bitstream frozen?

It's still shit, and Google very likely uses something else internally.

>>942957

Did you try HEVC or AVC's reference encoder? Comparing x264/x265 to a reference encoder is just retarded.

>>943167

Jewgle still uses vp8 for jewtube video. They haven't switched to vp9 yet.

>>943209

horse shit, just download any recent video and check it for yourself

>>943198

for AV1 we'll probably never get anything other than the reference encoder, that's the problem

>>943209

How can you say such bullshit unfazed?

> youtube-dl --list-formats 'https://www.youtube.com/embed/oOUX_yAQB7o' | grep vp9
278          webm       256x132    144p  103k , webm container, vp9, 27fps, video only, 3.93MiB
242          webm       426x218    240p  235k , vp9, 27fps, video only, 7.58MiB
243          webm       640x328    360p  472k , vp9, 27fps, video only, 14.28MiB
244          webm       854x438    480p  853k , vp9, 27fps, video only, 25.46MiB
247          webm       1280x656   720p 1693k , vp9, 27fps, video only, 53.63MiB
302          webm       1280x656   720p60 2668k , vp9, 55fps, video only, 84.70MiB

>>943214

>>for AV1 we'll probably never get anything other than the reference encoder, that's the problem

See rav1e. If you really look into it AND behind it, you'll know that it'll become the x264 of AV1.

>>941164

>audiophile

Don't get me started on these faggots.

>gold plated audiophile grade monster hdmi cables that improve picture quality by 500%

>superconductive shielded fiber optic cords that stop all forms of emf interference

Yes, tube amps sound different due to imperfections in amplification caused by imperfections in production or induced noise.

No, digital amplifiers aren't garbage because their digital. They're garbage if you buy garbage.

The real mindfuck is to tell them that everything is recorded digitally now, even re-released old mixes of records.

The last truly analog recordings were done before the adoption of magnetic recording, which happened in the 30's.

All records from the 60's were all digital. reel to reel in studio, which is digital, then shipped to cutters

They'll deny it, but it's true.

>>943214

>>943216

oops sorry

didn't check recently enough

>>943225

>The real mindfuck is to tell them that everything is recorded digitally now

It's like they could tell a difference in a blind test, which they can't anyway.

>>943217

>AND behind it

wow, that's intense

how did you come to that conclusion?

>>943239

Well, I meant who's behind it. Xiph brought the multimedia world so much that I can't help but have faith in them; they're the only entity I donated money to (I plan to donate to Gentoo, though).

>>941164

>>943225

There are stupid audiophiles like that Japanese guy who even had to built his own electric pole when he coulda just used UPS on batteries to avoid EMF/feedback from those connected to the electric grid.

Those gigantic slug of a HDMI or RCA cables gave us top keks so I'm not even mad.

I'm surprised people have shit hearing because most of the time almost ALL headphone's earbuds/earpods or *insert pop brand* I've tried are shit especially those with microphone which always have one channel louder than the other due to its BAD design (yeah the mic really killed it) plus the channel latency caused by the microphone if they put the microphone chip and volume keys on the right side (nothing on left side = no latency).

Even headphones like xiaomi's latest one gets too many attention and positive reviews though it's far worse than the one I use.

There's also an IRS setting on xiaomi for that same earbud and it seems it sounded better but not any better compared to the one I use.

protip: don't buy anything with microphone.

Anyway if anyone's interested with that earbuds I am talking about it is A4tech MK650 (no microphone). I'm sure this will be your last earbud ever.

There are dual driver or shome gimmicky earbuds but they're still shit because of A) the microphone B) it doesn't have a balanced freq. response as that A4tech one.

>>941262

>there's no point in loudness wars any more

Doesn't help that producers still don't know about proper sound production or dynamic range anymore. Certain instruments or parts of a song should be louder or quieter than the rest of the song, but instead everything is at the same volume. (There's videos that explain this a lot better.)

Opus still can't into ReplayGain.

>>945825

You mean the opus container, right? Because Opus Ogg works without problems.

>>945825

it can

>>945848

even opus container can

>>944595

>AV1 optimized

haha

ha

>>945857

1.44 frames per minute at cpu-used 0 is amazing compared to earlier versions where it took 3 minutes to encode a single frame.

>>945856

I know it can do EBU r128 but:

1) According to https://tools.ietf.org/html/rfc7845, they don't want to handle peaks.

2) I never know if the player has support for it.

3) Why change Ogg? It works and has worked for a long time now.

>>945857

>>945858

And people don't realize this: AV1 is like a basecode.

The future versions, or third party versions, will all be compatible with AV1-ready hardware.

>>937708

I tried. If libaom is absolutely horrendous, rav1e is just plain unbearable. Not sure what hw does 5 fps with it. I have an old A8-3870K and it took several minutes to encode just one frame. Size was 240p.

Why nobody disparaging AV1 ITT looks at industry support it has? You guys are only looking at present. It's going have better support than H.264 by 2020 if AOMedia delivers and I don't see why they would not. That's two years away. AV1 was officially released just a few months back, keep that in mind.

>>947345

>(((They))) repeatedly told the public that major webbrowsers and video hosters such as Jewtube would enable native AV1 playback within hours of its bitstream getting frozen, none of which have ended up happening.

Shouldn't believe everything you read, amitard.

They SAID that they have to finish the specification for the bitstream freeze first and then they would work on the encoder. They didn't even say much.

You probably read that crap on some tech page which just slapped rumors into an article.

>Outdoing h.264 support by 2020

Kek, would you use h264 in 2020?

>>947350

Scenefags barely adopted VP9 and Jewtube's 1080p AVC encodes are in some cases smaller than the VP9 encodes at similar levels of quality, so why not?

Now if OBS were to implement an efficient real-time AV1 encoder on par with x264 then you'd likely see a big shift towards it, but that is highly unlikely to happen without hardware encoders which will take a minimum of 2 years to arrive, and even then given how hard Moore's law has been stagnating an adoption of magic AV1 encoding ASICs in every major GPU&mobileshitter SoC past 2020 will still take at least 3 years if not longer to replace h.264.

Fuck, h.265 is much more likely to overtake h.264 during that time at least for consumer video storage considering the situation among scenefags and the fact that cheap chinkshit SBCs are getting h.265 HW decoders, not to mention x265's astronomic SW performance compared to libvpx and libaom.

h.264 itself was a meme compared to the more widespread Xvid up until it was integrated into Flash in 2007.

Will XVC ever be more than a royalty-based meme?

>>943227

they have been using vp9 for 2 years already

>>947335

H.264 will be video's JPEG. There's no stopping it now. It will have support on everything long after you are dead.

>>947464

That's quite wrong. You underestimate how shitty JPEG is compared to HEVC or AV1's intra.

>>947385

>Moore's law

>ever mentioning

Anon, you are NOT on reddit

>h.265 is much more likely to overtake h.264

>implying it will overtake anything because it has a similar name

So what if Blu-Rays come with it? Physical media is dying, remember? Webbrowsers is where it's at and NONE of them support HVEC.

And who owns the webbrowsers? The companies participating in AV1! Google and Mozilla.

THEY CAN'T LOSE.

>>947476

Storage is one thing, realtime is another. Sure, there are HW encoders, but they'll never be as widely and reliably supported, just because for mature SW encoder to shit itself, something has to go horribly wrong, GPU drivers aren't as reliable.

>>936698

>why do we need different linux distros and desktop environments when ubuntu and gnome are enough

>>947476

It doesn't make any difference how good or bad the codec is. H.264 is proven, time tested, and supported on everything. AV1 wont even be practical for another year or two and HEVC is a lawyers dream. They have both already failed.

>>947749

>AV1 wont even be practical for another year

Wrong.

It's already here. Just disabled by default for some time: https://caniuse.com/av1

If you have a chromium based browser: chrome://flags

if you have a firefox based browser: about:config

>>947821

Proofs?

I have the necessary AV1 flags enabled in Firefucks and Chromium and they can't do shit with AV1-encoded webbums.

>>947998

You seem to be right about that I'm sorry I didn't test it.

Even VLC media player has "experimental support" but the only way I got to play the AV1 webm I made with ffmpeg was to use ffplay.

Maybe the ffmpeg or Chrome or vlc doesn't use the 1.0 bitstream yet?

I don't know but I got a GIF from 800KB to 40 so at least that's good.

>>947821

>>947749

Um sorry sweetie. Netflix will be able to encode Hollywood movies with multi-million dollar computer clusters. Check and m8.

>>949216

Hardware support is coming.

Also, they had to make the codec convoluted and complex to avoid patents.

>>949233

>hardware support

>hardware (((support)))

I wonder if they'll be mad enough to implement DRM in the decoder/encoder firmware so you'll have to pay for a subscription to Hollywood or acquire some loicense if you want to decode/encode certain things.

>>949216

WEll get to work then and stop whining you fucking freetard. I for one plan to sell efficient AV1 encoder.

>>949216

Hey, I encoded a 7 and a half minute video and it only took 50-60 hours.

>>945864

there is no 1 good way to handle peaks.

to eliminate both loudness differences and clipping, you will have to use a limiter in the end anyway.

>>936737

Because we tried it in the 90s and it was a bigger clusterfuck then it is now. Remember Real? Fucking DivX and it's countless versions?

>ASICs

Yeah because we don't carry nuclear powerplants in laptops/phones and batteries are still shit. Also not wanting to burn my hands when watching chinese cartoons

>>940560

>I prefer live performances, on which I go about 5-6 times a year.

Degenerate.

>>949233

>Also, they had to make the codec convoluted and complex to avoid patents.

Gay. Sounds like a recipe for disaster. Fuck the law.

>>950070

>Because we tried it in the 90s and it was a bigger clusterfuck then it is now. Remember Real? Fucking DivX and it's countless versions?

Yes. Constant, rapid advances in the quality and performance of audio/video, unconstrained by the geological pace of the consumer electronics industry

>because we don't carry nuclear powerplants in laptops/phones and batteries are still shit

Pure software isn't the only alternative anymore, there are compromises between CPUs and ASICs, like DSPs, GPUs, and FPGAs.

>>937616

>AV1 is anything but efficient, both encode and decode.

We don't know that, nobody put the effort to write an optimised implementation yet.

>>940376

>On top of that, rest assured that even if you have golden ears you'd fail a 320kbps MP3/FLAC ABX test. It would be credible between the official transparency point (128) and, say, 224. At 256 is already unbelievable and at 320 there are no validated ABX tests.

You're a retard. MP3 has design flaws that make some specific artifacts unavoidable regardless of bitrate. Most noticably, limited phase precision ruins spatial positioning of sound sources. Get a sound sample with well defined sound positions and you don't need a trained ear or expensive playback hardware to notice how positions get blurred even at flat 320kbps.

>>940686

>The easiest one for me to pick up the difference was brushwork on cymbals. Lossy compression smeared it together.

This.

>>940797

>Then why are even very slightly older SIP blocks incapable of partially accelerating newer profiles, let alone whole new codecs, that share 60-90% of their single-thread stages

Because if the (((manufacturer))) released updated firmware, customers wouldn't upgrade to the newer one? Why would they spend shekels on hurting their own profits?

>Given the amount of blood and sweat the x26x team and Doom9 have poured into attempting to get more useful work out of humble hardware, if it were possible, I can only imagine they would've done it at least once.

They don't have access to the internals, only the external APIs. As I said, the internals are completely undocumented, highly esoteric and proprietary.

>>941252

>imblying vinyls are exempt from the loudness war

>>947499

Czeched but web browsers are for browsing html formatted text. They aren't supposed to be an Operating System. You probably want play HEVC video with something else.

>>951644

>but web browsers are for browsing html formatted text. They aren't supposed to be an Operating System.

>that surely is what the normie thinks

Normies use things like ChromeOS

>What's a browser? Do you mean Google?

>>936698

>>936697 (OP)

>>936718

>>936711

>>936730

>>936746

You have to somehow get all the Camera manufactures, Hollywood, chip makers, and editing software companies all on the same page. Problem is patents, contracts, and $$$$.

>>941252

Blowing out the bits though makes it sound better because its more like your recording to some kinda tape format with limited dynamic range. That is why people like it, it sounds more analogue.

>>951021

Now try with Opus codec.

>>951977

If people like shit, it doesn't mean that shit is better.