/tech/ - Technology★

When will technology advance enough that we have videos as a string of PNGs?

>>880551

Run ffmpeg with the fs parameter set to 16MiB.

>>880552

its the full 1 hour 30 movie with audio.

trying to keep quality same. i reduced it to 40mb but its too large to post.

>>880554

>full movie

>16mb

>same quality

Not possible bud. Just split it into multiple parts.

Fuck av1 where's daala?

>>880550

https://github.com/qyot27/CorePNG

>>880574

AV1 is based on work of Daala and VP10 if I remember corretly. Multiple companies working together instead of each making their own codec.

>>880546 (OP)

This demo makes me happy. Hopefully AV1 is good enough so there is no reason to implement the hardware acceleration of codec that (((MPEG))) group will develop next.

>>880575

>latest commit 14 years ago

>>880571

I dont mean same quality, i mean the same quality as the one in the 40mb.

>>880546 (OP)

AV1 was supposed to have its bitstream frozen at the end of last year. They've removed bits of daala so it's easier for current hardware to playback. It currently take a year to encode one 90 minute film. I don't like h265 either, but at least it exists. h264 isn't going anywhere soon.

>>880546 (OP)

>Webm vs AV1

>comparing a container to a codec

>being this retarded

where do you think you fucking are?

>>880883

>webm is a container

Not even that, it's just a subset of Matroska

>>881895

Ditch your chinkpad

>>881906

>FX 8350

>chinkpad

If only.

Also it went up to 7 hours encode time with all cores at 100%, wtf is this codec.

>>880554

If it's a whole movie, there's nothing wrong with splitting it into a few 16MB chunks.

>>881895

>kissanime

>>882000

Just drop the bitrate below double digits and downscale the shit out of it.

Also don't do 2 pass, I know that goes against what most people say but using 2 pass will make your file larger.

You can't get a full movie down to 16mb without losing quality, it's not possible.

>>882000

that's easy:

1) use VP9 in CRF mode (aka "constant quality"):

… -b:v 0 -crf X … where 20 ≤ X ≤ 40

larger X = worse quality

2) if size is too big even with X = 40, add downscaling:

… -vf scale=iw*0.75:-1 … keep reducing size until it fits into wanted size

you can add more threads to make it go faster and also produce more heat if you want.

other options are of little use, they won't change anything really much.

>>882023

targeting average bitrate without 2-pass is a silly thing unless it's for realtime streaming. it will always be less efficient than CRF.

>>880550

It's called GIF.

>>880883

Still don't understand why they even bothered with WebM. MKV is perfectly suitable for the web as it is. Even in the case of streaming it's better (youtu.be/hip7Vz3zJN0). Just another case of reinventing the wheel?

>>882040

>>881895

>you can add more threads to make it go faster

not with vp9, even if you give it 10 cpu's it won't matter, it's only going to use 1, at most 2 for anything encoding under 1080p.

if you want to multi-thread with vp9, you have to write a script that splits the video into N parts for N cores, then run N instances of ffmpeg on those N parts, and then merge them all back together again at the end.

it sounds like a pain in the ass but once you script it it really isn't bad at all, it's all well documented with ffmpeg and you can split to the exact frame, you shouldn't notice that the file was split at all, and you'll get all your cores going with vp9, which is otherwise impossible.

>>882082

>if you want to multi-thread with vp9, you have to write a script

Really? Could you share such script?

>>882083

i would but i lost it because of lack of a backup a few months ago. it's not as hard as you might think to write though, it only took me a day and I did it in python, might be able to do it in bash if your good in bash.

if there's demand for it maybe i should rewrite it and post a thread or something.

>>882081

if you rename a vp8/9+vorbis/opus .mkv to .webm it will be 100% standard compliant, that's what I meant with >>881905

>>881895

>>882082

But I'm encoding AV1 not VP9.

aomenc --codec=av1 --webm -p 2 --pass=1 --fpf=niggers.txt -t 8 --lag-in-frames=25 --end-usage=cbr --target-bitrate=<X> --bias-pct=0 --auto-alt-ref=1 --tile-columns=6 -w <X> -h <X> -o "NUL" "input"
aomenc --codec=av1 --webm -p 2 --pass=2 --fpf=niggers.txt -t 8 --lag-in-frames=25 --end-usage=cbr --target-bitrate=<X> --bias-pct=0 --auto-alt-ref=1 --tile-columns=6 -w <X> -h <X> -o "output" "input"

CQ modo doesn't werk, it won't open the input file for some reason.

>>880551

>>880552

>>880554

ffmpeg will not always match the fs parameter. It will try, but a lot of other options are needed to get close.

