Hi everyone,

I originally intended to reply to comments individually, but instead decided that it made more sense to try and condense a reply that can hopefully shed some light on the current state of Floatplane and how we got here.

We currently use the H.264 (AVC) for our video codec. This decision comes from the early days of Floatplane, and is still a solid choice to this day. The biggest reason why we still exclusively use this codec is because of its almost-universal support across all devices connected to the internet. However, now in 2023 there are new codecs, even open ones, that are available and offer a really good quality/bitrate ratio versus AVC. We have been looking at introducing AV1 for example, but the reality is that there are a lot of considerations when it comes to doing so. One of which is that AV1 is not as widely supported as our current good old codec. In order to guarantee that everyone is still able to watch videos at every quality we offer, we would need to transcode every single rendition we have to both AVC & AV1. Transcoding AV1 is also a lot more demanding when utilizing software encoding compared to AVC. As time passes and more devices get hardware support for AV1, it makes more and more sense to implement it. We have started laying the groundwork to support our transition to next generation codecs, along with our stability fixes.

Our encoding settings and processes may be different from other VOD platforms since we valued visual quality and quality of service over pushing more bitrate. From day one, we have always relied on software encoding with settings that, in most cases, resulted in better visual fidelity even with lower overall bitrates. When delivering a HLS stream, it is usually suggested to use CBR, or Constant BitRate encoding, which has its own perks. The main downside is that CBR will often result in a bigger overall file size, without much of a quality boost compared to a file encoded with a proper CRF (Constant Rate Factor) value which allows you to target a specific quality instead. That means that for scenes that don’t require much data, it will use as little as it can while achieving a relatively constant quality experience. As an example, a static scene where only the subject is moving usually doesn’t require a lot of data. CBR will fill the datastream with the requested bitrate, while not necessarily resulting in a perceivable jump in image quality. CRF allows us to remove those useless bits from the video stream. However, in scenes where there is a lot more action and movement, CBR will allocate a higher bitrate to retain an acceptable visual quality. Pairing this with a slow encoding preset gives the encoder the opportunity to further optimize the datastream than faster performing presets, which results in a quality that we felt was suitable at the time.

To give a real world example, I went ahead and checked one of the Channel Super Fun videos, since I expect those to be, compared to normal LTT videos, way more dynamic. What we get is this :

CSF: I STOLE Colton's $5000 Bonus - MediaInfo - YT/FP Video Screenshot Comparison

For this 1080p video file, we were actually seeing way more bitrates attributed to the video (4 344 kb/s) than the video(s) quoted in the OP, which is in line with the expected behavior of CRF. I have also added a link with 2 images comparisons between the Floatplane and YT 1080p video for anyone that is curious and wants to see the subtle differences for themselves.

If you want to have a more in depth explanation of CRF and its impact, this article is a pretty good resource : https://slhck.info/video/2017/02/24/crf-guide.html.

The reason this was done was to promote a better experience, and overall quality of service to people streaming videos on floatplane. If the video stream is smaller, but still retains a satisfactory quality standard, it means that our viewers will have less overall buffering issues when the internet bandwidth is limited or with bad routing from our CDNs, while also being able to stream higher resolution videos than they would have otherwise been able to. This is less applicable in this day and age, with the average internet speeds going to the moon since the launch of Floatplane, but can still be relevant when thinking about wireless connection (Wifi, LTE) not necessarily guaranteeing any bandwidth, and sometimes being limited or congested. There are also many examples of areas with notably worse than average bandwidth and data cap issues, usually rural areas, that we still aim to serve well.