To GIF or not to GIF?
Hello! My name is Anton, I am developing the server part of iFunny - a mobile comic service. In this article, I will talk about how our approach to working with animation in the project evolved and what profits were obtained in the end.
It is known that humor slows down the aging process, and laughter prolongs life, which is why we are so pleased to do iFunny, which gives smiles and good mood to more than 4 million users every day (at the moment, unfortunately or fortunately, mostly from the USA) . We strive to become the most convenient fun-browser in the world, as well as a place where the best humor is born. Our users download more than 250,000 works per day.
')
Until recently, we distributed around 150TB of statics per day, but with the addition of animation to the project, we received an increase in the amount of downloadable content by 17% and an increase in daily traffic to 750TB.
It so happened that at present in GIF the most interesting cuts from humorous (and not so) videos are encoded, which sadly affects the volume of the resulting files. According to our feelings, the average size of GIF-animation in the modern Internet is about 5Mb. The logical question that we asked during the development is whether we can somehow optimize the animation on the server side in order to reduce its volume?
After conducting a series of experiments with various animated files and optimization algorithms (Basic Frame Optimization, Transparency Optimization), we concluded that the gain from optimization for most of the images turned out to be very small, about 10-20%. Moreover, if the GIF-animation was already well optimized by its author, then with the automatic approach, we could get the opposite effect.
The light of hope that it will be possible to somehow ease the volume of animation files has gone out, and we began to use GIF in the form in which users upload it to us.
If the implementation of GIF support on the server side and in the iOS client was pretty simple, then on the Android client we had to resort to the tools of bearded Jedi - libgif + JNI, which only provoke us.
As soon as everything was finished, we passed the test of censors in the App Store, uploaded the application to Google Play and started ... And immediately after the first day we saw a sharp jump in content views and, accordingly, traffic. In the first 24 hours the traffic has grown 6 times!
In total for half a month the volume of the distributed traffic increased by 200% and in June, thanks to the launch of the animation in iFunny, we distributed 4.75 Petabytes! The increase in the activity of the audience, of course, can not but rejoice, but did it all turn out well in the end?
We were ready for a certain number of GIF-animations in iFunny, but the statistics we received in the first few days made us understand that we are not quite optimistic: the actual number of loaded GIF-animations per day was 5 times higher than expected. Coupled with massive 3-4 megabyte GIFs running every 3-5 static images, we received a service that could only be used via WiFi. Even users with unlimited 3G had a hard time: the animation was loading for a long time, and because of the active work of the 3G module, the device was warming up and killing the battery.
Against the background of sobering statistics, we wondered: to what extent is the GIF (set of images, in fact) suitable for such use? We see that if we are dealing with a simple animation containing a small number of frames, the use of a GIF is more than justified. However, as I said above, a modern humorous GIF is a cutting of interesting moments from video clips ...
Based on the foregoing, we decided to try to abandon the GIF in favor of some video format suitable for playing short animated videos. In this case, it was necessary to find the appropriate encoding format. Standards for coding h.263, h.264, as well as the video codec vp8 in the container WebM were considered.
We carried out GIF video recoding tests, and the light at the end of the tunnel loomed: the size of the resulting videos was 2-10 times smaller than the GIF source!
It remains to determine the codec. The use of the retired codec - h.263 gave a terrible resulting picture and contradicted our moral standards, so we brushed it off first.
h.264 is a good codec, but we did not want to get involved with patented technologies, and the resulting file size was quite large: 20-40% more than when encoding the same fragment in vp8. Therefore, we decided to stop at vp8.
An additional argument when choosing vp8 was also the fact that Google is actively implementing and using it on YouTube, and an improved VP9 format is currently being developed, which makes it possible to judge the success and prospects of the entire project.
To convert from GIF to WebM, we use ffmpeg assembly with support for GIF decoder and vp8 encoder. The process of conversion itself goes without special comments and rather quickly, but immediately we encounter a problem in the resulting video. Take this GIF animation, for example:
Please note that the last frame has a delay of 2 seconds, after which the animation is played again. In the resulting WebM file, this delay somewhere magically disappears, and the last frame “skips”. Analysis of other content showed that the delay after the last frame of the animation is always removed, which is quite a big problem for us, because we want users in the application not to see the difference between the GIF and the video. The problem was solved, but with such a crutch that we are still blushing with shame: we add a duplicate of the last frame to the convertible GIF.
At the time, hardcore reigned in the ranks of mobile developers: they assembled libvpx for the necessary platforms, wrote a wrapper for C and voila.
After the release of the version where we began to play short videos instead of GIF-animation, it became clear that the work done had borne fruit: the traffic consumption in one session decreased from inadequate 50-100Mb to quite comfortable 7-20Mb, devices became less heated and killed battery, and most importantly, users began to see content more often than its preloader.
If we talk about our handing out traffic, the picture is as follows:
The transition from GIF to WebM has reduced the volume of distributed traffic by 30% and reduced CDN costs by about $ 50,000 per month.
The GIF87 format, created more than 20 years ago, was intended by the author to be used to transfer raster images over the network, while the GIF89 modification allowed using images with transparency and storing a set of simple slides with a certain delay — animation.
On his life path, the format managed to make several significant revolutions, now dying, now being born again.
For example, we all remember animated banner ads, which, unfortunately, are still used in some advertising networks. Yes, now memories of flashing and jerky banners are more associated with hallucinations from LSD, but 10-20 years ago it was a revolution - the Internet ceased to be static.
Now GIF is also making a revolution, contributing to the avalanche-like distribution of a new format of humorous content - short video clips. However, from the height of our experience, we can say that using GIF for such content is not correct for a number of reasons listed above, and only one weighty argument forces users to distribute cuts from video clips in GIF - this is its universal support in all browsers. We have no hands tied to the possibility of web browsers, so we managed to “revive” iFunny without the drawbacks inherent in the GIF.
It is known that humor slows down the aging process, and laughter prolongs life, which is why we are so pleased to do iFunny, which gives smiles and good mood to more than 4 million users every day (at the moment, unfortunately or fortunately, mostly from the USA) . We strive to become the most convenient fun-browser in the world, as well as a place where the best humor is born. Our users download more than 250,000 works per day.
')
Until recently, we distributed around 150TB of statics per day, but with the addition of animation to the project, we received an increase in the amount of downloadable content by 17% and an increase in daily traffic to 750TB.
GIF Optimization
It so happened that at present in GIF the most interesting cuts from humorous (and not so) videos are encoded, which sadly affects the volume of the resulting files. According to our feelings, the average size of GIF-animation in the modern Internet is about 5Mb. The logical question that we asked during the development is whether we can somehow optimize the animation on the server side in order to reduce its volume?
After conducting a series of experiments with various animated files and optimization algorithms (Basic Frame Optimization, Transparency Optimization), we concluded that the gain from optimization for most of the images turned out to be very small, about 10-20%. Moreover, if the GIF-animation was already well optimized by its author, then with the automatic approach, we could get the opposite effect.
The light of hope that it will be possible to somehow ease the volume of animation files has gone out, and we began to use GIF in the form in which users upload it to us.
Release version with GIF
If the implementation of GIF support on the server side and in the iOS client was pretty simple, then on the Android client we had to resort to the tools of bearded Jedi - libgif + JNI, which only provoke us.
As soon as everything was finished, we passed the test of censors in the App Store, uploaded the application to Google Play and started ... And immediately after the first day we saw a sharp jump in content views and, accordingly, traffic. In the first 24 hours the traffic has grown 6 times!
In total for half a month the volume of the distributed traffic increased by 200% and in June, thanks to the launch of the animation in iFunny, we distributed 4.75 Petabytes! The increase in the activity of the audience, of course, can not but rejoice, but did it all turn out well in the end?
We were ready for a certain number of GIF-animations in iFunny, but the statistics we received in the first few days made us understand that we are not quite optimistic: the actual number of loaded GIF-animations per day was 5 times higher than expected. Coupled with massive 3-4 megabyte GIFs running every 3-5 static images, we received a service that could only be used via WiFi. Even users with unlimited 3G had a hard time: the animation was loading for a long time, and because of the active work of the 3G module, the device was warming up and killing the battery.
Need to do something ...
Against the background of sobering statistics, we wondered: to what extent is the GIF (set of images, in fact) suitable for such use? We see that if we are dealing with a simple animation containing a small number of frames, the use of a GIF is more than justified. However, as I said above, a modern humorous GIF is a cutting of interesting moments from video clips ...
Based on the foregoing, we decided to try to abandon the GIF in favor of some video format suitable for playing short animated videos. In this case, it was necessary to find the appropriate encoding format. Standards for coding h.263, h.264, as well as the video codec vp8 in the container WebM were considered.
We carried out GIF video recoding tests, and the light at the end of the tunnel loomed: the size of the resulting videos was 2-10 times smaller than the GIF source!
It remains to determine the codec. The use of the retired codec - h.263 gave a terrible resulting picture and contradicted our moral standards, so we brushed it off first.
h.264 is a good codec, but we did not want to get involved with patented technologies, and the resulting file size was quite large: 20-40% more than when encoding the same fragment in vp8. Therefore, we decided to stop at vp8.
An additional argument when choosing vp8 was also the fact that Google is actively implementing and using it on YouTube, and an improved VP9 format is currently being developed, which makes it possible to judge the success and prospects of the entire project.
To convert from GIF to WebM, we use ffmpeg assembly with support for GIF decoder and vp8 encoder. The process of conversion itself goes without special comments and rather quickly, but immediately we encounter a problem in the resulting video. Take this GIF animation, for example:
Please note that the last frame has a delay of 2 seconds, after which the animation is played again. In the resulting WebM file, this delay somewhere magically disappears, and the last frame “skips”. Analysis of other content showed that the delay after the last frame of the animation is always removed, which is quite a big problem for us, because we want users in the application not to see the difference between the GIF and the video. The problem was solved, but with such a crutch that we are still blushing with shame: we add a duplicate of the last frame to the convertible GIF.
At the time, hardcore reigned in the ranks of mobile developers: they assembled libvpx for the necessary platforms, wrote a wrapper for C and voila.
Release version with WebM
After the release of the version where we began to play short videos instead of GIF-animation, it became clear that the work done had borne fruit: the traffic consumption in one session decreased from inadequate 50-100Mb to quite comfortable 7-20Mb, devices became less heated and killed battery, and most importantly, users began to see content more often than its preloader.
If we talk about our handing out traffic, the picture is as follows:
The transition from GIF to WebM has reduced the volume of distributed traffic by 30% and reduced CDN costs by about $ 50,000 per month.
findings
The GIF87 format, created more than 20 years ago, was intended by the author to be used to transfer raster images over the network, while the GIF89 modification allowed using images with transparency and storing a set of simple slides with a certain delay — animation.
On his life path, the format managed to make several significant revolutions, now dying, now being born again.
For example, we all remember animated banner ads, which, unfortunately, are still used in some advertising networks. Yes, now memories of flashing and jerky banners are more associated with hallucinations from LSD, but 10-20 years ago it was a revolution - the Internet ceased to be static.
Now GIF is also making a revolution, contributing to the avalanche-like distribution of a new format of humorous content - short video clips. However, from the height of our experience, we can say that using GIF for such content is not correct for a number of reasons listed above, and only one weighty argument forces users to distribute cuts from video clips in GIF - this is its universal support in all browsers. We have no hands tied to the possibility of web browsers, so we managed to “revive” iFunny without the drawbacks inherent in the GIF.
Source: https://habr.com/ru/post/191892/
All Articles