The key is deciding the bit rate & screen size. Calculating the bit rate will determine the rate available for the screen size, so I'll look at the bit rate - since it really is the deciding factor in all of this:

1.5hrs = 5400s = A

16MiB = 16777216bytes = 134217728bits = B

B/A = 24855b/s = 24.8kb/s (b=bits, also - if you said 24.9kb/s the file would end up be larger than 16MiB, so you have to round down to 24.8, not up to 24.9)

24.8kb/s is extremely low. This is the total bit rate for both audio and video!

Decent audio only with no video is 96kb/s upwards.

So in short it is possible, but it will look nothing like the original. (Probably more of an animated icon, with accompanying background hiss)

Find more on encoding in >>>/webm/

>>882085

>>882083

You can search for such multi-thread two pass encoding scripts online, or have a look in >>>/webm/

>>880546 (OP)

The next version of the webm spec includes av1 as a codec option along with vp9 and vp8.

>>882108

>CQ modo doesn't werk, it won't open the input file for some reason.

perhaps it only means that aomenc is trash atm.

unless you develop something with it, better to just wait.

Will AV1 content run on Raspi3, and with what resolution?

>>880550

APNG

>>882651

>>880550

APNG and MNG

Both are supposed to be successors to GIF

Both fail horribly since no one can decide on which to use.

PNG itself is dated and only supports up to 8bit per channel

http://flif.info/

flif will support up to 16-bit, better compression, better interlacing with nearly no filesize increase, animations (also interlaced)

It's just a matter of time and contributions until it's finished and can be implemented everywhere

>>880550

I think Netflix is using AI to do just that.

>>882724

forgot to mention that PNG eats CPU for gamme used for crts

>>882724

what is up with every open source crap and shit naming conventions. hur dur upload a flif.

>>882728

*gamma

>>882724

>flif

>animations

for video, there are better codecs already (H.264, VP9) and yes they allow lossless mode as well.

there's no fucking reason to drop proper motion prediction as soon as you call it "animation" for some reason. and most bloated GIFs are in fact not an "animation", but a slices of photorealistic content for which proper video codecs are specifically optimized.

Who cares? 360p source footage will look like dogshit no matter how you encode it. Also 3D and 3DPD shit is a useless metric. I want to see 2D anime comparisons, 1080p, with lots of stark red on black coloration like Kill La Kill.

>>882738

>That's true but we're talking about the ones that are.

>1.51 MB

I didn't bother to look because I've blocked all .gif URLs but "real animation" doesn't take this much size unless it's overlong

>>882740

>491x750

GIF compression is just shit at bigger sizes

>>882741

The developer is pretty overconfident

Look at the to do list

A format will only be widely implemented when it's clear that nothing changes

>>882742

there are only a few cases when it's not total shit

(notably, GIF beats PNG at encoding 1x1 transparent pixel, which is commonly used in (((web))) for bullshit purposes)

>wanting websites to fingerprint your viewport resolution when resizing flif images

wow, the absolute state of nu/tech/

>>882815

it is already possible with javascript

>>882831

There are noscript larpers who think they are safe with current day CSS+HTML. FLIF would be another nail into their paranoia coffin.

>>882837

how many websites are 100% usable without javascript?

>>882815

This is implementation dependent. You could disable it or change quality per size then it would no longer work.

I'm not sure that even if the format got support that that feature would also be used.

>>882840

also be used.

also be implemented.

>>882040

Pardon my stupidity I'm still entirely new with encoding and I'm a little sleep deprived so my reading comprehension might be lowered but are you saying crf without 2-pass is better than non-crf 2-pass or that 2-pass crf is better than single pass?

>>882985

Two-pass crf doesn't exist as far as I know

>>882986

As far as my experience goes, Two-Pass encoding makes a difference even in lossless mode in VP9. So yeah, Two-Pass CRF does not only exist but also makes a difference (at least in file size).

>>882991

What software lets you do two-pass crf encoding?

>>882993

ffmpeg

>>883002

Well fuck handbrake then, you can't pick both two-pass and crf

>>883005

handbrake is just a shit gui front-end for ffmpeg. git gud with ffmpeg cli. it's not that hard.

>>883033

>anons start using still-experimental av1 codecs

>overnight, every new anime rip available from active groups is reencoded

>years before av1 spec is ever commercialized, it becomes impossible to find vp8/vp9/avc/hevc fansub releases

Good or bad?

>>883006

Have you ever tried to rip a track from DVD or Bluray with ffmpeg? If not, I suggest you STFU.

>>883041

>anons start using still-experimental av1 codecs

