161–170 of 212 posts
Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author puts it, AV2 decoding is roughly five times more complex than AV1 decoding ?
Go ask FFmpeg what they're writing their encoders and decoders in.
Earlier quoted context omitted.
Go ask FFmpeg what they're writing their encoders and decoders in.
Just don't try reporting a security issue to them.
If so, FFmpeg's stance is very understandable in my opinion.
Earlier quoted context omitted.
Just don't try reporting a security issue to them.
Is this a reference to this: https://news.ycombinator.com/item?id=45785291 ? If so, FFmpeg's stance is very understandable in my opinion.
Media decoders are one of the highest risk programs since they deal with untrusted user input and are incredibly complex. So just because a large project like ffmpeg uses C, doesn't mean there isn't very good reason to consider a language like Rust for saftey reasons.
Earlier quoted context omitted.
I don't know if I'm underestimating HN's reach but I doubt we did that, probably traffic from a much bigger aggregator/forum
The HN hug of death is real. If you aren’t prepared, it can set fire to your server room.
Earlier quoted context omitted.
Are video codecs in the present day able to be sandboxed? In my fantasies at least I’d like the worst a malicious video file can do is cause garbage output or cause the codec to crash. Forgive the ignorance, I have worked entirely in the abstracted layers of the stack, and mostly web.
not really. they're mostly pure assembly and sandboxing assembly isn't really a things
Earlier quoted context omitted.
Is this a reference to this: https://news.ycombinator.com/item?id=45785291 ? If so, FFmpeg's stance is very understandable in my opinion.
Somewhat, but somewhat not. Yes it's a very obscure format, and yes it's partially a marketing stunt from Google for their AI tools. But it's also a real bug which is exploitable on ffmpeg. And we have seen in the past that state sponsored hacking groups specifically target media decoders with obscure formats that aren't often tested or known about. Media decoders are one of the highest risk programs since they deal…
The disadvantage in speed when using Rust is pretty obvious.[1] When it comes to video encoding and decoding, I and FFmpeg care a lot more about speed than memory safety. So those reasons have been considered and largely discounted.
[1] https://xcancel.com/FFmpeg/status/1924137645988356437 (to be fair, this is only transpiled from C, so it could probably be optimised further, but that apparently needed a 20k USD bounty to then not even happen (as far as I can tell))
This is an odd signoff. Are people having a go at dav2d?
Wait until you try d4vid, it's killer.
Earlier quoted context omitted.
If you don't encode locally as the video is created, you either need to store RAW frames which takes enormous amount of storage, or you use a different format and suffer quality loss by transcending.
> you use a different format and suffer quality loss by transcending. Compressing to AV1/h264/265 etc is really only done for the final version, but that doesn't mean that videos are stored in RAW format during editing, where it is very common to store frames locally in Apple ProRes, Avid DNxHD, or some other compressed format that's targeted towards professional editing. Contrary to AV1 or whatever similar format wh…
ProRes and the like are used for proxies or quick and dirty productions that are mostly shooting their look in camera because of a fast turnaround time. This is usually event work on a budget or something for social media.