Video Codecs

the webm is showing h265 vs av1

Webm vs AV1
which is the future?

Attached: AV1 Videocodec [360p].webm (640x360, 4.07M)

Other urls found in this thread:

github.com/qyot27/CorePNG
flif.info/
en.wiktionary.org/wiki/deprecated
trac.ffmpeg.org/wiki/Encode/AAC#fdk_he
wyohknott.github.io/video-formats-comparison/
aomediacodec.github.io/av1-avif/
github.com/AOMediaCodec/av1-avif
github.com/tabatkins/bikeshed).
wyohknott.github.io/image-formats-comparison/
videolan.org/vlc/download-windows.html
cnet.com/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/
wyohknott.github.io/image-formats-comparison/report.html
aomedia.googlesource.com/aom
aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/
twitter.com/NSFWRedditImage

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

also how do i compress this video to a webm to 16mb.

Attached: 54.png (868x551, 177.49K)

Run ffmpeg with the fs parameter set to 16MiB.

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.

Not possible bud. Just split it into multiple parts.

Fuck av1 where's daala?

github.com/qyot27/CorePNG

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

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.

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.

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.

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

It's called GIF.

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?

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.

Really? Could you share such script?

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.

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

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= --bias-pct=0 --auto-alt-ref=1 --tile-columns=6 -w -h -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= --bias-pct=0 --auto-alt-ref=1 --tile-columns=6 -w -h -o "output" "input"
CQ modo doesn't werk, it won't open the input file for some reason.

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/

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

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

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?

Attached: 334a6cb3ad37456b3eae6956e0793ebda2e073bef86333489017f5524f72c272.png (900x675, 900.88K)

APNG

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
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

I think Netflix is using AI to do just that.

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

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

*gamma

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.

That's true but we're talking about the ones that are.
Those are completely different They often even contain different frame rates for single layers.
They are either real animation or a static image with some elements animated.
And because GIF is the only widely supported option great art gets ruined through shitty 255 colors and 1 for transparent

Attached: Dead_City_by_Mark_Ferrari.gif (298x164 1.51 MB, 199.27K)

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

I'm sad that FLIF will realistically never take off. I tried it and it's much better than PNG but fucking nothing supports it.
But, since PNG just werks and normalfags are retarded nobody will care enough to support it.
I hope I'm wrong, but I'm not holding my breath.

Attached: starting to get sad.jpg (287x343, 19.15K)

GIF compression is just shit at bigger sizes

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

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)

wow, the absolute state of nu/tech/

it is already possible with javascript

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

how many websites are 100% usable without javascript?

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.

also be used.
also be implemented.

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?

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

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).

What software lets you do two-pass crf encoding?

ffmpeg

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

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

Apparently gstreamer 1.14 has experimental support for mkv-contained AV1.
Does it werk?

Attached: chair spin.gif (266x355, 143.63K)

Good or bad?

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

It would be pointless to encode anything and expect the file to be compatible with the final bitstream.
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.

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.

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

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

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.

Here we go. How is ffmpeg going to handle this, genius? I don't even know what fucking track the real one is.

Attached: Screenshot_2018-03-14_22-51-36.png (1920x1080, 222.88K)

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

...

Not a solution

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.

21 tracks tell me which ones to concatenate for the main title.

Attached: Screenshot_2018-03-14_23-05-51.png (858x673, 132.14K)

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

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.

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

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

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.

have you ever tried to have brains?

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

WTF are you talking about? looks like complete horse shit

FFmpeg isn’t really that hard to use (unless you want to replace After Effects with it but even then it doesn’t become as much “hard” as just “too verbose”).

Here’s how my command looks like (if I have plenty of time on my hands):
ffmpeg -hwaccel auto -y \ -i $INPUT -map 0:v:0 -map_chapters -1 -map_metadata -1 \ -c:v libvpx-vp9 -pass 1 -threads $THREADS \ -deadline best -cpu-used 0 -aq-mode 0 -auto-alt-ref 1 -frame-parallel 0 \ -lag-in-frames 25 -tile-columns $COLUMNS -row-mt 1 -crf $CRF -b:v 0 \ -f webm /dev/nullffmpeg -hwaccel auto \ -i $INPUT -map 0:v:0 -map_chapters -1 -map_metadata -1 \ -c:v libvpx-vp9 -pass 2 -threads $THREADS \ -deadline best -cpu-used 0 -aq-mode 0 -auto-alt-ref 1 -frame-parallel 0 \ -lag-in-frames 25 -tile-columns $COLUMNS -row-mt 1 -crf $CRF -b:v 0 $OUTPUT.webm

