720p on 384Kbps? How? Here's how.

One of the marvels of new technology is the increasing efficiency of video codecs. The first video codec I recall was MPEG-1, along with .avi. It's been a long while since I had much of an interest in codecs, although I have on occasion preferred H.265 when available (over H.264), such as when recording with my Vega 56 GPU, which has a hardware based encoder. This helps keeps screen recording files smaller. I also have an SVT-AV1 software-based encoder on my Ryzen CPU.

AV2 and H.266 are being developed, and AV2 is probably going to be released later this year. This will allow more efficient 8k and 4k videos, but there are also improvements in the file sizes for smaller resolutions.

Since I have been testing a slow mobile data plan (with "unlimited" data beyond a 1GB alottment), I have been curious how much "bang" I could get on a budget MVNO plan. The answer might surprise you. A couple weeks ago, I was testing out a 128Kbps plan, which if most of the internet were still in 2000-era web design, might actually be somewhat tolerable. But since most websites need and do use more data, I had to upgrade to another plan that offered a bit more. I am not ready to upgrade to something in the MBps speeds (I have used that on wired plans, however) although I will soon, once I am done testing my Galileo board- I found an ethernet cable, and will get to that in another post. 

My current plan offers me 384Kbps unlimited, and I was curious how much streaming I could do with this, using my phone as a hotspot, since my desktop offered more controls.

First, I wanted to set some parameters for this test. It couldn't be a video that I could download, although that is an easier option since even a 128kbps could play 1080p or even 4k if one waits long enough (assuming the connection doesn't cancel or fail and restarts). Second, it had to be 720p, which is a little harder than streaming 480p (for most videos, that is the limit of what 384kps can handle, and even then, it might be slow on a higher encoded bittrate.

Third, it had to be production quality video, not something recorded on a smartphone (or at least a really cheap camera phone). I have long subscribed to RED camera channel on YT, which has a lot of technical videos on their cameras, along with sample footage from filmmakers. Some of the quality exceeds TV quality, so I thought this might be a good benchmark.

RED also has cameras that shoot in anamorphic, which is an ultra widescreen 2.39:1 format. Most widescreens are in the 16:9 format, and a few of their videos offer that format on Youtube, which apparently the latter now supports too (from the appearance of the maximum resized window showing that).

However, I determined that 2.39:1 on 384Kbps was too much data, so I wasn't going to be able to stream that without significant buffering. It wasn't my first choice anyways, but it was something I stumbled upon when testing a 2nd RED video after getting a smooth result on the first.

So how does it work? Right-clicking the video in a Chrome or Firefox browser will reveal "Stats for Nerds" option. Click that and you'll be able to see all the technical data of the video, including dropped frames, a crucial benchmark for smoothness.

The first thing I noticed is that RED was using AV1, which is great. I selected this in the Youtube settings to default when available. This offers up to 50% efficiency improvement over h.264 and 33% over VP9 (Old news but here's the link). The only problem, is that older computers don't have the decoder in hardware, and seem to use a software decoder to play it back. Fortunately, I was testing this on a 4-core, 8 threaded i7 from 2012. This was released in Q2 of 2012, which was quite a while ago. But it was able to play back AV1 smoothly, and only used 2 of the 8 threads, averaging around 25% of the CPU utilization. On a dual core CPU, especially older ones (and ones that are not dual threaded), that might not be enough to play back 720p video in a Chrome Browser, at least with AV1. 

Also, many smartphones released in the past 3 years include AV1 decoders, which is a plus because many phone resolutions have between 720p and 1080-1440p, although the latter uses more battery power. 128kbps can play back 144-240p and possibly up to 360p, but it depends on the codec.

The last part of this requirement turned up only by accident. I wasn't actively searching for 24p video, but since movies are typically shot in 24fps, they indirectly use less data than say, a 30fps TV show or network broadcast. I wasn't thinking that 30fps would be the straw that broke the camel's back, but in this case, it was. I was able to play this video with extremely minimal buffering without preloading the video (often at least 33% is recommended if it is on a slower connection so that it won't catch up by the end of the video). Chrome used to have browser extensions that would allow smarter prebuffering, but it seems that youtube allows more prebuffering than it used to- where it would pause at just 15 seconds ahead of the video to limit excessive bandwidth usage by users who might not complete the video. For smaller videos, however, this at least seems to have changed.

The video I tested was this: "V-RAPTOR XE REEL" 

A caveat is that the "Viewport/ Frames" indicator is actually the uncropped video that the video uploader sent to Google, whereas the Optimal Resolution is what Youtube crops for the format selected. While the fps can't be toggled (except when deciding between 480p and higher resolutions, which sometimes are encoded at 60fps starting at 720 and up (but only for videos that were recorded uploaded with 60fps), the 720p resolution shows 24fps, and this is actually preferred in this case since it will use less data. The Viewport is also sending more data to the browser than is being used, so the closer the resolution to the actual intended size requested for viewing, the less data that will actually be "wasted" (i.e. not seen, for example, on a 720p monitor that can't view resolutions above 1366x768- although up to 4x downsampling does result in a sharper image, except in this case there isn't the bandwidth for it). 

I will also point out that when AV1 was first released, some websites, maybe youtube included, would only encode the larger 1080p, 4k and 8k videos on it to save encoding resources, while leaving the smaller videos at vp9 or h.264. It's unclear if this changed for newer videos with additional resources/datacenter, but I still see a lot of videos encoded in vp8, even at higher resolutions (it's also a user preference for some). This can also also have the unexpected result of possibly seeing a 480p video encoded at a higher rate (in vp9/h.264) and size than a 720p video encoded in AV1. Higher encoding rate doesn't always equal better quality, although it might preserve some artifacts slightly better, depending on the  equipment, lighting and other filming techniques used.

I could have encoded these in .heic but Microsoft wants me to buy the codec from the Store.

As you can see from these screenshots, there is a bit of a dip in the bandwidth, and it was because I hadn't realized Chrome was updating its browser, which it does quite frequently (often 1-2x a week or more for minor and major security updates).

Another possible caveat is that the cell connection might not always be as strong, causing additional buffering delays. But I haven't had this issue so much as noticing unexpected system or browser updates, which seem to happen a lot more often than the once a week or every two weeks cycle. Fortunately, Firefox allows you to pause or postpone an update by clicking on "Help- About," whereas Chrome goes HAL9000 on preventing any manual override to the automatic updates. The same follows for Edge, which is a Chromium derivative too. As much as I prefer to use a Linux OS in the near future again, sometimes there is a convenience to using Windows (and I'm referring to 10, not 11). So there, this post was a brief analysis on how to get a decent, smooth production quality video playback on a throttled connection, even when:

1. Connected to 384kbps

2. Connected to a wireless hotspot

3. Running a memory-intensive browser such as Chrome or Firefox

4. Playing back HD quality 720p24 video- not 30fps nor 720p/60.

5. (Not  running any system or browser updates, including on any other devices connected to the same hotspot, including the phone itself)

6. Pre-buffering the video when/if necessary, usually at least 33% but less if you're feeling lucky.

7. Not in 2.39:1 format, only 16:9 or less, although still cool if you can, and 2.39:1 runs fine in 480p mode.

8. Also, 24fps is preferrable for historical reasons and TVs can display it properly when motion blur is turned off.