161–170 of 190 posts
Earlier quoted context omitted.
Hopefully their patents will be busted and preferably Dolby will be also forced to pay damages for filing invalid lawsuits. That's the only way to teach patent trolls proper lessons.
How is Dolby a patent troll? :D
Earlier quoted context omitted.
> One of the interesting usage of AV1 was specifically for low bitrate calls, and software encoding was perfectly fine, even on mobile. You really want hardware decoding on mobile, otherwise you end up with 40 minutes battery life. Fortunately, for typical videoconference resolutions, VP8 and H.264 are just fine. AV1 is nice to have, though, due to excellent support for synthetic content (screen sharing), and for sca…
No, you do NOT want hardware anything on mobile if you are targeting smaller bitrate that are not that taxing on the CPU, when the conditions are otherwise so bad that the call would either drop or be unusable. HW encoders produce bad results at low bitrate. HW decoders usually have issues with the temporal encodings used and they may also just not accept those streams (a lot of test scenarios are movies, and the RTC…
Is that poor implementation or is it inherently harder to implement in hw encoders?
Earlier quoted context omitted.
No, you do NOT want hardware anything on mobile if you are targeting smaller bitrate that are not that taxing on the CPU, when the conditions are otherwise so bad that the call would either drop or be unusable. HW encoders produce bad results at low bitrate. HW decoders usually have issues with the temporal encodings used and they may also just not accept those streams (a lot of test scenarios are movies, and the RTC…
> HW encoders produce bad results at low bitrate. Is that poor implementation or is it inherently harder to implement in hw encoders?
What does limit them, though, is pseudo real time single pass pipelines.
I see the best encoding results from two pass - one fast run to work out the easy compress and hard compress parts of a video and then a second pass to get the optimal results on a stream that's already got a budget in mind for each section through the advantage of foresight as to what's left to do.
Dav2d doesn't have the same nice ring to it. I hope there's someone with a decent repo-name punning skill who'll contribute before that. avi2ude? av2go?
It was difficult to find a nice name, with av2 :( It works in French d2vid (Deuvid)
Slightly worse in English, av2age mav2ick
Earlier quoted context omitted.
AVIF is for sure my favorite image format right now. No other format has the quadfecta of lossless, HDR, transparency, browser support. Plus as you said, for very compressed images it looks amazing. It blows my mind how small AVIF files can be. Also, unlike HEIC and Ultra HDR JPEG, it actually supports HDR natively as part of the file format rather than doing the hacky sidecar gain map trick. I know it doesn't matter…
I really don't. 1. Lossless AVIF is a joke often beaten by WebP and even PNG. Even worse for grayscale. 2. Chroma subsampling remains a bad idea for still images unless the resolution is high enough to hide the artifacts. 3. Tooling is the worst part, AV1 encoders are basically focused 99% on video and leave a measly 1% to image; unlike JXL, of course. SVT-AV1 still doesn't do YUV444 and libaom was unusable. Fortunat…
Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts. Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression. That said, if you don't like it, AVIF supports 4:4:4 just fine.
In my tests, AVIF beats PNG easily for lossless compression of actual photographs (for things like charts and screenshots, PNG wins of course). And for lossy, it's much smaller than jpeg and supports HDR unlike WebP. So if you need HDR and are doing lossy compression on the web, it's your best option as far as I know.
Earlier quoted context omitted.
Why patents is a problem, please explain. If you build something that has been patented, then, well, you pay the per piece fee on it.
> In the 1980s, when IBM accused Sun of violating seven patents, Sun examined the patents and argued that IBM didn't have a case. The reply of IBM's lawyers was "maybe you don't infringe these seven patents. But we have 10,000 U.S. patents. Do you really want us to go back to Armonk [IBM headquarters in New York] and find seven patents you do infringe? Or do you want to make this easy and just pay us $20 million?" An…
Earlier quoted context omitted.
Everything here is really niche, except video calls (and even that...). In other words, unless on smart phones, don't expect broadly distributed AV2 encoding hardware. If it does happen on PC, it will be most likely some courtesy of the hardware chip designers.
Screen recording is not niche, anyone who works remotely probably does video calls daily and the others are somewhat more niche but I'd guess that at least 50-70% of people do at least one of these things
(As a side project, I am writting my walyand compositor, and I know that if it supports screen recording, that's going to be something certainly hacky and I can disable at compile time).
Earlier quoted context omitted.
Everything here is really niche, except video calls (and even that...). In other words, unless on smart phones, don't expect broadly distributed AV2 encoding hardware. If it does happen on PC, it will be most likely some courtesy of the hardware chip designers.
Video calls are niche, and offline encoding of video isn't ? Are you sure this isn't just “things I do are commonplace, and things I don't are incredibly niche”?
Video calls is just a feature expected on smart phones, and it means there we better have an hardware encoder.
I don't know if AV2 is defining them, but it needs hard "profiles", that to give a scope for hardware implementations.
Well, it all depends on how AV2 is designed, and defining those profiles is very probably a feedback loop between the AV2 designers and hardware implementors.
Earlier quoted context omitted.
Do you think advanced users should consider AVIF/AVIF2 along JPEGXL for long term pictures archival ? Which kind of encode settings do you suggest for conversion from high resolution RAWs or JPEGs ?
For long term archival, JXL is better, the only issue with it is browser and device support
Earlier quoted context omitted.
Video calls are niche, and offline encoding of video isn't ? Are you sure this isn't just “things I do are commonplace, and things I don't are incredibly niche”?
What? All are niche, and video calls are at best quite rare. People still prefer audio calls or even text messages mostly. Video calls is just a feature expected on smart phones, and it means there we better have an hardware encoder. I don't know if AV2 is defining them, but it needs hard "profiles", that to give a scope for hardware implementations. Well, it all depends on how AV2 is designed, and defining those pro…