I've always found it funny that the "HBO" branded intro to all their shows is produced of pure visual static. ([1] for anyone unfamiliar.) They literally couldn't have picked something worse to encode for streaming.
I remember noticing as a kid that some channels on cable TV were noticeably worse quality (far more blocky iirc, looked very MPEG artifacty) than the analogue broadcast equivalent and that others looked very different between even cable and satellite tv (iirc More4 was one of the more obvious ones, looked OK on Sky but awful on NTL).
The HBO static intro screen was worst case for compression but gave a pretty good indication of the quality (of the bitrate/compression) of the rest of the show; which worked for broadcast, recordings or downloads. Probably not deliberate, but actually kinda useful.
Every time a movie came up 10 minutes short of the hour or half hour, they padded it with tiny documentaries and previews for other movies.
Maybe it's just an illusion. But I swear I can see the seams where the widescreen pixels start
(Modern video formats are not deterministic in that the same source always encodes to the same output for the same format. They are more like programming languages that they provide as set of tools you can use to compress various different kinds of redundancy out, but it's the job of the encoder to find that redundancy. For example, one of the tools typically available is to provide a source image to an off-screen buffer, and then when rendering the screen, occasionally provide offset/length pairs into that buffer instead of pixels. This could be used for efficiently encoding the duplicated noise.)
I'm also amused when they drop confetti and the screen turns into blocky slush.
Another surprisingly hard to encode scene is water. Wave motion and shimmering is almost impossible to handle efficiently.
Which is not quite as absurd as it sounds. Have a look at the reflections in https://www.youtube.com/watch?v=udPY5rQVoW0
Capturing depth in a satisfying way in a photograph is a skill that can be learned, but often it's impossible. (The skill is really about learning to see the small set of perspectives that do translate meaningfully to a 2D projection.)
My photography teacher told us "If you can't see the same thing (that you see with your eyes) via the viewfinder, don't take that photo". It took me a decade to completely understand what she meant.
One day it clicked at a very mundane moment, but it was pure enlightenment.
(Bonus: the parallax effect can be exploited to convey depth also on a print, actually. A comparatively long exposure time will, depending on light levels, emphasise or de-emphasise motion closer to the camera in motion blur effects, that vary in size and intensity depending on the two things above.)
I'm often watching videos at a resolution larger than my screen can display just to get the extra bitrate.
First, set up the scenario. You're going to binge-watch an HBO Max series that is 10 x 1 hour episodes. Each episode has the HBO static card (7s), a 1m45s intro sequence, and a 2m30s trailing credits sequence where the first 30s is episode-dependent but the last 2m is constant across the series.
This is a best-reasonable-case scenario, since we know that people do sometimes binge-watch a series like this. We can construct unreasonable scenarios which would do better (10 minute loop of an aquarium played for 24 hours) but they would be unreasonable. More often, I think, people tend to watch one movie or one episode of a show and then switch to something else or leave.
The receiving device needs to have 3m51s of storage available for reuse across episodes. That's not unreasonable. At a 4K streaming rate of 10GB per hour (Youtube 4K uses more than this, Netflix uses less) that would be 260MB or so.
That number does sound unreasonable, though. A typical streaming device has between 1 and 4GB of RAM available -- an Amazon FireStick 4K has 2GB, various modern Roku devices have 1 to 2 GB -- and eating a quarter of that speculatively does not make sense to me.
For some reason ffmpeg's H.265 implementation doesn't have a film profile, I wonder why?
It would be nice to have a fantastic implementation of an h.265 encoder like x264, but alas.
Still, it was really interesting that
ffmpeg -i bluray:[filename] -c:v libx264 -crf 22 -tune film -preset slow -nr 500
ffmpeg -i bluray:[filename] -c:v libx265 -crf 25 -preset slow
Noise detection could be useful, if you can get noise that's close enough, it'd be a more than adequate substitute.
It'd also be useful for rain, which video codecs also struggle with.
Another thing is, a lot of modern video was generated, and composited - why not have that reflected in the codec?
You could directly encode the elements as understanded by the process used to generate them, rather than attempting to reconstitute things from a stream of bitmaps.
You might like Gan Theft Auto: https://www.youtube.com/watch?v=udPY5rQVoW0
On the other hand, deep-learning based compression with autoencoders or something similar is pretty promising, since it can learn the constituent elements in a more general way, independent of what program was used to create it.
Update it every decade or so to reflect artefacts of whatever in-house codec they use at the time. The ramp-up would be a creative exercise for the techies working in the studio.