Hisilicon 3559 universal platform construction: YUV422 pit stepping record

Preface

   The Long March will never be plain sailing , Record a seemingly ordinary but important step-by-step record for subsequent development , After this time , New question and answer search random debug Just turn the page , Start positive positioning development ！

background

   After a while, I'm sorry YUV420 The twists and turns of , Relatively speaking, it's not much worse 422 The format book is not in mind , Plus, some former colleagues have used this format , It seems to be just modifying attribute parameters PIXEL_FORMAT_E What happened ？

Process record

   At first, it must have been taken for granted vpss Parameters of , Naturally, it does not take effect , Because of vi Your understanding is not deep , Before, because of the problem of sensor loading , I feel it's useless to match it. I can adjust it anyway api Take parameters from the sensor , It didn't change , This is definitely wrong . Then try to vi Also changed to PIXEL_FORMAT_YVU_SEMIPLANAR_422 after , However, there is still no subsequent output on the currently constructed channel . Fortunately , The pit of angular rotation made me notice venc There must be something imperfect about the setting of .
But in the configuration of basic parameters , That is to say venc The attribute structure of the channel does not have this member ！ This is absolutely certain ！ Reasonably speaking, Hisilicon has such a rigorous and unified code style , Should be and vivpss It comes down in one continuous line ！ Why can't you find it anyway ？
Facing the increasingly tricky and difficult search problem , It takes a lot of time and energy to search and read Posts alone, but the return is very little , Suddenly, after pressing enter, I felt that it was definitely not a way to rely on question and answer to solve the problem every time , In addition to solving problems , I have to find a solution to the problem ！ It is better to teach a man to fish than to give him fish .
I recall that I have been in contact with Hisilicon for some time , Positive troubleshooting and correction ideas are always not established , It's impossible for everyone to be as experienced as a big man and learn by analogy , When the forum and related resources are not perfect , What did the previous developers do ？！ How do they check and solve problems ？ Just rely on a thin Development Manual ？ Although the manual is detailed, it is difficult to find the precautions of the pit in time and quickly ！

Train of thought

   The most basic way to learn must be to match the manual sample, Since I have given so much sdk Nature should be used .
The first search is 422 Format in sample How is it used in . Fortunately venc The last case It uses , Compare repeatedly from mpp Initialize to vi Until then vpss venc All channel properties of , Then in the manual venc Part repeatedly search ,

   I must have missed it carefully , Let me see it again

   bosses , Really not
   Really? I don't believe , You said last time that it was really gone
   I .. I really made a detailed comparison , In addition to the functions to be realized , It's really the same
   Is it? , What then? sample It's OK ？
   Yeah , Why can it ？！

Train of thought two

   It's the old way , Forum Search depends on the same trample to find the answer . Improving search business is still a solution with high cost performance , After all, the fastest way to solve the problem is the king . Of course, the higher level is to directly avoid problems , It requires years of accumulation and depends on the basic skill system , There's no quick way , But we must not abandon .

Train of thought three

   Hayes's log Mechanism . Search, search , I found that even the great God who has solved countless problems of Hisilicon platform can't cover all the pits , How is he positioned ？ The answer is to see log. Hisilicon platform has a very perfect log Mechanism . The manual introduces in detail /proc/umap Each module under , I've seen it briefly before , But I didn't take him as a serious analytical tool , And the most important screening logmpp, It's actually on /dev In the catalog , It's not in /proc Next （ The contents of this chapter are called proc Description of debugging information , Look at the catalogue list ）, Actually, take a closer look 13.4 Of LOG chapter , It also mentions /dev In the catalog log（ Manuals are real, basically , But it's really hard to find ）

   Now that I think of the log , Then use the log first Train of thought , have a look sample What demon is there
   modify vivpss After the channel attribute of , Remote login
  cat /proc/venc Observe , It is found that the image format of the coding channel is still YUV420, Similar to the resolution problem of previous rotation , Also located venc part , It's the problem of coding settings

   The main process timed out

   Run again sample in 422 Format process

   See also venc Channel properties , see , It indicates that the coding channel must support YUV422SP Of
   But I can't find the setting entry for modifying the image format in the encoding channel attribute
   Compare the two repeatedly sample differences , Two experiments were done ：

experimental condition ：

  sample1 h264 code default setting YUV420SP sample5 mjpe code default setting YUV422SP

experiment 1：

   take sample1 Of vi vpss Property is set to yuv422sp, here cat To the venc Channel properties have not yet YUV420sp

experiment 2：

   take sample5 Medium vi vpss Property is set to yuv420sp, here cat To the venc The channel attribute itself becomes YUV420sp！
   This confirms once again that this property can indeed be changed and supports both formats
   Train of thought two Start making great contributions . I found such a statement on the Forum

   Will the 3559 The same is true ？
   So I did another experiment , take sample5 The encoding type of is changed to h264, The rest are the default settings YUV422SP, It was found that venc The channel attribute automatically becomes YUV420SP！

Conclusion

   That is to say, there is no clear statement in the manual . however venc The channel attribute of does not have a separately configured entry , It's through venc_sendframe in VIDEO_FRAME_INFO_S The properties in the structure are consistent , However, due to different coding types ,h264 Don't allow YUV422SP Format , Will be forcibly transferred to YUV420SP

   Train of thought three If the function of is limited to this, it will certainly not open a single record , After waking up the next day, I got it again logmpp Reminder , Finally the truth came out （ Format 25 In enumeration type, it is YUV422SP.26 yes YUV420SP）

   At this time Train of thought Jump out and compete for favor again ： I don't read this basic guide carefully , Who is to blame if something goes wrong ！（ It's really hard to find. For Xiaobai who is completely unfamiliar with the framework ）
  HI_MPI_VENC_SendFrame It is mentioned in the notes of function that the conclusion is completely sealed ,sample The bottom layer must actually call this function ,vpss All the images have been encoded by him ,（ Although on the surface, it's just vpss and venc After binding, it doesn't matter anymore ）, So sample The encoding format of is changed h264 The post coding channel is also forcibly changed into 420. And the path we built ourselves was deliberately called ！ The code framework design doesn't conform to other people's specifications ！

Add

   by the way , The next one mentioned ive There are also HEIs' own tools 420 and 422 Methods of mutual transformation
Think of the simplest way in theory , Maybe the bottom layer is similar to this ？
YUV4:2:2 —> YUV4:2:0 ： Y unchanged , take U and V Signal value is good ( vertical direction ) In a interlaced sampling .
YUV4:2:0 —> YUV4:2:2 ：Y unchanged , take U and V Each line of the signal value is copied to form two consecutive lines of data .

lesson .

   The way to solve the problem must not be blind or simply rely on search every time , The most inseparable thing is the accumulation of basic knowledge , Rich experience , The improvement of vision , This is the basis for looking at and solving problems , The instant reinforcement of search can only play a role of adding bricks , It's work, after all , Solve the problem at the first time , But we must not forget that reducing problems and avoiding problems require systematic learning and accumulation ;
   The second is to try to use positive thinking to solve problems , Each platform will have its own unique way of awakening , But there will also be common debug Way , For example, when you encounter a paragraph error, take gdb Debugging , see dump Documents , The log function like Hisilicon provides a lot of convenience , Similarly, do you also need to add logs in the future project framework （ Previous glog It's also a great open source project ）, The worst and the worst , Old benzene method printf Positioning Dharma will always help
   Don't panic it doesn't matter , Even the new working environment should regain confidence , Technology is different in various fields , But there will always be the same part , come on. ！