Over the years, some of Google’s improvements to Android have come under project code names. One of these is Project Butter, which was introduced with Android 4.1 Jelly Bean along with the original generation Nexus 7 in the summer of 2012. Project Butter was designed to improve the visible performance of the user interface and it certainly helps matters. Now, over three years after the original Project Butter, Google are working on a new Project Butter. However, unlike the original 2012 Project, the 2015 version of this software tweak to keep things running as smoothly as possible is in conjunction with the YouTube and Google Chrome browser teams.
The YouTube Engineering and Developers Blog explains that video quality is important to viewers and in particular, poorly timed or dropped frames are very obvious to the human eye. The reason for this is because the brain interprets what we see by filling in the motion between frames, something called “motion interpolation.” Although the subject is complicated, one of the basic rules is that if the timing is out between each frame, the video does not appear smooth. The YouTube blog goes on to explain about frame rates, display refresh rates and cadence. The frame rate is the number of frames per second that the YouTube clip is stored, ranging from 24 fps through 25, 29.97, 30, 48, 50, 59.94 and up to 60fps. Display refresh rates are typically 50 HZ and 60 HZ for Europe and the United States of America respectively. Cadence is the ratio of frames in the video clip to the refresh rate. The YouTube engineers played a number of videos back on different devices to score their smoothness via a HDMI capture rig. A video clip playing at 30 fps, played on Chrome 43 on a 60 Hz display only scored a smoothness score of 68.49% and 5 frames were dropped. In other words, almost one third of all frames were not displayed correctly and the clip was not smooth.
YouTube’s software engineers went to work to take a look at what was going on within Google. The blog reports that they “identified timing issues inherent to the existing design for video rendering as the culprit.” The two main problems were caused between Chrome’s compositor (the component responsible for drawing frames) and the media pipeline (which generates frames). The compositor did not have an efficient way of knowing when a video frame needed display and the media pipeline didn’t know when the compositor would be ready to draw the new frame. This meant that the media pipeline would occasionally select a too-old frame to be displayed by the compositor. YouTube’s engineers took the results from these tests to present to the Chrome team, and for Chrome 44 the media and compositor pipelines have been redesigned in order to better communicate with one another. The improvements include code that determines the optimum settings based on a combination of the screen being used and the video being played. The result is that Google Chrome 44 was significantly smoother than Chrome 43 and of course, these improvements have continued on to Chrome 46, which is the current stable version.