I imagine that using rust for this is going to mainly provide security benefits. Parsing the MP4 file isn't very CPU intensive; it's a straightforward binary format. (Decoding the video stream is what is CPU intensive, and this code doesn't do that.)
Perhaps, but software codecs aren't nearly as interesting as hardware codecs. Efficient high-resolution video decoding uses dedicated hardware these days.
It'd be interesting to see portions of libva rewritten using Rust, though.
The only reason to implement a codec in hardware is speed or power consumption. Software codecs are much more flexible with the parameters you can tweak, and more tolerant of variances in the input such as buffer under/overflows, etc.
In that respect, software codecs are much more interesting, but hardware does allow you to get cutting-edge compression to market more quickly.
> The only reason to implement a codec in hardware is speed or power consumption.
Which are two of the most critical properties of a codec. When people look at the battery life of a new platform, one of the common questions is "how many hours of continuous video playback?". Or "how many hours of screen-off audio playback?".
> Which are two of the most critical properties of a codec.
If your target is mobile or embedded, yes. Fortunately, that's not the only use case. Software codecs are a lot more interesting from the standpoint of not being fixed function.
I have to agree... for example, when looking at a micro HTPC replacement for a full on desktop cpu/board, I tried several... none of which could handle 1080p video well without proprietary drivers, often that didn't work in the OS/kernel the image I happened to be trying used.... my last attempt was a quad-core cubox i4-pro, which actually didn't do too bad in software, but would overheat and lockup in use.
In the end I'm using a core i3-5010U based box, that runs well enough... but would really love to see something almost as powerful, but lower power use and better supported. On the one hand, I want a stable flexible system... on the other I want to have the ability to tinker.
It seems a lot of times vendor interests are at odds with a tinkering consumer.
On the same note, been thinking that something akin to Kodi/XBMC that has a control interface that's web based and works on mobile devices, combined with an output interface that can render to something like a google chromecast would be awesome. It could run on a desktop, in another room, and simply display on the TV, or multiple TVs for that matter.
Looking at some of the streaming gaming options from nVidia and Steam, I'm hoping to see this become a home media option that actually works nicely in the future.
Unlikely. They haven't so far in the last 20 years they've been around. And the (painful) processing time required for "place & route" massively limits the degree to which their dynamic nature can be exploited.
Interesting set of priorities there. Hardware codecs are much slower to market than software due to fixed costs, speed is completely critical in decoding codec performance, and lots of people care about power.
Software implementations of a new codec are generally available earlier, but the first implementations shipping to consumers (in STBs, phones, etc) are all going to be in hardware, because the computational cost of a new codec is typically high enough to justify that lead time. That hardware will be limited to a specific set of of run-time levels and profiles, VBV sizes, etc.
Of course hardware implementations have their benefits. But the knobs that software codecs offer are much more interesting.
Keep in mind that the vast majority of "hardware codecs" are actually tiny embedded DSPs running software (well, firmware) that nobody generally gets to see.
The vast majority of phones shipping today include VP8 in hardware. VP9 is a bit rarer at the moment.
While it's up to you and your lawyer to decide whether you can ship a codec, many companies feel perfectly comfortable shipping VP8 and VP9, including Mozilla, Google, Samsung, most SoC vendors, etc.
Wrong. Using VP8/VP9 means you have to accept the Google license, which says it is void as soon as you claim software patents are invalid or sue in court against any of Google’s claims.
