5 ms·

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 f

by jewel 11y ago

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

izietto 11y ago
It would be pretty exciting to see an audio or even a video decoder/encoder written in Rust
- steveklabnik 11y ago
  Some VLC committers have been experimenting with Rust. Mostly parsing, see https://github.com/geal/nom https://github.com/geal/nom and http://spw15.langsec.org/papers/couprie-nom.pdf http://spw15.langsec.org/papers/couprie-nom.pdf
  - izietto 11y ago
    Oh yes I remember about it, it was published on HN some time ago (by you I see :-) ): https://news.ycombinator.com/item?id=9602055 https://news.ycombinator.com/item?id=9602055 I have to read the paper, forgot about it
- JoshTriplett 11y ago
  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.
  - ris 11y ago
    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.
  - jallmann 11y ago
    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.
    - pjc50 11y ago
      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.
      - jallmann 11y ago
        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.
    - JoshTriplett 11y ago
      > 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?".
      - jallmann 11y ago
        > 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.
  - kuschku 11y ago
    Sadly, with the rise of VP8/VP9/webm, this got lost.
    - JoshTriplett 11y ago
      Those have been implemented in hardware too.
      - kuschku 11y ago
        h264 exists in hardware everywhere now. VP8/VP9, not really. And VP8/VP9 has again the same patent issues as h264.
        TD-Linux 11y ago
        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.
        nitrogen 11y ago
        And VP8/VP9 has again the same patent issues as h264. No, not the same patent issues. Google obtained a blanket global license for VP8 and VP9 from MPEGLA.
        kuschku 11y ago
        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.
- sjagoe 11y ago
  I came across a FLAC decoder on HN yesterday [0]. It's pretty new and I haven't looked at it in any depth. [0] https://github.com/ruud-v-a/claxon https://github.com/ruud-v-a/claxon (via https://news.ycombinator.com/item?id=9731249 https://news.ycombinator.com/item?id=9731249)

by jewel 11y ago

izietto 11y ago

It would be pretty exciting to see an audio or even a video decoder/encoder written in Rust

steveklabnik 11y ago
Some VLC committers have been experimenting with Rust. Mostly parsing, see https://github.com/geal/nom https://github.com/geal/nom and http://spw15.langsec.org/papers/couprie-nom.pdf http://spw15.langsec.org/papers/couprie-nom.pdf
- izietto 11y ago
  Oh yes I remember about it, it was published on HN some time ago (by you I see :-) ): https://news.ycombinator.com/item?id=9602055 https://news.ycombinator.com/item?id=9602055 I have to read the paper, forgot about it
JoshTriplett 11y ago
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.
- ris 11y ago
  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.
- jallmann 11y ago
  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.
  - pjc50 11y ago
    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.
    - jallmann 11y ago
      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.
  - JoshTriplett 11y ago
    > 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?".
    - jallmann 11y ago
      > 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.
- kuschku 11y ago
  Sadly, with the rise of VP8/VP9/webm, this got lost.
  - JoshTriplett 11y ago
    Those have been implemented in hardware too.
    - kuschku 11y ago
      h264 exists in hardware everywhere now. VP8/VP9, not really. And VP8/VP9 has again the same patent issues as h264.
      - TD-Linux 11y ago
        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.
      - nitrogen 11y ago
        And VP8/VP9 has again the same patent issues as h264. No, not the same patent issues. Google obtained a blanket global license for VP8 and VP9 from MPEGLA.
        kuschku 11y ago
        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.
sjagoe 11y ago
I came across a FLAC decoder on HN yesterday [0]. It's pretty new and I haven't looked at it in any depth. [0] https://github.com/ruud-v-a/claxon https://github.com/ruud-v-a/claxon (via https://news.ycombinator.com/item?id=9731249 https://news.ycombinator.com/item?id=9731249)