DropBox H.264 lossless details
Recently, an article caught our eye. Dropbox developed a lossless compression algorithm for H.264 and JPEG files, and we decided to test this solution and get some tangible technical details.
The fact that I was immediately able to find out that the compressed H.264 file ceases to be such and can only be used for intermediate storage.
Also, the effect of this type of compression can be expected in two cases: if the file uses CAVLC as an encoder or if the file is encoded with PU and TU blocks of maximum size. And this is only possible if the H.264 codec is configured for the fastest encoding.
One of the most “heavyweight” of all types of data is video, and it is not surprising that the services that are associated with the processing, transmission or storage of it, think about compression. However, the solutions to this problem may be different. In August 2015, DropBox published its vision - its own, not yet final, algorithm for H.264 video files. The company's activities are mainly related to the storage of files of its users. The user is not interested in the form in which they are stored, but the only important thing is that back, when downloading, he will receive exactly the same files that were downloaded. Therefore, the algorithm proposed by DropBox is without quality loss. In addition, the compression result is not a video file of the original format .
In this article, we will try to determine the effectiveness of the algorithm when compressing various files. As an auxiliary tool, we will use the ZOND 265 of Solveig Multimedia (this is what we are), the H.264 and H.265 video analyzer.
All files obtained in the article (compressor executable compiled for Linux Ubuntu x64 12.04, test video files) can be downloaded here .
Compressor source codes and test files are available on the GitHub website . First, compile the compressor and evaluate the test files. Then, let's see the efficiency on files encountered in real life.
Clear instructions for compiling the Pied Piper compressor are available only for Linux, this is essentially one file - the piedpiper_make script. Therefore, we load Linux Ubuntu x64 and enter three commands: After compilation, the compressor files will appear in the current folder: h264dec - the executable file of the compressor and decompressor, libopenh264.so.0, libopenh264.so - auxiliary dynamic library and a link to it. Compression is carried out by the command: Decompression: It should be noted that the result of compression is not a file of the same format as the source, but I am a collection of .pip extension files.
According to the Git repository, the developers used several files as tests - “black.264”, “tibby.264”, “walk.264”, “BA1_FT_C.264”, “BAMQ2_JVC_C.264”. Having loaded them into Zond 265, we see that they are compressed in the same way (see screenshots of Zond 265, “Bitstream” tab, Fig. 1-3 for the “tibby.264” file). The main feature is the use of CAVLC (PPS, entropy_coding_mode_flag: 0) and the absence of B-frames (SPS, max_num_reorder_frames: 0). For performance tests, the first three files are taken.
Fig. 1. Block Sequence Parameter Set (SPS) file «tibby.264»
Fig. 2. Block Picture Parameter Set file «tibby.264»
Fig. 3. The structure of the video stream file "tibby.264"
Users can receive video files in several ways: take it with a camera (for example, their phone), download it from various video services (youtube, vk, vimeo, facebook, etc.), use the program with the transcoding function.
The file from the phone is taken from a regular Android smartphone, this is the file "VID_20150917_131139.264". It also does not contain B-frames, but uses CABAC rather than CAVLC as an arithmetic compressor. On files downloaded from youtube (they contain B-frames and use CABAC), the compressor gives an error, so we will not include them in testing.
The console utility ffmpeg (module "libx264") was taken as a program with the transcoding function. Running ahead, compression was observed only with the ultrafast preset, with the superfast preset compression was no longer possible. The test files are “tractor-ultrafast.264”, “tractor-superfast.264”.
In addition to the indicated ones, three more files are included in the table in order to evaluate whether the proposed algorithm will leave the inclusion of the “CABAC” options and coding by PU and TU blocks of the maximum size effective: “black-cabac.264”, “tibby-cabac.264” and “tibby -cabac-max-blocks. "
The test results are summarized in tables 1 and 2. Data on the number of PU and TU blocks for the table were obtained by the Zond 265 program (tab "Stream Stats"). In fig. Figure 4 shows a screenshot of the data for the tibby.264 file.
Fig. 4. Data on PU and TU blocks for the “tibby.264” file
Table 1. Results of tests of compression efficiency of the compressor of the project “Pied Piper”
Table 2. Results of tests of compression efficiency of the compressor of the project “Pied Piper”
As can be seen from the tables, the proposed Pied Piper project algorithm in the published version is effective in two cases: if the file uses CAVLC as an encoder or if the file is encoded with PU and TU blocks of maximum size. And this is only possible if the H.264 codec is configured for the fastest encoding. Obviously, the files will be quite large. These are the files obtained by the ffmpeg codec with libx264 with the ultrafast preset.
Thank you for your attention, we will be happy to discuss the results. This is our first expert article, do not judge strictly.
The fact that I was immediately able to find out that the compressed H.264 file ceases to be such and can only be used for intermediate storage.
Also, the effect of this type of compression can be expected in two cases: if the file uses CAVLC as an encoder or if the file is encoded with PU and TU blocks of maximum size. And this is only possible if the H.264 codec is configured for the fastest encoding.
About the Pied Piper Project
One of the most “heavyweight” of all types of data is video, and it is not surprising that the services that are associated with the processing, transmission or storage of it, think about compression. However, the solutions to this problem may be different. In August 2015, DropBox published its vision - its own, not yet final, algorithm for H.264 video files. The company's activities are mainly related to the storage of files of its users. The user is not interested in the form in which they are stored, but the only important thing is that back, when downloading, he will receive exactly the same files that were downloaded. Therefore, the algorithm proposed by DropBox is without quality loss. In addition, the compression result is not a video file of the original format .
In this article, we will try to determine the effectiveness of the algorithm when compressing various files. As an auxiliary tool, we will use the ZOND 265 of Solveig Multimedia (this is what we are), the H.264 and H.265 video analyzer.
All files obtained in the article (compressor executable compiled for Linux Ubuntu x64 12.04, test video files) can be downloaded here .
Pied Piper Compressor Efficiency Assessment
Compressor source codes and test files are available on the GitHub website . First, compile the compressor and evaluate the test files. Then, let's see the efficiency on files encountered in real life.
Compression
Clear instructions for compiling the Pied Piper compressor are available only for Linux, this is essentially one file - the piedpiper_make script. Therefore, we load Linux Ubuntu x64 and enter three commands: After compilation, the compressor files will appear in the current folder: h264dec - the executable file of the compressor and decompressor, libopenh264.so.0, libopenh264.so - auxiliary dynamic library and a link to it. Compression is carried out by the command: Decompression: It should be noted that the result of compression is not a file of the same format as the source, but I am a collection of .pip extension files.
git clone github.com/danielrh/losslessh264.git
cd ./lossless264
./piedpiper_make
./h264dec ./source-file.264 ./destination-file.pip,
./h264dec ./compressed-file.pip ./decompressed-file.264.
Pied Piper Test Files
According to the Git repository, the developers used several files as tests - “black.264”, “tibby.264”, “walk.264”, “BA1_FT_C.264”, “BAMQ2_JVC_C.264”. Having loaded them into Zond 265, we see that they are compressed in the same way (see screenshots of Zond 265, “Bitstream” tab, Fig. 1-3 for the “tibby.264” file). The main feature is the use of CAVLC (PPS, entropy_coding_mode_flag: 0) and the absence of B-frames (SPS, max_num_reorder_frames: 0). For performance tests, the first three files are taken.
Fig. 1. Block Sequence Parameter Set (SPS) file «tibby.264»
Fig. 2. Block Picture Parameter Set file «tibby.264»
Fig. 3. The structure of the video stream file "tibby.264"
Other test files
Users can receive video files in several ways: take it with a camera (for example, their phone), download it from various video services (youtube, vk, vimeo, facebook, etc.), use the program with the transcoding function.
The file from the phone is taken from a regular Android smartphone, this is the file "VID_20150917_131139.264". It also does not contain B-frames, but uses CABAC rather than CAVLC as an arithmetic compressor. On files downloaded from youtube (they contain B-frames and use CABAC), the compressor gives an error, so we will not include them in testing.
The console utility ffmpeg (module "libx264") was taken as a program with the transcoding function. Running ahead, compression was observed only with the ultrafast preset, with the superfast preset compression was no longer possible. The test files are “tractor-ultrafast.264”, “tractor-superfast.264”.
In addition to the indicated ones, three more files are included in the table in order to evaluate whether the proposed algorithm will leave the inclusion of the “CABAC” options and coding by PU and TU blocks of the maximum size effective: “black-cabac.264”, “tibby-cabac.264” and “tibby -cabac-max-blocks. "
Test results
The test results are summarized in tables 1 and 2. Data on the number of PU and TU blocks for the table were obtained by the Zond 265 program (tab "Stream Stats"). In fig. Figure 4 shows a screenshot of the data for the tibby.264 file.
Fig. 4. Data on PU and TU blocks for the “tibby.264” file
Table 1. Results of tests of compression efficiency of the compressor of the project “Pied Piper”
Table 2. Results of tests of compression efficiency of the compressor of the project “Pied Piper”
As can be seen from the tables, the proposed Pied Piper project algorithm in the published version is effective in two cases: if the file uses CAVLC as an encoder or if the file is encoded with PU and TU blocks of maximum size. And this is only possible if the H.264 codec is configured for the fastest encoding. Obviously, the files will be quite large. These are the files obtained by the ffmpeg codec with libx264 with the ultrafast preset.
Thank you for your attention, we will be happy to discuss the results. This is our first expert article, do not judge strictly.