HN user

dr-ando

19 karma
Posts0
Comments12
View on HN
No posts found.

That's a great list of the H.264 patent claims--thanks. I had naively assumed that since the first iteration of standard was published in 2003 that "obviously" all related patents (to features in the first iteration, anyway) would have to have been filed prior. Clearly, that is not the case.

Funnily enough I recently released 0.1.0 of "less-avc" a pure Rust H.264 (AVC) video encoder: https://github.com/strawlab/less-avc/ . For now it only implements a lossless I PCM encoder but supports a few features I need such as high bit depth. If anyone has a codec-writing itch they want to scratch, I would welcome work towards the compression algorithms H.264 supports: context-adaptive variable-length coding (CAVLC) and context-adaptive binary arithmetic coding (CABAC). Also I'm happy for constructive criticism or questions on this library. I think it is fairly idiomatic, and no `unsafe`, rust. While H.264 is an older codec now, as far as I can tell, this also means any patents on it are about to run out and it is very widely supported.

The computational requirements are very modest. The magic is in the math. I'm not sure if it counts as "batteries included" but I wrote a Kalman filter implementation in "no-std" (no standard library) rust called adskalman [1]. This means it can run on very modest bare metal targets with no operating system. Of course, it can also run on targets where the standard library is available and the examples [2] make use of this to do nice things like print the results which can be piped to a file and plotted. The core runs fine on embedded targets, and we use this with arm microcontrollers, but it should work on just about anything. Feedback is welcome.

[1] https://crates.io/crates/adskalman [2] https://github.com/strawlab/adskalman-rs/blob/main/examples/...

I am sympathetic to the point you make but to be accurate, one can consume and create C and C compatible dynamic libraries with rust. So, one is not “losing” something because what you (and me) want - dynamic linking and shared libraries with a stable and safe rust ABI - was not there to begin with.

The dev kit is just that - a dev kit. For production you could use the jetson nano module but probably want a different carrier board. I think the Nvidia license also prevents production use of the dev kit.

Relatedly, a paper was posted to bioRxiv a few days ago describing the results of large scale fruit fly release-and-recapture experiments. They conclude the abstract with "Our field data do not support a Lévy flight model of dispersal, despite the fact that our experimental conditions almost perfectly match the core assumptions of that theory."

https://www.biorxiv.org/content/10.1101/2020.06.10.145169v1

Also, Viswanathan's 1996 Nature paper was stupendously wrong due to the key measurements being in error, but instead of retracting it, he and colleagues published a followup - in Nature 2007 - in which they say the albatross flight times are gamma distributed.

If is interesting to you, I also suggest to check out my Rust crate bui-backend[0]. This is a library for building Browser User Interface (BUI) backends. The key idea is a datastore which is synced between the backend and the browser. The demo has several example frontends. The most interesting perhaps is the yew[1] framework, which is somewhat like React but in Rust. This lets you share code directly between the backend (natively compiled) and frontend (compiled to wasm). There is also a pure Javascript frontend, an Elm frontend, and a Rust stdweb frontend in the demo.

0 - http://github.com/astraw/bui-backend 1 - https://github.com/DenisKolodin/yew