Why do you think it wouldn't work for a JPEG? I just made one like that, and it worked just fine.

> Why do you think it wouldn't work for a JPEG? I just made one like that, and it worked just fine.

JPGs are lossy encodings; my use-case would definitely not work with JPGs, not matter how high you put the quality.

For testing a display (like displaymate does) you literally want to light up specific pixels with specific colors. You can't do that with JPGs.

You can do that with JPEGs, just not the obvious way (i.e. by exporting the JPEG at the target resolution.)

Instead, you need to export the JPEG at a resampled resolution that's a multiple of your target resolution, such that each pre-transform source-image pixel gets mapped to its own entirely-independent JPEG color block.

Most obvious (though perhaps not optimal?) approach: nearest-neighbour upscale your image by 8x, and then save as JPEG with 100% quality (which will create 8x8 blocks with 4:4:4 subsampling.)

> You can do that with JPEGs, just not the obvious way (i.e. by exporting the JPEG at the target resolution.)

Yeah, I don't think GP did it that way.

Did you actually test? I did it and it worked fine (and zooming in confirmed that the RGB bars are nicely preserved). Be sure to put your subsampling at 4:4:4.

Just remove the A record, and nearly all the scrapers disappear. :-) (And then you get one email per month or so that “your host does not resolve in DNS”.)

> And while they've recently announced more of this stuff will move to FOSS soon, at the same time their response rate to new bug reports has become worse than ever before, which is deeply worrying.

A huge chunk[1] of the MySQL developers were laid off (and also large amounts of QA etc.), so it's not surpising at all that they are struggling to keep the lights on. There are talks about an external group trying to form to take more ownership, but so far, your best bets are MariaDB or Postgres, depending on whether you think MySQL 5.1 was the epitome of relational databases or not.

[1] From what I gather, about 75%. In the first wave.

MySQL has never been downstream of MariaDB.

I am talking pre mariadb times.

Are you maybe confusing “downstream” with “mainstream”? Being “downstream” of a product means that you are a derivative of that product (your upstream), taking in basically all of their code and adding your own on top.

So the meaning of downstream is different for SuperSQL (the direct derivative) and TodoApp (the commercial product)?

Imho, downstream are all consumers/users of that product. I guess it's arguable how a package manager positions in that terminology.

Edit: Also I originally said, "it was the thing used downstream", which just is to describe the consumers. Also not sure what I got into, because the original question is wildly confusing!

They are using a fork, although nobody _really_ knows how up-to-date it is.

It's the one that nags you to upload all your IMAP passwords and email to Microsoft's cloud.

FFmpeg has its own native H.264, HEVC, MP3, Speex and AAC decoders. It's true that they don't have an H.264 or HEVC _encoder_ without calling out to external libraries, but they have a pretty good AAC encoder now, and TBH most use of FFmpeg is for decoding, not encoding.

> most use of FFmpeg is for decoding, not encoding.

Isn't that merely an observation of how lopsided media consumption vs production is on average?

> due to FFmpeg back then lacking any framework for code sharing between components and codecs

Funny, I remember this being completely different; FFmpeg bundled ffserver, which transcoded to a bunch of codecs at the same time (sharing motion search and everything) precisely to demonstrate how similar the codecs were and how much could be shared. (Of course, that could easily be spaghetti, but not spaghetti for non-code-sharing reasons.) All on the 400MHz-class machines we had at the time. Do I remember wrong? I haven't looked at these old releases in forever.

The idea of having two arguments to fread() is presumably to be able to do something else than all-or-nothing when there's a short read.

Yes, it divides the bytes read by the element size to get the return value.

Which is the obvious reason you'd pass an element size of 1: you want to know how many bytes were read.

> ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines.

FFmpeg doesn't do “pipelines”. It's a library, not a framework.

It's also a command line tool, where you can design (limited) media graphs: sources, sinks, filters, encoders, decoders, muxers, demuxers. You don't express it as directly as gst-launch's pipeline syntax, but it's very much a pipeline.