I’ll try to explain the options I use in the attached image file.

Another thing to note is audio encoding. WebM container only allows Vorbis and Opus codecs. Opus beats Vorbis (and every other lossy audio format), therefore Vorbis is depreciated.

Here's my command:
ffmpeg -hwaccel auto \ -i $INPUT -map 0:a:0 -map_chapters -1 -map_metadata -1 \ -c:a libopus -compression_level 10 -frame_duration 60 -vbr on -b:a $BITRATE $OUTPUT.opus

Unlike VP9, there’s really no reason to explain what all the options do because audio encoding is fast and these are objectively best options for Opus. Bit rate is controlled with -b:a #k. Opus supports bit rates between 5 kbit/s and 510 kbit/s (e.g. -b:a 96k). According to Xiph.Org Foundation, bit rates between 64 kbit/s and 96 kbit/s are good for music, 128 kbit/s and above give you transparent results. Bit rates below 64 kbit/s can still sound good but the results are less predictable, they’re recommended mostly for speech.

To merge the resulting files use this command:
ffmpeg -i $INPUT_VIDEO -i $INPUT_AUDIO -c copy $OUTPUT.webm

Attached: ffmpeg_vp9.png (801x961, 8.75K)

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.

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.

Lrn 2 spel gud

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

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.

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

I had a feeling that I might make a typo here so I double-checked with Aspell. So yeah, suck a dick.

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

Probably, but since Opus is pretty much transparent at 128 kbit/s, I don’t see any reason to use higher bit rates. I’d just use FLAC in such cases.

Attached: depreciated.png (510x510, 35.83K)

I’m retarded and confused the post numbers.

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

Fuck.

nah, there are some killer samples.

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.

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

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

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

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

i was going to argue with you but your right
i even checked the linux kernel source, they use deprecate

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.
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.

at that point it gets subjective — which artifacts you find less annoying.
also Opus is free and not patented.
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:
wyohknott.github.io/video-formats-comparison/

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

this is an unfair test

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

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.

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

it's not a browser

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

(((they)))

P-pure coincidence.

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

seems to be right:
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.
>index.bs is processed to produce an HTML version (index.html) by a tool called Bikeshed (github.com/tabatkins/bikeshed).

are there other proposals?

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)

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

these are completely different formats.
the naming is just an attempt to get recognition (or not).

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.

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.

Since you guys are also interested in images, I also have:
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?
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)

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?

Throw it out and get an ARM SBC

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.
It has a CRT with a Trinitron tube, so for its day it was actually quite good I guess.

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.

Have you tried VLC media player with KernelEx?

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

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.
Probably optimized towards much newer systems, expecting or even requiring at the very least SSE1 (or even SSE2).

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)

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

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.

It's a compatibility layer.
VLC media player runs well on everything I ever tried
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
videolan.org/vlc/download-windows.html

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).

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

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

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

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).

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?

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.

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

An earlier press release about it:
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.

trash

no thanks

OMG! YOU DON'T SAY?
WANNA TRY FINDING ANOTHER SOURCE FOR THIS PRESS RELEASE?

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.
wyohknott.github.io/image-formats-comparison/report.html

then you've done something wrong

Why am I even talking to you?

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.

...

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.

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.

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

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

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.

It's all about the Royalties.

GStreamer 1.14 is out with experimental AV1 support.
Anyone tried to see if it werks?

Attached: hardware decoding.jpeg (912x904, 324.69K)

I save everything to .wmv

...

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.

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?

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

The reference encoder is aomenc, git is at aomedia.googlesource.com/aom
Bitstream isn't frozen and I haven't managed to encode anything that didn't result in garbage, it's I wouldn't say it's ready for anything beyond experimental shitposting at this point in time.
aomenc --codec=av1 --webm -t 8 --lag-in-frames=25 --end-usage=cbr --target-bitrate= --bias-pct=0 --auto-alt-ref=1 --tile-columns=6 --frame-parallel=1 --aq-mode=1 --enable-dist-8x8=1 --frame-boost=1 --deltaq-mode=2 --single-tile-decoding=1 --cpu-used=8 -w -h -o "output" "input"

