前言
??长征永远不可能一帆风顺，记录下一个看似平凡却对后续发展起着重要作用的踩坑记录。这一次之后，全新的问答搜索被碰撞了debug翻开篇章，开始正向定位开发！
背景
??经过一番对YUV420的折腾，相对来说差不多的422格式并没有放在心上，再加上以前的同事用过这样的格式，似乎只是修改属性参数PIXEL_FORMAT_E的事情呗？
过程记录
??一开始一定是想当然地改变了vpss参数自然不生效，因为对vi我没有深刻的理解。以前因为都是传感器加载的问题，感觉配了也没用。反正会调整。api从传感器中取参数，不改，肯定是不对的。而后尝试将vi也改成PIXEL_FORMAT_YVU_SEMIPLANAR_422之后，目前构建的通道仍没有后续输出。幸运的是，角度旋转的坑让我注意到了venc设置一定不完善。 但在基本参数的配置中，即venc渠道的属性结构没有这个成员！这绝对是肯定的！从理论上讲，海思严谨统一的代码风格应该和谐vivpss一脉相承！为什么死活找不到？ 面对越来越棘手、越来越难搜索的问题，仅仅搜索和阅读帖子就花费了大量的时间和精力，但回报没有回报。突然，我觉得每次我按下车回来，我都不能依靠问答来解决问题。除了解决问题，我还必须找到解决问题的方法！俗话说，教人钓鱼比教人钓鱼好。 回想起接触海思已经有一段时间了，积极的调查和纠正的想法总是无法建立起来。不可能每个人都像老板一样有经验。当论坛和相关资源不完善时，以前的开发人员是怎么做到的？！他们是如何调查和解决问题的？只有一本薄薄的开发手册吗？虽然手册很详细，但很难及时快速找到坑的预防措施！
思路一
??最基本的学习方法必须是用手册咀嚼sample，既然给了这么多钱sdk自然要利用。 首先搜索的是422格式sample是怎么用的？幸运的是venc的最后一个case它被使用了反复比较从mpp初始化到vi再到vpss venc的所有通道属性，再在手册venc部分反复搜索， 
??我肯定没仔细看。让我再看一遍。
??大佬，真的没有 ??真的，我不相信。上次你说真的没了。 ??我。。我真的详细比较了。除了要实现的功能，真的是一样的。 ??是的，那为什么呢？sample就可以呢？ ??是的，为什么可以？
思路二
??还是老办法，论坛搜索依靠同样的坑找到答案。提高搜索者仍在解决具有成本效益的解决方案，毕竟，最快的解决方案是王。当然，更先进的层次是直接避免问题，这需要多年的积累依赖于基本技能体系，不能很快，但不能放弃。
思路三
??海思的log机制.搜了搜，发现即使是解答了无数海思平台疑难杂症的大神，也不可能踩到任何坑。他是怎么定位的？答案是看log。海思平台非常完善log机制。详细介绍了手册/proc/umap下的各个模块，之前倒是也简单看过一点，但是没有把他当成正经的分析工具，而且最为重要的排查logmpp，实际上是放在//实际上是放在/dev目录下的不在/proc下面(本章目录叫proc调试信息说明，看目录清单也是），其实深入仔细看13.4的LOG章节，也提到了/dev目录下的log(手册基本都有，但真的很难找到。 ??既然想到了日志，就先用日志结合。，看看sample到底有什么妖？ ??修改vivpss通道属性后，远程登录 ??cat /proc/venc观察发现编码通道的图像格式仍然是YUV420，类似于之前旋转的分辨率问题，也定位为venc部分是编码设置的问题 ??主进程超时 ??再跑sample422格式进程 ??同样查看venc这并不意味着编码通道必须得到支持YUV422SP的 ??但是在修改编码通道属性中找不到图片格式的设置入口 ??反复比较两个sample差异，做了两个实验:
实验条件：
??sample1 h264编码 默认设置YUV420SP sample5 mjpe编码 默认设置YUV422SP
实验1：
??将sample1的vi vpss属性设置为yuv422sp，此时cat到的venc通道属性还没有YUV420sp
实验2：
??将sample5中的vi vpss属性设置为yuv420sp，此时cat到的venc通道属性本身就变成了YUV420sp！ ??这再次确定了这个属性确实可以改变，并且都支持两种格式 ??开始立功。我在论坛上看到了这样一句话 ??会不会3559也是这样呢？ ??于是又做了实验，又做了实验sample5的编码类型为h264，其余默认设置YUV422SP，果然发现venc自动变成通道属性YUV420SP！
结论
??也就是说，手册上没有明确的表述。venc的通道属性确实没有单独配置的入口，是通过venc_sendframe中VIDEO_FRAME_INFO_S由于编码类型不同，结构体中的属性保持一致，h264不允许YUV422SP格式，将被迫转换YUV420SP
??如果仅此而已，肯定不会单独打开一个记录，第二天醒来后再刷logmpp最后，真相大白(格式25在枚举类型中是YUV422SP。26是YUV420SP）
??这时再次跳出来争宠:我不认真看最基本的指南，怪谁出了问题！(真的很难找到。对于完全不熟悉框架的小白来说) ??HI_MPI_VENC_SendFrame函数注意事项中提到的完全盖章定论，sample这个函数实际上是在底层调用的，vpss图像开始通过他编码(虽然表面上只是vpss和venc绑定后再也不管了)，所以说sample更改编码格式h264后编码通道也被迫变成420。而且我们自己建的通道不是专门调用的吗？代码框架设计不符合别人的规范！
补充
?? 顺便说一句，下一篇文章提到的ive还有海思自带的420和422相互转换的方法 想想理论上最简单的方法，底层可能和这个差不多吧？ YUV4:2:2 —> YUV4:2:0 ： Y不变，将U和V信号值在行(垂直方向)进行隔行抽样。 YUV4:2:0 —> YUV4:2:2 ：Y不变，将U和V每行信号值复制一份，形成连续两行数据。
教训。
??解决问题的想法不能每次都盲目或简单地依靠搜索，最不可分割的是基础知识的积累、丰富的经验、视野，这是解决问题的基础，即时搜索只能发挥作用，毕竟，是工作，第一次解决问题，但不能忘记减少问题，避免问题需要系统的学习积累； ??二是尽量用积极的思维解决问题。每个平台都会有自己独特的醒悟方式，但也会有共同点debug例如，在遇到错误时，采取方法gdb调试啊，看dump文件，像海思这样的日志功能提供了很多便利。后的工程框架里是不是也需要加入日志呢（之前的glog也是个很棒的开源项目），最最最不济，老苯办法printf定位大法总会有所帮助吧 不要慌不要紧，即便是全新的工作环境也要重拾信心，技术固然各领域有所不同，但也总会有殊途同归的部分，加油！