TD-Linux

Verilator is only a simulator, once you want to run it on a fpga you use yosys + nextpnr. The icestick is a popular and cheap choice to get started, there is also the TinyFPGA BX and iCEBreaker if you would like a few more features.

One cool thing you can do with Verilator is use the API to simulate other hardware. For example, here's a Verilog Gameboy being simulated realtime by simulating the display attached to it: https://twitter.com/zephray_wenting/status/11126917323936645...

The GP shows both avc1 and av01, the latter of which is AV1.

Firefox Nightly switched to dav1d, which for many users is only going to use a fraction of their CPU. https://code.videolan.org/videolan/dav1d/issues/15#note_2345...

It will still be a measurable difference if you are watching hours of video, but for the gif replacement that this site suggests, it's negligible.

ST fixed their STM32Cube licenses so that most of it is BSD licensed, but yeah I also agree that libopencm3 is great. ST has good datasheets that allow anyone to easily create their own HAL or set things up directly if needed. There's also HALs for other language, such as Rust.

The (optional) GPU is a Vivante core, which is great because it's supported by free software drivers and Mesa support. Given the generally good free software support that ST gives, plus the mainline Linux support landing over a year early, this looks like a pretty fun part to play with.

AV1 also uses the brand new media codec sandboxing feature (RDD process). It has platform specific code, hence why only Windows was ready by 65 (but Mac + Linux should be available soon).

The site is actually a bit out of date, the ECP5 bit (Project Trellis) and nextpnr are already working:

https://github.com/YosysHQ/nextpnr

You either write an entire separate asm function, or use macro utilities to ifdef portions of the function. See for example: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcod...

Nitrokey, the manufacturer of the Librem Key, has a U2F key available for preorder.

Already done. Check out a-frame: https://aframe.io/

Bonus points for doing it in Firefox Reality or another VR browser.

Yeah there is, if you go to some of the sites on the home page there's an "enter VR" button, where the site does the equivalent of fullscreen for VR (it enters VR mode and it's much like a VR app).

It's not an Open Source license either, violating criteria 5 and 6 of the definition. https://opensource.org/osd-annotated

The MIT license has no restriction on applying additional restrictions, without the permission of the contributors. For example, MIT licensed software can be used in proprietary software.

The article doesn't say that 1 human = 100GB anywhere. It does say a reference genome is ~1GB, which sounds similar to a zipped FASTA.

500k humans would make this 400TB of data. Really not that much, especially compared to the $500 million dollars it would take to sequence all those humans at $1,000 each.

This article totally failed to justify why compression algorithms are so important for this application. How big is the human genome, how much can we compress it by, and why does this matter?

I took a look and zipped FASTA files are about 800MB. Large, sure, but people are streaming Netflix movies far bigger than this every night.

It's really hard for me to see the MPEG-G effort as anything but a money grab for compression patents and licensing.

I'm disappointed this didn't launch with the i7-8809g as was rumored - having an AMD GPU would be far better for a Linux machine.

Virtually all of the consumed memory is from the reference frames, so it depends on how big your video is. AV1 supports up to 8 reference frames, though if you're memory constrained you could use less.

Different encoders produce different outputs, the algorithm isn't specified.

I actually had a realtime rav1e demo running, with some modifications. There's nothing inherently less realtime about AV1 than, say H.264.

AV1 isn't just for 4K, though. Netflix recently showed a demo of 720p AV1 at only 200kbps. It should massively improve the low end - in fact, maybe the low end first because lower resolution streams are the fastest to encode.

The AI services are accessed through a built in LTE modem. So you can't really filter it even if you wanted to.

None, so a separate FEC can still be useful. You can use FEC like described in the article with WebRTC: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08

fMP4 has an index for each chunk, so you have to buffer the whole thing to create the index on the writing side. However, with DASH you do have the option for WebM as well, which does not need and index and can be streamed. Or really small fMP4 segments work too.

The author of the OP has an article about DAI too: https://prestonbyrne.com/2018/01/11/epicaricacy/

Doesn't seem so hot to me, and what happens when the bot runs out of capital?

It would also play back flawlessly even without the hardware decoder, because H.264 is so fast to decode nowadays. If AV1 is fast enough it can allow people to use AV1 without buying new hardware.

FLIF has much better lossless compression than AV1 but much worse lossy compression.

Actually had to double check this to make sure it wasn't in the sources. It seems the the encoder basically sees the trees as only having a small difference, but really visually it's quite large. The solution is a better distortion function in the encoder - libaom's is simple but dumb. (luckily this means no decoder or format changes)

That's a very good point. I chose Rust more to get ergonomics and more reliable threading - security was not the primary motivation. That said, the encoder is exposed directly to the web via the MediaRecorder API.

The github counter is misleading - it is counting auto-generated C headers used for calling assembly code. The repo also contains a libaom submodule, but the only parts that are used are initialization tables and the transforms.

The feature is called "async DNS" and I believe queries both the system resolver and Google, and takes the first response.

https://superuser.com/questions/656938/does-chrome-use-a-dif...