[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: codec_comparison.webm (3.96 MB, 720x720)
3.96 MB WEBM
Does /g/ encode videos to AV1? I always assumed it was only useful for compressing blu-ray movies but I guess I was wrong. Also not trying to shill but I found a place that lets you share AV1 videos.

https://umigalaxy.com/explore/videogames/385
>>
>>108684424
yes. I compress ridiculously large 8k VR movies to AV1 for a more sane file size. I dont need a 50GB video of a pair of tits
>>
>>108684793
GPU or CPU?
>>
>>108684793
>I dont need a 50GB video of a pair of tits
Depends on the tits
>>
File: arc.png (258 KB, 1000x1000)
258 KB PNG
>>108684424
Yes
>>
>>108684424
CUTE CUTE A CUTE!
>>
>>108684424
I can't see a difference.
>>
>>108686044
Pay close attention to her hair.
>>
>>108686223
Oh yeah, it's softened on the right. I always turn off AA in games anyway, makes me feel like my glasses aren't on my face right.
>>
The day I bought my first 10TB HDD is the day I stopped encoding anything
>>
>>108686262
You can't see individual hair strands on the left. At low bitrates H264 will lose fine detail and turn everything into a blocky low-detail mess.
>>
>>108686283
Do you know which ~500 gram Tablets have a HDD slot?
>>
File: 움짤121.gif (691 KB, 400x225)
691 KB GIF
>>108684424
I have yes, I also re-encoded my music and converted my photos, but it was for a very specific purpose, I wanted to have all my media on my laptop's 1TB SSD in case I didn't have access to my NAS.
Afterwards I upgraded to a 4TB SSD and it became pointless. And good thing I upgraded when I did, dear God the prices are insane right now.
>>
File: 1762633828301296.jpg (36 KB, 460x518)
36 KB JPG
Is it worth investing resources into AV1 when AV2 is right around the corner? Like seeing how manufacturers really took their time adding AV1 hardware decoding support I'm a little worried this will also happen with AV2...
>>
>>108688592
>Like seeing how manufacturers really took their time adding AV1 hardware decoding support I
didnt shit tier android phones get support a decade ago?
who didnt have support? Apple?
>>
GPU AV1 looks like dog shit compared to GPU HVEC. The main benefit of AV1 is it uses less bandwidth which makes sense for Youtube, game streaming at a distance, low power machines in general that dont need to spend as much compute aka save battery life on a phone or laptop.

Always prefer CPU encoding/decoding for quality.
>>
>>108688637
lolno, most cheap Android phone lack the AV1 ASIC because it's 100% legal to use a 2017 SoC on a 2026 Android smartphone. I wish it wasn't though. That's probably why so many people have been switching to iPhones lately, AV1/Jpeg XL support is guaranteed now....

>>108688667
Not sure what you expected, GPU video encoding equals like x264 fast. It was never meant for high quality, like at all. It's just a giant speed hack kind of thing for streaming vidya on twitch/youtube. You're a moron if you're using it to personally compress video for yourself.
>>
>>108688711
People keep shilling AV1 but unless you're using DAV1D or no hw accel its awful.
>>
>>108688711
apparently qualcomm 430 from 2015 can decode av1 just fine
>>
File: 1767156581096524.webm (728 KB, 640x480)
728 KB WEBM
>>108688731
Through Dav1d so battery life becomes dogshit. An AV1 ASIC allows you to blow through like 10 hours of non-stop AV1 1080p video playback but only flagships have it right now because again it's 100% legal for phone manufacturers to use 2017 on 2026 phones. Making modern Android a joke desu senpai.
>>
File: 1751388274235801.png (323 KB, 1080x1254)
323 KB PNG
>>108688836
2017 SoCs*
>>
>>108688711
>Not sure what you expected, GPU video encoding equals like x264 fast. It was never meant for high quality, like at all. It's just a giant speed hack kind of thing for streaming vidya on twitch/youtube. You're a moron if you're using it to personally compress video for yourself.
Why can't GPUs beat CPUs in encoding in BOTH speed AND quality?
>>
>>108688865
gpus are designed to do many thousands of tiny tasks in parallel. as opposed to a cpu which is designed to do maybe a dozen large tasks in parallel
this makes them each good at some things and bad at others. cpus are slow and wasteful rendering graphics, and gpus are slow and wasteful trying to handle a big task
while there are parts of video encoding which can be done in parallel, it often comes at a cost of compression efficiency. thing about doing something in parallel is that each part can't rely on the result of any other part done in parallel, they all have to be independent, and video compression relies heavily on inter-dependent data to compress video.
gpu encoders have always existed for things like streaming, so people can record/stream their display without slowing down anything else, they're not even trying to be the best quality option, just fast and power efficient
>>
>>108688923
>while there are parts of video encoding which can be done in parallel, it often comes at a cost of compression efficiency. thing about doing something in parallel is that each part can't rely on the result of any other part done in parallel, they all have to be independent, and video compression relies heavily on inter-dependent data to compress video.
So video encoding for quality is fundamentally a very-low threaded application? Does that mean a single-core CPU would encode a higher quality video than a quad-core? As CPUs get more cores are video encodes just going to naturally get worse unless you physically limit the thread count?
>>
>>108688865
Hardware encoders need to be simple first and foremost. You can add arbitrary complexity to a software encoder.
It's not worth designing bespoke hardware just to save some processing power for encoding the newest Netflix slop at bitrates that would make me blush. For user content hosting, scale matters more than efficiency.
>>
>>108688865
>>108688923
also note that even on a cpu you get the most compression efficiency when using only a single thread, but video encoding is all about compromises, just saw you post >>108688949.
now of course, it's not like doubling the threads halves the efficiency, but it does have an effect. depending on what you're trying to do and what hardware you have you may opt to encode with less threads. especially sensible if you have many files to encode because you can still fully utilise the cpu that way and get some free efficiency
>>
>>108688949
There are bound to be diminishing returns, and without the requirement for real time there are also alternatives that'd allow parallelization without affecting results. For instance, older codecs would spread key frames everywhere - if you have n keyframes, you could technically use n threads to encode it as fast as possible without any resulting loss from threading. It just wouldn't work for real time.
>>
>>108688982
>There are bound to be diminishing returns, and without the requirement for real time there are also alternatives that'd allow parallelization without affecting results. For instance, older codecs would spread key frames everywhere - if you have n keyframes, you could technically use n threads to encode it as fast as possible without any resulting loss from threading. It just wouldn't work for real time.
I see.
>>
You "found a place". Pretty sure I saw you telling us how you finished vibe coding that place in another thread just the other day.
You can just tell us you made the website. Other anons have done that kind of thing. It's better than pretending you just came across it.
>>
>>108688949
>So video encoding for quality is fundamentally a very-low threaded application?
it's fundamentally something that can't be as efficient the more it's threaded, yes.
video is made up of HIGHLY redundant information, both spatially and temporally. ideally you want an encoder to have access to as much information surrounding what it's encoding as you can reasonably give it. things like tiled encoding where a frame is cut up into equal size pieces and encoded separately is a common way to speed up encoding and also speed up decoding (as the decoder can parallel-decode a frame, something to be careful of when using low encoding thread count), but naturally if you encode a frame in multiple independent chunks, they can't use redundant information between them, and any movement between them is doubled-up. this is just one example.
>>
>>108684424
Diana...
>>
>>108688865
The encoder on a GPU is a separate piece of hardware, or in other words it's a separate little part of the GPU die that is specifically designed to encode video in whatever codecs. I'm sure there are some knobs to tweak regarding how it does its job but in the end it's still a fixed-function piece of hardware and I would guess you do not have full control over the encoding process like you do in software, because some of the bits are just the hardware doing its thing, so you can't tweak them.

When you use a GPU's encoder it's not like you're running the compression algorithm as a GPGPU program on the actual shaders of the GPU, you're just using that little fixed-function encoder portion.

Also GPUs are good at extremely parallel compute. There are video compression algorithms out there that cannot even take proper advantage of all the cores a modern consumer CPU has, I'm certainly no expert in this field but if this is a problem at such low thread counts then I kind of doubt you can easily extend these algorithms to make effective use of thousands of GPU shader cores instead.
>>
Could any compressionGODS tell me if there's a basic generic "not the best but alright" codec/setting?
For example something I can run all my videos through, all I care is decent looking 1080p.
Also I'm looking into converting all my images, but I think I'd have to separate drawings from real pictures right?
>>
>>108688949
Different anon, yes that is true. VMAF lowers (some times by 10 points in high motion sources with 64 threads vs 1) when comparing single threaded vs multi threaded for x265. It is why streaming services usually split the film up into chunks (ffmpeg), encode each part single threaded, but multiple parts in parallel (GNU parallel or xargs), such that throughput is still high, then finally losslessly recombine the encodes (ffmpeg).
>>
File: 1759642110144495.jpg (909 KB, 1818x1920)
909 KB JPG
>>108689058
OP here, I legit found out about it from other threads. The only thing I know is that it supports AV1 uploads which got my attention because almost nothing out there currently allows you to upload AV1 video. Not sure if it's gonna be the best place for that, website still looks like it's under construction.
>>
>>108689156
This might satisfy that requirement. Regular SVT-AV1 will achieve higher VMAF scores but on a side by side comparison I really prefer the SVT-AV1-PSY output.

https://umigalaxy.com/explore/general/275-i-made-a-video-tutorial-of-how-to-encode-av1
>>
>>108689454
I was looking into it after I posted my message. Turns out I can't encode in AV1 on my 12 gen intel and 3060, I guess the best alternative is H265 right?
>>
>>108688865
I see it similar to Indians infiltrating tech spaces all over the world. Like yeah they'll work for peanuts but the money saved won't look good when the work is shotty. GPUs are the Indians of the computer world IMHO.

>>108689467
H265 is slower to encode. Consider going back to regular SVT-AV1, that should encode at like 60 FPS for 1080p video on a 12th gen i5. The SVT-AV1-PSY encoder is slower on purpose to tune encodes for quality, like more time trying to make the video pleasing to human observers not VMAF.
>>
>went to update a old channel archive i did years back when I realized it was in inferior vp9 blurr mess only to find they made it worse compared to the old vp9 I saved
Is this one of codecs that are to blame on YouTube for downgrading old videos to pixelated dog shit quality?
>>
>>108690208
Nah, I'd say that's more of wrong-tool-for-the-job kind of problem. Like SVT-AV1-PSY exists, costs $0 to use, and you don't have to use SVT-AV1 (or GPU AV1 encodes).
>>
>>108689156
No such thing, every source faces different compression problems desu. x264 crf 20 seems to be the closest thing but it introduces bloat.
>>
>>108684424

that child is eating a solid storage unit.
>>
>>108684424
>encode
I'm decooding doe
>>
>>108688865
Why would a GPU beat a CPU in quality?
The encoder of a GPU is mostly fixed function. Anything a GPU does can be done on a CPU with more flexibility.
>>
>>108695200
well he's asking, isn't he? with no prior knowledge it's not exactly obvious what makes gpus and cpus different

>>108692554
if you could nibble an ssd to gain it's knowledge you would
>>
File: VID-20260409-WA0028.mp4 (250 KB, 200x356)
250 KB MP4
>>108684424
PEDO THREAD
>>
>>108692554
Why are you projecting your fantasy of the ROBOT NON-HUMAN girl sucking dick when nobody in this thread even hinted at this notion? I think it's (You) who can't look at a video of a little girl doing cute little girl things without imagining sexual things who needs a little bit of introspection and professional help.

The fact that you posted AI SLOP makes it worse.
>>
File: 1746159863410984.jpg (37 KB, 600x443)
37 KB JPG
>>108696227
FUCK, meant to quote to >>108696191


>>108692554
Just taking a byte out of it...

Nothing a little chkdsk can't fix.
>>
>>108684424
I probs would, but I have no use case for encoding videos rn.
>>
>>108696984
There is definitely an optimization aspect to explore with AV1. A bloated H264 rip (ie it was hardware encoded) can have like 60-80% of its filsize reduced with only a small reduction in quality.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.