Complete a H.265/HEVC bitstream analysis tool

After about one months of spare time, finally completed a H.265/HEVC stream analysis tool. The time includes the usual weekends, evenings, and take some time. Of course, the Mid-Autumn Festival go home do not write code. As of today, after a variety of h.265 sequence testing, there are various tools compared, basically no major problem, the v2.0 version finally released. The v1.x version was made early last year, and in the blink of an over more than a year today continues to do. But the back also do not know whether there is no time and mood perfect, the fate of it. I. Background

According to the Convention, every year in the middle of the year, the company will talk about the new platform pre-research, but not the end of the pre-study, the company's high-level meeting raised hands to finalize a new platform, and make "pre-research" end. One of the themes this year is on h.265. The first h.265 standard came out in January 2013, so far not enough 3 years, there are many companies to stare at this field, the momentum is very good, but after all, only the beginning of a few years, or to be developed.

This kind of propaganda, estimated product managers, industry directors to pay attention to, we do not have to write code to care too much. But it is necessary for the research and exploration of technology. There are many commercially available tools that have been developed online, and some of them are mentioned in the article "hevc/h.265". In view of the previous written H264 stream analysis tool, from this point will be better, one to practice practiced hand, maintain code familiarity, and secondly in the process of writing against the standard manual study, the effect is much better than reading a manual. So on the basis of the original tools, continue to do H265 analysis. second, the idea

In the article "complete a tool to analyze H264 stream," probably wrote some ideas, but not very systematic. Here, write again. The core code is the H264bitstream open Source Library, which provides a good solution for reading, writing, and open source. It provides a basic interface for reading and writing code streams. For example, find NAL, exponential Columbus code, and so on. Therefore, using the open Source Library, just follow the syntax rules in the standard manual to one by one resolution. For this library, do not expand the description in detail here.

0, according to the standard manual syntax, establish a global structure, each field is stored separately. All structures belong to h264_stream_t and h265_stream_t structures. For fields with an indeterminate number, use vector storage uniformly.

1, the user to open the file, the first to determine the file type, currently only support H. 2,652 formats, such as the suffix name, priority to use the suffix, otherwise read the beginning of the NAL head, view the manual, two streams of nal head differences, so you can use this method.

2, read the file by byte, according to start code parsing nal, get nal offset, length, type (if it is slice, will also parse out the type of slice, such as I-frame, p-frame, B-frame), stored in the vector, at the same time, in order to obtain such as video resolution, frame rate, YUV Space and other information, in the analysis of NAL, together. This work is done in order to list the individual nal information as well as the video's summary information in the interface lists. See the screenshot below.

3, the mouse double-click a nal, according to the previous get nal index, offset, read the file and parse, to get the nal details, the method used here is based on the manual, one by one to read the code stream. Third, the realization

Here is the experience of coding, learning process.

Do not move the handwriting code, to download business tools to play, but only a few days of the trial period, a few key nal screenshots saved to facilitate future comparisons. After the expiration, take the HM Project to do a comparison, the project to open a few macros can be run process information printed out, including parsing the various fields of the stream.

Then according to the manual syntax, refer to the H264bitstream code, establish the corresponding structure of h.265, basically the grammatical aspect is consistent, but h.265 more a VPS structure, there are PTL (profile tier level). Adding these grammars can take a lot of time, with a syntax field that is much more, and a manual look at it--even so, there are individual errors and omissions in the back. h.264/h.265 There are many fields that belong to an array type, depending on a value to determine the range. At first reference H264bitstream, the array unified use 255, but later think or use the vector better, then changed.

Read the stream is complete, the Print field is finished, and then from the macro view of the whole project, found to write chaos. This is the tool written last year, in fact, the improvement of space is very large, just lazy, not to do. So take advantage of the opportunity to refactor the code, refactoring after a lot of well-organized.

After that, the debugging is done. In this process, there are still a lot of problems.

Some of the details, such as a place to judge the B-frame, the result of the "= =" written "=", found a half-day. There is another place is pred_weight_table judgment, Judge P and B frame conditions are different, but the code is not pay attention to copy, did not make the right, and spent a long time to troubleshoot. Another is to read the slice header Num_ref_idx_l1_active_minus1 field, also is the code copy, not note is UE (), in and HM code running results compared, spent a lot of time to determine the problem.

Print nal field functions, some do not write in the syntax, resulting in individual fields and other tools inconsistent, and then to the manual change-should be so at the beginning, but also lazy not attentively write.

Let's talk about other problems.

Parsing nal, is to change the code to RBSP, code Engineering Unified Use H264bitstream provides the NAL_TO_RBSP function, but the function is only one byte of the H. S stream, and h.265 nal header has 2 bytes. The NAL header is not included at the time of conversion, so the parameters of the function are modified manually.

There is not much parsing about the Sei,h264bitstream library. Perhaps the SEI information is not very important. There is one more problem. In PPS, More_rbsp_data's judgment is incorrect. Causes subsequent fields to no longer resolve. After several searches, the final use of FFmpeg code judgment method, seems to be normal, no longer delve into.

And as for the other modifications and improvements, I wrote in another article, "About H264bitstream bug fixes and improvements," which is no longer written here. four, the interface

Anyway, it's done. This transaction is counted over. The interface is as follows:

The source code warehouse address is: Https://github.com/latelee/H264BSAnalyzer. Follow-up is not sure whether to continue maintenance, update, the warehouse code prevail.

PostScript: Take some period, there are rumors that big boss to stop investigating a domestic support h.265 chip platform, but I did not get information in the formal situation, do not know whether true. When unsure whether to h.265, I decided to do the tool and complete the tool when I'm not sure whether to stop h.265. Loose ends.

Updates for 2015.11.21:

Release the v2.1 version. Use the tree control to display the code flow syntax elements. Increase the zoom function of the interface. From the last version has almost 2 months, in theory, such a small function does not take so long, mainly because of their laziness, one to the weekend will not write code at all. The new version of the interface is as follows (at first glance it looks like a lot of high end):

Li Yu 66 Anniversary of the founding of the PRC, long live the motherland