TD-Linux

Every Intel laptop with integrated graphics has been unified memory, all the way back to ye olde 915 in 2004 at least.

Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.

Hardware support does not matter for TS, as containers are handled in software.

Fast start is irrelevant because MoQ normally uses fragmented MP4, not progressive.

HLS also supports fMP4 now and no one is making new services that use TS (there are some old ones still around with too much friction to switch)

Funnily enough, KDE got this feature yesterday: https://invent.kde.org/plasma/kwin/-/merge_requests/8602

While I think you are oversimplifying the timing issue, you are not the first to think that about 2110.

https://stop2110.org/

If you want OpenWRT you don't want this, you want one of the Mediatek based routers (GL-MT*).

Specifically, it needs an age rating set or it can't be viewed in Europe without an account.

Which is completely wrong by the way, JPEG-XL quantizes its coefficients after the DCT transform like every other lossy codec. Most codecs have at least some amount of range expansion in their DCT as well, so the values quantized might be greater bit depth than the input data.

I do not understand the connection between the patent concerns in the article and open-source 3D printing. In particular, the patent issues seem to be the case for all non-Chinese 3D printer companies, whether open source or not. I am not sure how sharing your designs makes this worse (I suppose with the original drawings it's a bit easier to write a patent in bad faith - but certainly not necessary). Something like a defensive patent grant might make a lot of sense (see Opus, AV1 etc) but that's also independent of whether the implementation is open source or not.

The AR coefficients described in the paper are what allow basic modeling of the scale of the noise.

In this case, L = 0 corresponds to the case of modeling Gaussian noise whereas higher values of L may correspond to film grain with larger size of grains.

Almost none of the games pictured are actually "doujin" games - they are commercial publishers.

Also, the reason we don't remember PC-98 is because it was never sold in the US (except for the very unpopular APC-III). It was the most popular computer on Japan from late 80s to early 90s and is well remembered there. Being the most popular PC, there is a huge amount of software for it, including huge amounts of office and productivity software, many genres of games, and plenty of Western ports.

You don't need to store two whole independent images. The high quality image can predict from the low quality image, and the low quality image can be a lower resolution, too. It is less efficient than storing one image, but more efficient than storing two independent images.

Digital video tape formats (e.g. DV, HDV) are an example. Other containers that operate in this mode are TS and Ogg (and optionally, MKV). Any sort of live streaming format generally is, too.

Other reviews also voiced the same complaints. Here's one from November of last year that mentions things like the obnoxious animations: https://electrek.co/2023/11/21/fisker-ocean-review-coming-so...

I think the input lag on the accelerator pedal is what kills it for me, though.

All electric cars already do this, either with resistive heaters directly on the batteries or with water heaters in the coolant loop.

Those were all SPI-alike, or at least run in their SPI mode, including the ones linked. (I also used a Nokia 6100 LCD back in the day, and it was SPI, though with a wider interface option).

This is not a "mirrorless camera sensor", at least how it's meant to be interpreted. While technically mirrorless like all webcams, the sensor is under a quarter of the area of the smallest Sony mirrorless intechangeable-lens cameras.

No video is being transcoded in the parent's command (-vn).

Interestingly, the smooth bokeh has become a bit popular and is available with Canon "defocus smoothing" lenses (among other older examples). Rather than varying the aperture size over time, these just have a ND filter with the aperture window function coated on (and also a normal iris - the effect works best at the largest aperture setting).

Cortex-M4/M33 are pretty widely deployed on microcontrollers with control hardware, for example the STM32G4 and Reneasas RA series.

There's still a few reasons not to use it, though. Saving and restoring the float registers adds interrupt handling overhead. If you can fit into 16 bit integers, you can also use the 2 way SIMD instructions and get at least double the throughput.

Finally, floats themselves have a lot of footguns. You have to be very careful about propagating NaNs etc into control loops. It's also really easy (in C) to accidentally promote to double.

The size of most electric motors is proportional to the torque they produce - so if you can spin it faster, you can get more power for the same weight. There are some other factors that make high speed worse - for example, bearing and core losses. The PCB motor is a coreless motor though, so it has no core loss, biasing it even harder towards high speed operation.

Propellers generally get less efficient with higher speeds though, which might be a bigger factor than any of this.

Except they compromised on the very issue of media formats. They are making an unnecessary fight between two royalty-free formats, yet compromised and are hosting videos in royalty-bearing formats in their website. https://www.fsf.org/blogs/community/the-fsfs-approach-to-usi...

Waveform Lighting bulbs have a great CRI and no camera visible flicker, but even they are overdriven/undercooled. I've already had one fail because of the PFC chip (I did an autopsy). They also don't have enough bulk capacitance to not flicker when other nasty loads are on the line.

I did find these tables from Budget Light Forums handy for shopping, however the fact that you have to use these I think only reinforces the point of the article:

https://docs.google.com/spreadsheets/d/12jj1A6PNjHmWbFNu0FSi...

https://optimizeyourbiology.com/light-bulb-database

A progressive image format doesn't really fully solve the problem, it's only a potential bandwidth improvement. In both the case of a progressive and non-progressive image, you potentially prefetch the wrong asset - either a too low resolution image, or too few bytes of the progressive image, and you are stuck either waiting or displaying a too low resolution version of the image. The only advantage of the progressive format is that the prefetch bytes aren't wasted - as a rough estimate, if you grabbed the 1x image instead of 2x, you ended up using 125% as much bandwidth as intended. A nice improvement but also much smaller than just using a better image format in general. Likewise, it doesn't remove the need for container queries, you'd still at least want a byte offset for the complete base layer.

The subset of AV1 supported by hardware is much narrower than what is in practice used in AVIF images

The majority of AVIF images are hardware decodeable, even if most viewers don't bother with it. The biggest limitation is that profile 0 decoders are 4:2:0 only, but that describes the majority of Web images.

The biggest thing for me is the meson build system. newlib uses autoconf-generated files checked into the build tree, with several different versions of autoconf used depending on directory. So you have to keep several versions of autoconf around if you want to add e.g. another source file without churning the generated files.

The red content is intended to be supplied by a separate red LED. A red LED produces red much more efficiently than the phosphor on a white LED, so it saves power to leave red out entirely if you know it will be paired with red.

The loss of a higher buck ratio is not insignificant. It requires higher voltage rated mosfets which generally have worse performance, as well as increased switching losses resulting in more heat where you least want it. Most other use cases for 24/48V involve significantly longer wires than in a PC case. I think the actual net win, if any, would be quite small.

Comment 19 is 7 years old and doesn't reflect the contents of the patch that actually closed the bug, which enables HEVC both on Android and desktop when provided by the OS (but does not ship a software decoder itself).