4 ms·

Amazing the future is now! How does it perform?

jffry 11y ago
Sounds like it's still a work in progress: This isn't functional yet, but I'd like to get the code in tree as a base to build upon.
- comex 11y ago
  Indeed, the amount of parsing code that was actually imported here is tiny: https://bug1175322.bugzilla.mozilla.org/attachment.cgi?id=8623336 https://bug1175322.bugzilla.mozilla.org/attachment.cgi?id=86...
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
  - 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)
izietto 11y ago
It seems to be the very beginning of the project, I guess that talking about benchmarks is premature
- alexnewman 11y ago
  Sorry, I was mostly joking

jffry 11y ago

Sounds like it's still a work in progress: This isn't functional yet, but I'd like to get the code in tree as a base to build upon.

comex 11y ago
Indeed, the amount of parsing code that was actually imported here is tiny: https://bug1175322.bugzilla.mozilla.org/attachment.cgi?id=8623336 https://bug1175322.bugzilla.mozilla.org/attachment.cgi?id=86...

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

izietto 11y ago

It seems to be the very beginning of the project, I guess that talking about benchmarks is premature

alexnewman 11y ago
Sorry, I was mostly joking