It would be pointless to encode anything and expect the file to be compatible with the final bitstream.

>overnight, every new anime rip available from active groups is reencoded

You mean over week/s. Encode times are absolutely abysmal, but to be fair they said they haven't optimized the encoder yet.

The first quarter of this year is almost gone and they're still not done. I really wanted to be excited for AV1, but they've pulled some of the best features like daala transforms and perceptual vector quantization. All because they were worried older hardware couldn't handle it.

>>883071

yes, and your a fucking idiot if you cry about merging a few dvd files together and pumping them into ffmpeg and insist on using a bloated gui instead.

>>883071

cat [dvd files] | ffmpeg -i - [encoder/options]

>i need gui pls help

>>883076

>>883077

You have simply concatenated vob files together, not selected a title. Try again.

>>883077

>>883076

I would also like to point out that you would know this had you owned physical media and not dumpster dived like a filthy peasant.

>>883082

>how is ffmpeg going to handle the useless output of yet another bloated GUI

how about you merge the files that are longer than 30 seconds like the gui bloat is saying it's going to do.

>>883084

>paying for propaganda

>>883088

Not a solution

>>883089

Way to avoid answering

Why don't you faggots pipe down the next time someone brings these programs up? They're not meant for you.

>>883090

the one that you've opened and identified as being the start of the movie, then count up. it's not that hard.

>>883086

MakeMKV is also proprietary. how about you just use windows instead and pay for a digital downloadable version since you seem to love giving Hollywood money.

>>883093

You have successful encoded a menu into the main title. Congratulations.

>>883094

Because I can rip the DRM from it and supply you mouth breathers with more content.

>>880546 (OP)

AV1 is a codec, .webm is a container.

AV1 will be supported in .webm

AV1 is the future, no one wants to pay royalties to the HEVC guys anymore.

Also, AV1 is the best thing right now regarding quality.

>>883071

have you ever tried to have brains?

>>883073

>they've pulled some of the best features like daala transforms and perceptual vector quantization. All because they were worried older hardware couldn't handle it.

shit

I see some bags of money definitely changed hands

next time HEVC2 uses something similar they will convince everybody that hard decoding is okay

>>883095

WTF are you talking about? looks like complete horse shit

>>883308

according to the ffmpeg manual -hwaccel is only for decoding, it's not going to automatically try to encode with hardware.

i had to look it up because I was going to say, watch it enabling hardware encoding automatically, because hardware encoding can be inferior by a lot depending on the gpu. the intel hardware encoder for example, with h264 atleast, is shit. it's fast, but there's considerably fewer knobs to turn for quality/size and no matter what you do your going to get something that looks like shit and is twice the file size than with the software encoder.

i'm sure it varies by gpu even between intel gpu's.

>>883310

Yeah, I heard that as well, but all this information is pretty old and FFmpeg updates quite often so I just didn’t bother with removing it.

>>883308

>depreciated

Lrn 2 spel gud

>>883308

>-frame_duration 60

confirmed as useless by an Opus developer who obviously knows better.

>>883308

>Opus beats Vorbis

I've heard it's only true for bitrates smaller than ~160, and otherwise Vorbis is at least just as good and requires less work to decode.

that is if you target 100% transparency, you may as well use Vorbis.

>>883142

Oh, you also have mixed french and english for some strange reason. This is why concatenating VOB files is NOT A SOLUTION.

>>883613

I’m retarded and confused the post numbers.

>>883613

It's https://en.wiktionary.org/wiki/deprecated

>>883631

Fuck.

>>883613

>Opus is pretty much transparent at 128 kbit/

nah, there are some killer samples.

>>883613

>I’d just use FLAC in such cases

Musepack, or even WavPack-hybrid can also guarantee transparency while using less bits.

FLAC makes sense if you are archiving or are planning to do further editing.

>>883613

>I did some tests and it slightly decresed the file sizes.

while producing exactly the same decoded audio stream? if not, you can't simply compare file size.

>>883550

okay, not-a-solution guy, then what about you go and solve your special snowflake problem by yourself instead of bitching about your made up issues here

>>883636

>while producing exactly the same decoded audio stream?

Don’t really know. Not so much of an audio guy. Only know how to squeez stuff under 16 MiB.

>>883685

then you can do this by decreasing target bitrate or quality, you know

file size doesn't mean anything if you also don't know quality

>>883631

i was going to argue with you but your right

i even checked the linux kernel source, they use deprecate

>>883685

you can get decent audio with HE-AAC (mp4 container) with 8kpbs. i've done it with the vegas audio and squeezed two hours worth of audio in. I think it's better than opus for that.

