反思2017 - 无奈

时间

2017-08-11 09:51:06

问题

昨天下午要上公网测试，我负责pc客户端，只做一个功能，
并转换成rtmp，最后推到rtmp服务器来分发。

本来这都是小事，和我对接口的是媒体后端，只有一个接口，
走的也是rtsp标准协议，媒体后端的开发人员估计40多，比我大10岁左右，
就是上篇文章的M，
我们之间的边界非常清楚，我这边以rtsp客户端的角色用record方式推流，
M在rtsp服务器收流，M在收流之后会将rtsp转成rtmp再推向rtmp服务器，
其实这个构成非常简单，但有小概率M的服务后端会崩溃，
最后打印信息显示M在收到rtsp流之后，在推rtmp时write head会失败(ffmpeg)，
返回-22，我就纳闷了，为什么打印信息都显示-22，
下个断点查下问题是最好的方式，为什么不做呢，
M想都不想就是客户端推的数据有问题，最后想了想说他那边加个保护，
防止崩溃，(因为客户端这边ffmpeg推rtsp也是他提供的库，
有效代码简单到只有十几二十行)。我分别在虚拟机/台式机/笔记本上测试过，
发现一个现象，每次导致服务器崩溃，客户端这边都是比较卡，
虚拟机看的特别明显，当然不是每次推流都会导致服务器崩溃，
没有从代码级查问题，也不能肯定这个现象和问题是不是有关联。

最后M的保护加上去了，就是write head失败后，把rtsp流断掉，
这也是一种折中的方法，加上去了还是崩溃，M给的理由是就算断掉了rtsp流，
处理线程还是有数据？？？ write head 之后是write package，
rtsp已经断掉，只剩rtmp，write head失败后就返回了，没有做write package，
换句话说，wirete head成功之后才会启动发包线程来write package，
那现在有数据的处理线程是个毛线？我带着浓浓的疑惑问了一句，
M回答我也不知道，后面加了句我也不能做好所有的程序保护，
这太阳是从西边升起来了？一个工程师就这么理直气壮的来了句这么不负责的话。
这是老程序员，一个40多岁的程序员，每次联调出现问题，不是网线问题，
就是网络问题，或者是路由器，这些理由都是出现过的，还包括ffmpeg协议问题，
rtmp协议问题 电脑驱动问题 交换机问题。年纪大理论知识丰富，
说出的理由每次都能把上面的领导唬住(因为是家族公司，领导不懂技术)，
时间会证明一切，最后都找到问题的根本，就是M的代码问题。
不止一个老大跟我聊过(公司内斗，几个技术老大都走了)，先不谈M的技术能力，
M进公司之前一直是做音视频编解码库的，音视频理论也足，可以称上专家，
但是工程经验几乎没有，说白了就是写编解码库很溜，写产品的逻辑代码就不行，
调试靠猜，宁可面红耳赤用半天时间来争论理论，也不能花5分钟来下端调试一下。

现在产品是第二版，第一版按M的大刀阔斧，做出了一个畸形产品，被抛弃了。
当时技术老大都走了，M按自己的想法做出的东西，音视频严重不同步，
延时也有几分钟，在一个互动的直播项目，简直是不忍直视，最后定位到他的合成模块，
直到第二版产品开会讨论设计时，M还在推卸第一版的责任，当把分析结果推到他面前，
M才哑口，但是每次领导找M单独谈话，或是小组谈话，M都会再次提起这事，
然后把锅丢给我，不过如果开会我也参加，他就不回提及。

现在接着写，刚才耽误了1小时，是去测试是不是pc推流的问题，当我把测试例子丢在他那，
之前坚持的是推流的头信息和媒体数据相隔太远的的理由已经称为过去式了，
现在该为ffmpeg版本更新原因，那。。。这个我就没法去验证了，只能交给测试部去测试。
哎 ， 不是我想针对M，但是M这么大人，甩锅的本事比编码本事强几个数量级，
特别是我们平级，都是部门经理，他还老是爱指挥我，这该怎么改，他年纪比我大，
有时就忍了，毕竟老程序员是要尊重的，但是终端这块，他毛经验都没，就变成瞎指挥了，
这就不能忍了。有时想想，每次领导来办公室，他和其他人的讨论都是面红耳赤，
说的头头是道，每当测试结果证明是他的问题，或是证明他说错了，M那像被欺负的小媳妇模样，
外加他的年纪，多少让我有点同情，特别是经理这个职位是大白菜价时。

想对你说

你年纪大，平常开开玩笑，被你“指挥”一下，没什么大事，但是工作中恶意甩锅，
别摔到我这，没意思，不以技术服人，就算是领导也照样鄙视