News for hackers. Stuff that matters.

A comment on “Land initial Rust MP4 parser and unit tests”. Parent comment

Re:“Land initial Rust MP4 parser and unit tests” by izietto on Thursday June 18, 2015 @02:26PM (#9740626)
It would be pretty exciting to see an audio or even a video decoder/encoder written in Rust
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by steveklabnik on Thursday June 18, 2015 @02:30PM (#9740652)
Some VLC committers have been experimenting with Rust. Mostly parsing, see https://github.com/geal/nom and http://spw15.langsec.org/papers/couprie-nom.pdf
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by izietto on Thursday June 18, 2015 @02:37PM (#9740701)
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 I have to read the paper, forgot about it
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by sjagoe on Thursday June 18, 2015 @05:21PM (#9741678)
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 (via https://news.ycombinator.com/item?id=9731249)

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by JoshTriplett on Thursday June 18, 2015 @02:51PM (#9740812)
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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by jallmann on Thursday June 18, 2015 @03:43PM (#9741149)
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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by JoshTriplett on Thursday June 18, 2015 @03:59PM (#9741248)
> 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?".

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by jallmann on Thursday June 18, 2015 @04:17PM (#9741367)
> 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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by tracker1 on Friday June 19, 2015 @02:36AM (#9743310)
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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by swah on Thursday June 18, 2015 @04:59PM (#9741584)
FPGAs could change that equation :P
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by ris on Thursday June 18, 2015 @06:14PM (#9741947)
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.
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by pjc50 on Thursday June 18, 2015 @03:49PM (#9741185)
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.
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by jallmann on Thursday June 18, 2015 @04:26PM (#9741420)
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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by ris on Thursday June 18, 2015 @06:12PM (#9741935)
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.
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by kuschku on Thursday June 18, 2015 @03:47PM (#9741176)
Sadly, with the rise of VP8/VP9/webm, this got lost.
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by JoshTriplett on Thursday June 18, 2015 @03:58PM (#9741239)
Those have been implemented in hardware too.
[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by kuschku on Thursday June 18, 2015 @06:23PM (#9741975)
h264 exists in hardware everywhere now. VP8/VP9, not really.

And VP8/VP9 has again the same patent issues as h264.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by TD-Linux on Thursday June 18, 2015 @07:09PM (#9742135)
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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by nitrogen on Thursday June 18, 2015 @10:59PM (#9742784)
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.

[ Parent | on HN ]
Re:“Land initial Rust MP4 parser and unit tests” by kuschku on Sunday June 21, 2015 @03:43AM (#9752588)
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.
[ Parent | on HN ]