https://trac.ffmpeg.org/wiki/Encode/AAC#fdk_he

I think h264 is more efficient video stream wise for sticking a single background image in over vp9 too (to merge with the above audio, 8ch won't let you post an mp4 without a video stream), there's a tune setting for it.

>>883692

>I think it's better than opus for that

at that point it gets subjective --- which artifacts you find less annoying.

also Opus is free and not patented.

>I think h264 is more efficient video stream wise for sticking a single background image in over vp9 too

don't forget to reduce frame rate to something like 1/100.

the tune setting is cool but the difference would be tiny if you only have a handful of frames and maybe only 1 keyframe.

I'll just leave this here:

https://wyohknott.github.io/video-formats-comparison/

(AV1 will be added when bitstream is frozen, i.e. early April)

>>883789

>everything is in yuv420 from the beginning

this is an unfair test

Just adding to the discussion: they will use AV1 to kill .jpeg .jpg .png .gif

>>883892

PNG is here to stay. but it's no big deal, it's lossless and supports most of the useful color spaces, bit depths, etc.

for others, it would be a good riddance. also, fuck webp, it's a stupid format.

>>882837

My browser doesn't support javascript. Or css. Or images. How's that for larping?

>>884109

>doesn't support javascript. Or css. Or images

it's not a browser

>>883892

They will use a HEIF format: https://aomediacodec.github.io/av1-avif/

>>884143

(((they)))

>>884143

>av1-avif

>avif

P-pure coincidence.

>>883892

I'm totally waiting for this to happen.

This will kill:

* JPEGsixgazilion (the next slightly improved JPEG),

* WebP(made from garbage code),

* HEIF(just the shekels from video aren't enough for (((them))))

* GIF(which will die anyway)

* all other lossy image formats

>>883892

>>884143 seems to be right:

https://github.com/AOMediaCodec/av1-avif

>This is a (((Netflix))) DRAFT proposal for a still image format specification. This document describes how to use ISO-BMFF structures to generate a HEIF/MIAF compatible file that contains one or more still images encoded using AV1 intra-frame tools.

>The target use case for this format is for delivery of image assets.

>The specification is written using a special syntax (mixing markup and markdown) to enable generation of cross-references, syntax highlighting, ... The file using this syntax is index.bs.

>index.bs is processed to produce an HTML version (index.html) by a tool called Bikeshed (https://github.com/tabatkins/bikeshed).

>The repository contains both the input and the result of the Bikeshed processing.

are there other proposals?

>>884193

>the next slightly improved JPEG

there's little that can be improved while staying withing this crappy format.

mozjpeg does almost everything that's practical, except for per-image QT tuning, and targeting some even better quality metrics. Both of these things are unlikely to give big improvements.

JPEG's color space (YUV) is not really good for decorrelation of data usually found in photos, it sucks massive balls with red tones in particular. And after color space conversion it has no ways to exploit remaining correlation across channels. JPEG also can't do anything to reasonably compress lower frequency data (that is, "wavelengths" longer than these 8 pixels)

>>884204

>mozjpeg

I wasn't referring to JPEG which will stay because of the mass of pictures encoded in it but to JPEG 2000, XR...

>>884206

these are completely different formats.

the naming is just an attempt to get recognition (or not).

>>884193

>* WebP(made from garbage code),

the problem is not the code, which can be fixed at any moment anyway.

the format itself is gimped as fuck and there's no way around it.

the lossy variant is literally worse than JPEG as it can't encode chroma channels in full resolution (only YUV 4:2:0), thus never achieving transparency on many images.

also, no >8 bit support for lossless.

>>883892

video codec is not the ideal solution for single images, because there are a couple more things that can be done to compress images more efficiently that are problematic for video codec.

for example, a next-gen format can use per-image (or per-tile) color matrix which gives the best decorrelation for this image (or tile). this would be a bit over the top for video because it won't mix well with motion prediction, but a pure image format doesn't need to deal with motion prediction.

but people are too lazy I guess.

>>884143

>>883789

Since you guys are also interested in images, I also have:

https://wyohknott.github.io/image-formats-comparison/

(yuv420 still)

What is the optimal codec/decoder filter for playing old DivX/XviD videos on a Pentium II machine? Very old ones from say 2000-2003 will obviously be unoptimal generally due to being immature, while those from maybe 2006 and beyond could be unoptimal for such and old system due to being geared towards newer systems (SSE, SSE2 etc., significantly higher clock speeds, and so on). What would be the sweet spot for codecs/decoder filters to get the most out of a Pentium II?

>inb4 not a retro thread

yea but it's a codec thread, better ask here than in the general sticky (where if a question doesn't get answered within the 20 posts that follow it the it probably won't at all)

>>884283

given such an extreme CPU constraint and unusual format, I'd just test which one can work in real time leaving enough CPU to also deal with audio, etc. and call it a day.

quality difference would be small, and you are only viewing the result of decoding, not using it in any other way, so not a big deal.

you probably don't have a great monitor anyway?

>>884283

Throw it out and get an ARM SBC

>>884284

>>884285

It's a retro computer running Windows 98 SE and used every now and then to do retro things. "Throwing it out" or replacing it with with something else defeats its purpose.

>you probably don't have a great monitor anyway?

It has a CRT with a Trinitron tube, so for its day it was actually quite good I guess.

>>884284

It's about finding the optimal-performing decoding software for a CPU which is restricted to MMX only (no SSE and beyond) and has a clockspeed in the hundreds-of-MHz ballpark.

>>884303

Have you tried VLC media player with KernelEx?

>>884303

>retro things

>digital video playback

It's a shame you didn't find a brain in the trash can next to that PII

>>884305

>KernelEx

I refuse to use things like KernelEx on a retro system. While it doesn't need to be 100% period-correct, using KernelEx reeks of desperately trying to make an old system as modern as possible (possibly to use it as a main system). For the same reason I wouln't equip it with things like USB 2.0 or SATA controller cards.

>VLC

Probably optimized towards much newer systems, expecting or even requiring at the very least SSE1 (or even SSE2).

>>884309

Firstly it's not a dumpster find but a system I had owned for the better part of the past two decades. Secondly, while it may be surprising to you, a Pentium II was very commonly used for video playback back in the day (computers still were kinda expensive while performance increases were very substantial, you needed a completely new machine at least every 18 months or so to keep up with hardware progress but only richfags could afford that). It handles MPEG1 effortlessly, MPEG4 (such as DivX/Xvid) quite well if the resolution and bitrate are not too high (but the decoder performance could be of significance to get the most out of it, hence my question), and even MPEG2 (DVD) if the CPU is at least 300 MHz, both DVD reader and hard disk work in DMA mode, and the decoder is performant enough (very old versions of WinDVD or PowerDVD help very much, past the year 2000 they were not sutable for Pentium II anymore, requiring at least about a Pentium III 600 MHz or so - suspect that something similar, if not as pronounced, is likely the case with MPEG4 decoders)

>>884320

>[autistic screeching]

You can do video playback better and using less power on a 5 burger coupons ARM board than on a relic of that tier, it's not a task that needs retro hardware to be accomplished with perfect results like a retro game on a system with no/poor emulators

>>883674

I've already solved it multiple ways, none of which involve ffmpeg. Why don't you concede that you're a retard who doesn't know what he's talking about and never come back here.

>>884320

>I refuse to use things like KernelEx

It's a compatibility layer.

VLC media player runs well on everything I ever tried

>refuses to use new software

You didn't state that the software has to be old too (which makes no sense)

Old VLC versions don't require the layer which probably doesn't add more than a few CPU cycles for decreased maintenance

https://www.videolan.org/vlc/download-windows.html

>>884326

The system is supposed to do typical retro things like 1990s games etc. but also to play back early 00s videos/movies as best as it can without resorting to shoehorning modern software into it via KernelEx or similar (and I still have my reservations about if it even would really be successful in the first place). Sorry if that perplexes (or offends?) (You).

>>884342

>play back early 00s videos/movies as best as it can

There is no reason technical or practical why it should when there are better alternatives available for a pittance

>>884342

I SAID OLD VERSIONS DON'T REQUIRE TH LAYER YOU RETARD. NOW TRY IT AN TELL US IF IT WORKS AND HOW WELL

>>884347

I have asked precisely because not wanting to go through the ordeal of reinstalling and benchmarking dozens upon dozens of old Xvid/ffdshow/whatnot versions in the case the information I need (i.e. what codec/filter and what version would be optimal in the given case) is already known. Should have anticipated though that what I'd get would be >hurr why would you even want to do that in the first place retard to [something else entirely] instead

and/or

>hurr just go ahead and try ALL THE THINGS yourself (even if you'd reinvent the wheel and the kitchen's sink in the process)

>>884338

>It's a compatibility layer.

But one which aims to enable runnig software that is way out there in terms of being "period-correct". In the given case, it'd be like trying to run a somewhat modern forceware driver with an ancient-ass Riva TNT by means of stopgaps, hacks and trickery, all the while deluding oneself it would somehow increase the ancient card's performance (while in reality it would more than likely be the exact opposite - as a matter of fact, for any given GPU there's a driver version which is the sweet spot for that particular GPU performance-wise, because older versions are not mature enough, while newer versions are optimized towards newer GPUs).

>>884355

>not wanting to go through the ordeal of reinstalling and benchmarking dozens upon dozens of old Xvid/ffdshow/whatnot versions

>doesn't want to use the current version

>has to use old os because >muh vintage

>has to use old software because >muh vintage

>doesn't even want to try it himself

Do you expect me to install W95 in a VM because you're a lazy faggot?

What are you even trying to achieve? I thought that you seek fun in playing around with that old OS? If you don't then what's the point of your vintage machine?

>>884359

There is something called fallback, Windows 95 isn't THAT old and VLC not THAT bloatet.

It runs PERFECTLY on a Pentium M.

Sadly I don't have anything older lying around to try it on.

Either you install that layer(best option), you pick an old version, or you fucking install GNU/Linux and install VLC player there.

>>884359

>stopgaps, hacks and trickery

No. Just makes up for a few missing features. It's still Windows.

>>884065

>>884143

>>884193

>>884203

>>884212

An earlier press release about it:

https://www.cnet.com/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/

That's why I say whenever I can: don't buy anything now, AV1 and its derivates will make it big, a huge impact, and will make things without hardware support for it obsolete and on the verge of unusability pretty quickly.

>>884462

>cnet

trash

>>884369

>install 2009 ubuntu on Pentium II computer

>xorg eats 25-30% CPU all the time at idle (not even using a DE but just a WM

no thanks

>>884463

OMG! YOU DON'T SAY?

WANNA TRY FINDING ANOTHER SOURCE FOR THIS PRESS RELEASE?

>>883892

AV1 is rediculously slow and the lossless mode doesn't even look lossless--it's blury and the colors get darker. Sure, they might fix it but I kinda doubt.

https://wyohknott.github.io/image-formats-comparison/report.html

>>884491

>lossless mode doesn't even look lossless--it's blury and the colors get darker

then you've done something wrong

>>884466

>ubuntu

Why am I even talking to you?

>>884143

I've only just heard, Microsoft will add native support for HEIF to Windows 10. Now that Apple and Microsoft will have HEIF support out of the box, hardware manufacturers will begin adding it to digital cameras. AVIF may be dead in the water. Too little too late.

>>885053

>each camera supports a single picture format

>>885053

it doesn't matter which format is used for stills, all photos that matter are shot in raw.

for video --- it also won't matter as the quality of hardware encoders is a completely different thing. they aren't even using the full potential of H.264.

>>885102

You've made the mistake of believing best equals most used. Mom and Pop don't give a shit about raw. If they can get 500 images verses 20, they're going to use it.

>>885135

they also don't need good cameras and their output would mostly be worthless

>>885053

Irrelevant if Android gets native AVIF support, which is pretty much guaranteed considering (((who))) is developing+sponsoring AV1.

>>885147

Android is getting native HEIF support. Meanwhile AV1 isn't even finalized. I'll be happy to see one of these image formats replace JPEG, but I just don't see AVIF getting more support at this point.

>>885153

It's all about the Royalties.

I save everything to .wmv

>>886222

>not .rmvb

>>882081

MKV supports a lot of shit, vendors may not want to implement all of it. Clamping down on a standard subset is necessary sometimes. WEBM is artificially limited for this purpose, when you say MKV it could mean anything, with WEBM you know it's more than likely a VP8/VORBIS or a VP9/OPUS so if you account for these you can be compliant without supporting MKV and everything it could contain.

>>885644

What's the defacto encoder? I remember having trouble downloading the source for one before, they said it was public but you had to request it via a form.

I usually wait until I can encode and decode a format before going crazy and migrating all of my stuff over with it. if ffmpeg and mpv support it, I'll use it almost exclusively.

For the moment I'm using HEVC for a lot of things, the lossless encoding has saved me a ton of space for some of my old RAW footage that was encoded to lagarith and now HEVC-lossless. Does AV1 have a feature like this?

>>886575

>Does AV1 have a feature like this?

Should have but you need to test if it is really lossless (as usual)

>>887214

>Given that I only update my lossless collection once every few years, I'm willing to accept week long encodes for that space tradeoff. Adding new things can take days but I don't produce things daily so it's okay for my use. I'm sure in time things will get better as software gets optimized and hardware vendors potentially add support.

Good luck decoding pre-finalized bitstream with future decoder versions.

>>887323

what about 10-bit x264?

how does it compare?

>>887420

your comparison sucks because you picked different frames

>>887420

>jpeg comparison

2hu truly rots your brain

>>887227

Always keep the binary used to encode the media, with the media, for this exact reason. I place mine in the root of the directory under "/encs".

My problem hasen't been that as much as it's been, the tools become unavailable because who is keeping pre-release encoders up on their site.

>>887420

>comparison images

>ruined by jpg compression

You blew it.

>>887926

you're still comparing different frames you dinghole

go fix your seeking first

>>888062

Did you even read his post?

>>888372

Did anyone ever do this? I thought kinopak was Apple's.

>>887805

>>887227

If I recall correctly, Matroska allows you to embed the decoder with the video. Not that a single player uses this feature but still.

>>888372

inefficient crap

>>888068

it was reply to >>887940 probably --- just a wrong link

>>888062

AV1 looks worse here? what the fuck?

>>888653

Hey William Tell, can you not throw shit around people's heads? Thanks.

>>888569

That's interesting, seems somewhat pointless given platform differences unless they have their own method of handling it. I keep the source and a bin with my stuff and clean it out when I migrate.

General question about AV1 (and JVET, to a lesser extent): What are the chances chroma subsampling will be thrown in the same dustbin of history as interlacing? With modern lossy encoding, there is zero possible reason to ever cut the resolution of a channel instead of simply cranking up the compression (especially given the effects of interframe compression).

>>888653

Video Spigot wasn't a company, but (like Cinepak) a product of Supermac, which was one of the niche Mac-specific hardware vendors that existed in the NuBus/PDS days. They did license it a ton, and it was probably the most popular of the pre-MPEG codecs.

hxxps://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

AV1 just got its 1.0 release.

What now?

Some of its block predictions are fairly good but the deblocker is fucking awful, the blocks are way too big compared to VP9.

Even with a reduced keyframe interval it still looks like shit outside of still scenes despite the output webbum clogging up all of India's server storage.

Does any man on this vaccuum tube cleaning board know some encoder options that result in comparable quality+filesize to ffmpeg VP9 encodes based on guide related?

when will 8ch accept AV1 webbums?

>>890172

Encoders can evolve even after the codec spec is frozen, as is the case with x.264

>>880546 (OP)

AV1 officially released

https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

>>890202

Read the fucking thread

>>890204

Yeah my bad, didn't see the link since it got broken down

>>890208

>>890211

>>890172

oops

>>890208

Is this encoded in AV1?

>>890241

obviously not

>>890172

<hxxps

http://archive.fo/lt6gO

>>889240

>General question about AV1 (and JVET, to a lesser extent): What are the chances chroma subsampling will be thrown in the same dustbin of history as interlacing? With modern lossy encoding, there is zero possible reason to ever cut the resolution of a channel instead of simply cranking up the compression (especially given the effects of interframe compression).

Probably not a big chance but I agree that it's stupid and should not be done. If a coder has problems with low frequency information (like JPEG), that's the problem that should be fixed, instead of using subsampling which unconditionally destroys quality, often producing a big drop of efficiency overall.

(on many pictures WebP completely loses to same-size JPEG because of forced subsampling, even though it's supposed to be more advanced and to outperform it)

At least I hope that chroma subsampling would be optional in more places and people will learn to simply disable it.

HEVC takes 7 times longer to encode than H.264. Is AV1 any better?

>>895039

Oh yeah like light years faster. You should give it a try.

>>895039

if enough bags of money changes (((hands))), it will become better.

right now it would take years to encode any movie.

>>895039

It takes 3.7 Billion years to encode a 3 minute 720p video on some Intel CPUs, an FX 8350 takes around 12 hours and it looks like utter shit compared to VP9 at the same bitrate.

There's compression artifacts everywhere right now but it does look intredasting in how well it handles certain color gradients/distortions, complex patterns like wood grain and movement annihilate it at webbum-tier bitrates though.

I suppose the reference encoder is simply a pile of shit at the moment, we should be seeing some real improvements once ffmpeg gets AV1 support.

>>895107

Dumb image. When you're light years from someone, it implies that, even if you could travel at light speed (you can't), you would still take years to face him.

>>895113

Wrong. I could reach Andromeda before I die if I had a space ship fast enough.

>>895113

he-he, but years from which reference?

you seem to not understand relative physics.

What about https://github.com/xiph/rav1e ?

>>895117

>Input videos must be 8-bit 4:2:0, in y4m format.

Wow it looks like they have done so much work from the standard encoder. I would definitely shill again.

https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml

>>895114

Yea but for anyone else (specifically both back on Earth and at the destination) millions of years would pass. Effectively it would be a one-way tip to an Andromeda galaxy millions of years in the future. The specific destination (like a specific continent on a specific planet in a specific star system in a specific spiral arm of Andromeda) may not even exist anymore. Going back to Earth you may find that Earth itself fell victim to a greenhouse effect and is now a hell just like Venus, while a tribe of Muskenites has established a civilization on Mars. Or, given it would be many millions of years, maybe they too have managed to destroy their habitat and themselves, or maybe spread out elsewhere.

>>880883

>where do you think you fucking are?

/g/

>>880598

It's actually 15 years ago.

>>896473

>sucks cartel dick

>smugs at others

>>896473

Someone should write a nyaa-get, like pirate-get

>>896467

Which took acktually took place in ancient Japan.

>>901671

>latest ffmpeg

fug, apparently it's not in macOS homebrew yet…

Isn't encoding av1 still like an order of magnitude slower than x265, which is already fairly tedious tbh.

>>902150

>10 fps

that's pretty useless

>>902153

>10fps useless

10fps is pretty standard for an entire movie under 16Mb, as is mono instead of stereo for audio.

Does anyone know how to change the thumbnail image on a webm? ffmpeg will do mp4, but balk at webm, and exiftool likewise lacks support for writing a thumbnail to webm.

>>902168

>entire movie under 16Mb

useless as well.

unless it's also very short.

>>902178

>useless as well.

>compression, optimization, and pushing technology limits is useless.

If you think this is for an IMAX presentation you might not know much about the demoscene. Scratch that, you won't even know it exists.

>>902150

If you'd split it in two you could increase the quality.

>>901821

We can't compare while the av1 encoder hasn't received a single optimization.

>>902183

>If you'd split it in two you could increase the quality

>doubling the size can increase the quality

Obviously.

The point wasn't quality, the point is

1. achieving the smallest possible file size for the complete video, then

2. the best quality possible at that minimum file size.

>>902192

>peak autism

But if the result looks like shit you have wasted your time.

>>902193

>peak consumerism

>if the result looks like shit you have wasted your time.

You're using an entirely incorrect set of comparison parameters.

>looks like shit

The use of the word "like" indicates you are making a comparison to your expectations. However, such expectations (parameters) you use are invalid and nonsensical when applied to a 16Mb complete movie.

Compared to expectations of 4K, IMAX, 1080p, and other standard movies of HUNDREDS OF MEGABYTES? - Yes, it obviously "looks like shit" because it's LESS THAN 16 FUCKING MEGABYTES FOR OVER AN HOUR WITH FULL AUDIO AND VIDEO!

Compared to full movies capable of being played on very limited hardware systems? - No. It looks fucking awesome.

>>896473

>not getting it directly from the subbers

>wanting his torrent feed to be dictated by horriblesubs

Nigger, please.

>>902182

>scene

goback2reddit

>>902205

>very limited hardware systems?

for example?

who in their right mind makes movie players with only 16 MB of storage space?

>>902210

>le leddit

No fa/g/got. Having knowledge about /tech/ subcultures doesn't equate with coming from r​eddit, but not knowing that equates with you arriving from /g/.

>>902215

>for example?

Pick an SBC of choice.

>who in their right mind makes movie players with only 16 MB of storage space?

The same kind of people that would use a computer with only 48Kb.

>>902215

>who in their right mind makes movie players with only 16 MB of storage space?

…and which are, on the other hand, capable of decoding such a complex video format?

how about you get back to real life?

>>902192

>1. achieving the smallest possible file size for the complete video, then

why not 8MB or 4MB then?

it's totally possible to get smaller.

>>902182

>Scratch that, you won't even know it exists

kek

>>902182

>>compression, optimization, and pushing technology limits is useless.

…while targeting some real goals and not some made up shit.

for example, what about aiming to achieve lowest file size with no visually noticeable distortion. this would be actually useful.

or does VP9 still lose to x264 in that regard?

>>902218

Stop being a butthurt faggot, you're disgusting

>>902217

>Pick an SBC of choice.

They don't make sd cards smaller than 4GB anymore

>>902223

>>SBC

>SD cards

Wut? Many SBCs don't have SD card interfaces.

>>902218

>…while targeting some real goals and not some made up shit.

>I'm jelly I never thought of it

jej

>>902222

quads of ultimate truth

>>902222

not an argument

>>902222

>>902321

>not an argument

no, it's

>>902301

>quads of ultimate truth

>>895115

>Reference

From where they are in the moment they had the conversation to the point where Brock is, in cartesian coordinates.

Also, relativity hasn't been proved and is actually being disproved by the day.

It seems you don't understand physics.