I was aware of an issue where, ever since i moved my blog object storage backend to Backblaze B2 from AWS S3, my videos started failing to play at all on my website. That's obviously a serious problem, but I hadn't gotten around to looking into this since I haven't been making videos an important part of the site, but since video encoding settings tweaking (realistically this boils down to ffmpeg parameter tweaking) is something I want to get into later and innovate with in my blog as a long term aspiration, I was going to need to look into this eventually. I also think it's likely I will have some articles later that will be pretty heavy on embedded screen share clips.

Today the progress I made on this issue was pretty decent. I gave the header responses that the browser was receiving from the video file requests to GPT-5.1, and it suggested that my issues will go away if I encode my video files "Web Optimized". I did just this (I've known about this being an important setting to use when encoding videos in the past!) and it seems to fully address the problem! There are also a list of little changes that may benefit me later and allow my several other of my older video files I made to maybe also start to work in the browser again if I point Cloudflare at the S3 compatible Backblaze B2 URL instead. But I will save that change for attempting later now that I have a good solution so I can immediately start putting screen capture videos in my blog pages again and have them stream properly.

This also led me to a slight rabbit hole in which I learned a good bit more about ffmpeg parameters and what the x264 encoding presets mean and so on.

In terms of planning for the future, I will introduce initially a simple approach to video file hosting to better support high quality high resolution videos.

With 4K resolution I will want to use both H.265 and AV1 (and possibly even more) formats just from a practical perspective, but it does mean (and especially for AV1) many clients will be unable to efficiently consume some of these formats.

My plan for this at least to start is to use some simple automation that detects if my input video is over some predetermined threshold (perhaps that can just be whether the source resolution is greater than 1800p vertical), and if so to cause both x265 and AV1 CPU encoding to be performed for those videos.

Then, instead of my current use of video tags just use a slightly more fleshed out one that gives multiple alternative video files as options so a client's browser should be able to pick one that they can actually play. Then I will be able to avoid using a dynamic resolution video player on my site. There's nothing wrong with such players and it can certainly be argued that it's important to be able to adequately service users with poor connections, but I already plan to manually crunch my videos (always CPU encoding them all) to be very small. I think that particular thing can be punted for a while for now.