TD-Linux

A better source is the original posting:

https://groups.google.com/forum/#!topic/mozilla.dev.platform...

Not even in Nightly yet.

>only god knows what Google is sending itself from Chrome!

Chrome always uses Google DNS, which means that they already collect all the data that Mozilla could potentially collect from the DoH test.

Timestamps in the block header. These timestamps are used to regulate the proof of work to maintain a block interval, so in the end both measures have the same time accuracy.

There is a lot of previous art on this sort of thing, like the ffmpeg spp filter: https://ffmpeg.org/ffmpeg-filters.html#spp-1

It's unclear to me if this method will perform better than those methods.

Previous (flagged) discussion: https://news.ycombinator.com/item?id=16576516

This isn't the most unreasonable list I've seen, but beware you will break many websites with this, so you need to be prepared to deal with the fallout. Notably, a lot of the breakage is hidden in user.js, including:

* No WebGL or WebRTC

* Aggressive TLS settings (will break many websites)

* Mixed-content upgrading (Nightly ran an experiment on this recently and it also broke a lot of websites)

* No history

The text warns about this, but it should at least be clear why Mozilla doesn't ship this as default.

What is there even to discuss? The disclosures and email tell me everything I wanted to know.

Functions you don't call get stripped out of the final binary. The advantage is you get a bunch of high level functions like analogRead() that do all the setup for you. avr-gcc/avr-libc mostly just provides register definitions, so it's likely you're going to duplicate most of the code inside analogRead() anyway if you roll it yourself.

That said, I've done plenty of projects with bare avr-gcc (especially for chips not supported by Arduino at the time) and it's not terribly onerous, but often you don't need that level of control for every little thing.

Real products absolutely do use Arduino libraries, it's not a toy. They are just embedding the AVR directly for cost (and using an external programmer), but there's no reason the Arduino libraries don't work for products that ship. Arduino only eats two pins for serial - I suppose you could drop that if you wanted, but in practice most commercial products have a debug serial port anyway.

Both are built and run by Mozilla. (Pocket started out as a separate company, but then the whole company was bought by Mozilla). That said, Send is the right thing to use here, not Pocket.

I'm going to be that person - why a non-OSI approved license? Given that it's CUDA-specific, I'd expect NVIDIA to want people to use it.

Strangely, the Antminer comes in a metal case with holes smaller than that. Maybe it wasn't grounded or something? Or it was radiated through the external power supply wires?

EDIT: mixed them up, Spoondoolies ones had a nice mesh but the Antminer ones don't behind the fans. That 1" of plastic must be enough to let a significant amount through (or the power supply wires still)

While HEVC fees are only a tiny fraction of their encoders, they are far greater than 20 cents. Adding two of the pools together already nets up to $1.40, and there are more pools with unannounced pricing yet. https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

ffmpeg just ignores patent licensing - you're responsible for paying the appropriate licensing fees if you use it. The same applies to x264 and x265. Generally the pools won't go after ffmpeg itself but rather companies shipping it once they get big enough / have money. For example: https://github.com/mbebenita/Broadway/issues/124

HEVC is currently literally impossible to license. One of the pools hasn't decided on pricing yet. You basically have to set aside some cash and hope it's enough to back-pay once they announce the pricing. But even with the existing ones, you have to pay for encoders, decoders, and videos encoded in it. https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

Unfortunately that's not where the licensing ends - HEVC pools also charge for content distribution. Hence why you see companies like Netflix in AOM, despite them not having to pay fees for the hardware itself. https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

Keep in mind, though, that the constraints for Bitcoin mining are a lot different. The Bitmain chips are far smaller than the NVIDIA ones to increase yield, so the absolute chip counts will be higher but NVIDIA is probably still ahead in terms of area shipped (latency is totally unimportant so no reason to have gigantic chips).

If you end up being limited, there is a very similar trick you can do with audio, but even simpler. Unlike video, most audio formats don't have keyframes, but rather will converge to a correct decode a few packets after you start fresh or seek. So the solution to encode in parallel is to split the file into a bunch of chunks that overlap by a few packets (in the case of Opus, 80ms worth, or 4 packets, should be enough). You then encode all of these chunks, and then merge them together, throwing away the extra packets in the overlap. Unlike video, no final encode pass is needed.

Many encoders have a "two pass" mode that saves statistics from a first, fast pass to guide the second pass. Usually these are very simple statistics, used to choose a quantizer and frame type in the second pass. Your method feels like a rather extreme version of this, that can guide the whole RDO search with a very large state. And, of course, rarely are first passes done in parallel. It's super exciting to see people looking at this - I think there's a lot of untapped potential. The WebRTC case looks interesting too, though there you need extremely low latencies (1 frame) so I'm curious to find out how you tackle that.

One downside with your approach is that you have to code many keyframes that are eventually thrown away. Keyframes are often expensive to encode because their bitrate is so much higher. Have you considered "synthesizing" fake keyframes somehow, such as doing an especially fast and stupid encode for them? Also, artifacts from keyframes tend to be a lot different from inter predicted frames, so would encoding a keyframe, plus a second frame, then throwing away both yield a quality improvement at the final pass (at the cost of more wasted computation)?

Audio encodes far faster than video, so there isn't really a need to parallelize it. You'd probably combine this with Opus in WebRTC.

This is really cool. They use VP8, which means that any web browser (except Safari) can decode the video, even over low-latency WebRTC. It also shows a lot of the limitations of VP8/VP9 encode slowness is due to libvpx, not the underlying format. It'll be interesting to see what they can achieve with VP9 or AV1.

Compiling wasm also enforces security rules. Offloading that would require full trust of the server, which is probably not desirable.

Now 4 different entities with the addition of Velos Media, which hasn't even announced pricing.

That is a real risk - however, this time around people are already working on their own fast implementations (both software and hardware versions), so a lot of the dumb mistakes will already be avoided. There is also the risk of a lot of features being too slow to use at all in a fast encoder, but that's not a risk exclusive to AV1. HM (the reference H.265 encoder) was far too slow to be practical, and given the current speeds of H.265 encoders compared to H.264 at their best quality settings, it's not clear that they totally succeeded.

At least for HEIC, it's not really exposed to the Web - pictures are silently transcoded to JPEG when uploading. Apple could swap out HEIC for AV1 behind the scenes whenever they want, or alternately sliently transcode HEIC to AV1.

>Nothing prevents a sharding as long as you have some way to prioritize in case of conflicts

That's a pretty big leap - that's one of the biggest problems that Satoshi solved in the original white paper.

If you're alluding to setting the delay to infinitely large, you can do that by going to Settings -> Privacy -> Tracking Protection and setting it to "always".

Yeah that's what I meant, I updated my comment to be clearer.

The prediction gain of audio codecs is <1, which basically means that if you start at a random packet, once you play enough packets it'll converge to sound the same as if you had started playing from the beginning. It'll sound bad at the beginning though, so you usually crop off the first bit after seeking (80ms for Opus, much longer for other codecs).

Another source of delay is just the length of audio packets themselves (have to wait for the beginning of one) and radio limitations.

It also says that the clients transmit private keys and PINs to the SGX nodes, which presumably allow spending of their coins. Maybe it's designed in a way that they lose their money, but maintain the privacy of their previous and other transactions going through the node.

The described system is basically identical to Bitcoin's pruned mode. It's lot better than geth's fast sync, which trusts your peers to not have messed with the state.