Details of DropBox H.264 lossless compression
We recently came across an article . 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 immediately managed to find out that the H.264 file pinched is no longer as such and can only be used for intermediate storage.
Also, the effect of this type of compression can be expected in two cases: if CAVLC is used as a coder in the file 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 possible coding.
One of the most “heavy” among all types of data is video, and it is not surprising that services that are associated with processing, transfer or storage of it, are thinking about compression. However, the solutions to this problem may be different. In August 2015, DropBox published its vision - its, not yet final, algorithm for H.264 video files. The company's activity is mainly related to the storage of files of its users. The user is not interested in the form in which they are stored, but what is important is that back, when downloading, he will receive exactly the same files that were downloaded. Therefore, the algorithm proposed by DropBox is lossless. In addition, the result of compression is not a video file of the original format .
')
In this article we will try to determine the efficiency of the algorithm when compressing various files. As an auxiliary tool, we will use ZOND 265 from Solveig Multimedia (this is what we have), the H.264 and H.265 video analyzer.
All files received in the article (executable compressor file compiled for Linux Ubuntu x64 12.04, test video files) can be downloaded here .
Source codes and compressor test files are available on GitHub . First, let's compile the compressor and evaluate the test files. Then we look at the efficiency of files found in real life.
Clear instructions for compiling the compressor of the Pied Piper project 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 compiling, the compressor files will appear in the current folder:
h264dec - executable file of the compressor and decompressor,
libopenh264.so.0, libopenh264.so - auxiliary dynamic library and link to it.
Compression is performed by the command:
Decompression:
It should be noted that the result of compression is not a file of the same format as the original, and I am a set of .pip 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 file “tibby.264”). 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 efficiency tests, the first three files are taken.
Fig. 1. Block Sequence Parameter Set (SPS) file "tibby.264"
Fig. 2. Block Picture Parameter Set of the file "tibby.264"
Fig. 3. The structure of the video stream file "tibby.264"
Users can get video files in several ways: shoot 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 video from the phone was taken from a regular Android smartphone, this is the file “VID_20150917_131139.264”. It also does not contain B-frames, but uses CABAC as the arithmetic compressor, not CAVLC. 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”) is taken as a program with the transcoding function. Looking ahead, compression was observed only with the “ultrafast” preset, with the “superfast” preset, compression was no longer possible. Test files - "tractor-ultrafast.264", "tractor-superfast.264".
In addition to the above, three more files are included in the table to assess whether the proposed algorithm will leave effective inclusion of the “CABAC” and coding options for PU and TUs of the maximum size: “black-cabac.264”, “tibby-cabac.264” and “tibby” -cabac-max-blocks ".
The test results are summarized in tables 1 and 2. The data on the number of PU and TU blocks for a table are obtained by the Zond 265 program (“Stream Stats” tab). In fig. 4 shows a screenshot with the data for the file "tibby.264".
Fig. 4. PU and TU block data for the tibby.264 file
Table 1. The results of tests of the compression efficiency of the compressor of the project “Pied Piper”
Table 2. Test results of the efficiency of compression of the compressor of the project “Pied Piper”
As can be seen from the tables, the proposed algorithm of the “Pied Piper” project in the published version is effective in two cases: if CAVLC is used as a coder in the file or if the file is encoded with maximum size PU and TU blocks. And this is only possible if the H.264 codec is configured for the fastest possible coding. Obviously, the files will be quite large. These are the files resulting from 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 immediately managed to find out that the H.264 file pinched is no longer as such and can only be used for intermediate storage.
Also, the effect of this type of compression can be expected in two cases: if CAVLC is used as a coder in the file 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 possible coding.
About the Pied Piper project
One of the most “heavy” among all types of data is video, and it is not surprising that services that are associated with processing, transfer or storage of it, are thinking about compression. However, the solutions to this problem may be different. In August 2015, DropBox published its vision - its, not yet final, algorithm for H.264 video files. The company's activity is mainly related to the storage of files of its users. The user is not interested in the form in which they are stored, but what is important is that back, when downloading, he will receive exactly the same files that were downloaded. Therefore, the algorithm proposed by DropBox is lossless. In addition, the result of compression is not a video file of the original format .
')
In this article we will try to determine the efficiency of the algorithm when compressing various files. As an auxiliary tool, we will use ZOND 265 from Solveig Multimedia (this is what we have), the H.264 and H.265 video analyzer.
All files received in the article (executable compressor file compiled for Linux Ubuntu x64 12.04, test video files) can be downloaded here .
Evaluation of the effectiveness of the compressor project "Pied Piper"
Source codes and compressor test files are available on GitHub . First, let's compile the compressor and evaluate the test files. Then we look at the efficiency of files found in real life.
Compression
Clear instructions for compiling the compressor of the Pied Piper project are available only for Linux; this is essentially one file — the piedpiper_make script. Therefore, we load Linux Ubuntu x64 and enter three commands:
git clone github.com/danielrh/losslessh264.git
cd ./lossless264
./piedpiper_make
After compiling, the compressor files will appear in the current folder:
h264dec - executable file of the compressor and decompressor,
libopenh264.so.0, libopenh264.so - auxiliary dynamic library and link to it.
Compression is performed by the command:
./h264dec ./source-file.264 ./destination-file.pip,
Decompression:
./h264dec ./compressed-file.pip ./decompressed-file.264.
It should be noted that the result of compression is not a file of the same format as the original, and I am a set of .pip files.
Test files of the Pied Piper project
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 file “tibby.264”). 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 efficiency tests, the first three files are taken.
Fig. 1. Block Sequence Parameter Set (SPS) file "tibby.264"
Fig. 2. Block Picture Parameter Set of the file "tibby.264"
Fig. 3. The structure of the video stream file "tibby.264"
Other test files
Users can get video files in several ways: shoot 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 video from the phone was taken from a regular Android smartphone, this is the file “VID_20150917_131139.264”. It also does not contain B-frames, but uses CABAC as the arithmetic compressor, not CAVLC. 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”) is taken as a program with the transcoding function. Looking ahead, compression was observed only with the “ultrafast” preset, with the “superfast” preset, compression was no longer possible. Test files - "tractor-ultrafast.264", "tractor-superfast.264".
In addition to the above, three more files are included in the table to assess whether the proposed algorithm will leave effective inclusion of the “CABAC” and coding options for PU and TUs of the maximum size: “black-cabac.264”, “tibby-cabac.264” and “tibby” -cabac-max-blocks ".
Test results
The test results are summarized in tables 1 and 2. The data on the number of PU and TU blocks for a table are obtained by the Zond 265 program (“Stream Stats” tab). In fig. 4 shows a screenshot with the data for the file "tibby.264".
Fig. 4. PU and TU block data for the tibby.264 file
Table 1. The results of tests of the compression efficiency of the compressor of the project “Pied Piper”
Table 2. Test results of the efficiency of compression of the compressor of the project “Pied Piper”
As can be seen from the tables, the proposed algorithm of the “Pied Piper” project in the published version is effective in two cases: if CAVLC is used as a coder in the file or if the file is encoded with maximum size PU and TU blocks. And this is only possible if the H.264 codec is configured for the fastest possible coding. Obviously, the files will be quite large. These are the files resulting from 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.
Source: https://habr.com/ru/post/366447/
All Articles