Attached: image.jpeg (2183x3056, 976.79K)

In my never ending stupidity I forgot to mention that aomenc only werks with .y4m raws at the moment.
However,
Pass 2/2 frame 199/180 317931B 1424695 ms 8.38 fpm [ETA 25:39:59]
fug :DD

Attached: e1a0ea0485baf9201a0a75d09ae52a503b350f2205899999c50e33d570d57407.jpg (1920x2159, 240.17K)

Thanks. Cute picture. I think my best bet right now is to wait until ffmpeg gets support in git, by then it should be "stable-enough" to figure all the flags out and then wait a little longer before using it for real, long term storage.

WEW
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.

Attached: best guess - Chinese woman in militia, armed with a Mauser C96 pistol (Second Sino-Japanese War)

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

Here are some screenshots from video encoded at 500kb 1280x720 from a 1600x900 source.
VP9 encode uses
-c:v libvpx-vp9 -b:v 64k -c:a libopus -b:a 500k -speed 1 -lag-in-frames 25 -auto-alt-ref 1 -frame-parallel 1 -tile-columns 6 -row-mt 1 -quality best -sn -ac 2 -y -cpu-used 8 -threads 8 -g 9999 -colorspace bt709 -vf scale=-1:720 -f webm -pass 2 ".webm"
An intredasting thing to note is that the 2-pass AV1 encoder apparently calculates the final(?) output filesize and reserves that space when creating the file, which then grows slightly while encoding(created a 6mb file which has since grown to 7mb after 3900 frames, whereas ffmpeg output files grow continously during encoding).

Attached: AV1.jpg (1280x720 103.79 KB, 85.12K)

what about 10-bit x264?
how does it compare?

Also aomenc is slow as shit, having ffmpeg running at the same time only slows it down by 0,20 fpm.
Can't show more than these on a christian imageboard.

Dunno, I'll try encoding some animu and see what happens.

Attached: AV1_2.jpg (1280x720 91.72 KB, 84.74K)

I-it turns I accidentally swapped the audio and video bitrates of the VP9 encode in my earlier posts.
H-here are some updated comparison screenshots pls no bully
VP9 and AV1 are both encoded at 500k bitrate.

Attached: source.jpg (1280x720 103.79 KB, 106.32K)

your comparison sucks because you picked different frames

2hu truly rots your brain

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.

You blew it.

Seems increasing the MTU size helps alot with quality.
aomenc --codec=av1 --webm -t 8 --lag-in-frames=25 --end-usage=cbr --target-bitrate=500 --bias-pct=0 --auto-alt-ref=1 --tile-columns=6 --frame-parallel=1 --aq-mode=0 --enable-dist-8x8=1 --frame-boost=1 --deltaq-mode=2 --mtu-size=6 --kf-max-dist=6 --large-scale-tile=0 --limit=260 --tune=daala-dist --cpu-used=8 -w 1280 -h 720 -o "output" "input"

Attached: source_2.png (1280x720 704.36 KB, 718.39K)

you're still comparing different frames you dinghole
go fix your seeking first

Here you go user, 500k bitrate as usual.

Attached: Asuka_AV1.png (1920x814 5.08 MB, 5.02M)

Did you even read his post?

Attached: Asuka_source.png (1920x814, 7.15M)

Attached: 1375737931699.jpg (243x240, 19.68K)

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

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

inefficient crap

it was reply to probably — just a wrong link

AV1 looks worse here? what the fuck?

Many games that had movie files used cinepak encoding, especially on Sega CD and Saturn, and I assume a number of PC games did.
It was supported by early versions of Quicktime, but the codec itself was made by Video Spigot. Video For Windows supported it as well.

The Joke.
____
Your head.

Attached: 1384458742647.jpg (470x747, 71.94K)

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

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.

AV1's deblocker is fucking trash.

Attached: VP9.png (1280x720 597.83 KB, 697.15K)

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).

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?

fuggin alacrity daemon eating pics again

Attached: ffmpeg_WebM_Guide_v1.0.1.png (2400x3420, 1.14M)

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

AV1 officially released
aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

Read the fucking thread

it's from march 28, isn't it new?

Attached: biys.mp4 (688x464, 8.11M)

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

oops

Is this encoded in AV1?

obviously not