海思源码
① DevOps工具配置不当，微软、任天堂、华为等50余家名企源码遭泄露
据外媒 BleepingComputer 报道，雹丛由于基础架构配置有误，来自技术、金融、电商、制造业等众多领域的数十家知名公司源码遭到泄露。
这些公司包括微软、Adobe、联想，AMD、高通，摩托罗拉、海思、任天堂、迪士尼、江森自控等，而且这一名单还在不断增长中。
来自瑞士的开发者 Tillie Kottmann 通过各类第三方源收集到了这些漏洞，他自己也找到了不少 DevOps 工具中的配置错误，而这些工具可以用来访问源代码。
遭泄露的源码被发布在 GitLab 上一个公开存储库中，并被标记为 “exconfidential” （绝密），以及 “Confidential & Proprietary”（保密&专有）。
（更新：GitLab 仓库均已被删除，Kottmann 现采用 telegram 群组来公布这些信息。）
根据安全研究人员 Bank Security 提供的渗桥信息，该存储库中大约包含了超过 50 家公司的源码。但有一源喊樱些文件夹是空的，还有一些存在硬编码凭证——一种创建后门的方式。
Kottmann 提到，一些代码库中确实存在硬编码凭证，他在发布前已尽可能地将其删除，“以避免造成直接伤害或是助长更大的破坏”。另外，他也坦承自己并未在发布前与每一家受影响的公司进行联系，但他们确保自己“尽了最大的努力将负面影响最小化”。
目前，Kottmann 已应部分企业的要求删除了代码。例如 Daimler AG，梅赛德斯-奔驰的母公司；联想的文件夹也已经空空如也。针对有移除代码要求的公司，Kottmann 表示愿意遵守，并乐意提供信息，“帮助公司增强基础架构的安全性”。
事实上，从收到的 DMCA 通知数量（估计至多 7 份）和法律代表等的联系来看，许多公司仍对代码泄露事件不知情。另有部分公司没有撤除代码的意思，甚至有公司觉得“挺有趣”，只想知道 Kottmann 是如何获得代码的。
此次泄露的代码中，有一些项目早已由其原始开发者公开发布过，或是已经有很长时间不再更新和维护。网络安全公司 ImmuniWeb 的创始人兼首席执行官 Ilia Kolochenko 指出，“从技术角度来看，这次的泄露并不算很严重……若没有每天的支持和改进，源代码也会迅速贬值”。
尽管如此，这样大规模的泄露事件原因还是值得引起注意。许多公司使用错误的 DevOps 工具配置，引发源码暴露。Kottmann 及其团队近期正在 探索 运行 SonarQube 的服务器，他们发现，有成千上万的公司由于未能正确保护 SonarQube 安装而暴露了源码。
对于泄露源码的行为，安全专家 Jake Moore 对 科技 网站 Tom's Guide 表示，“失去对源代码的控制就像将银行蓝图交给抢劫犯一样……受影响的网站应立即采取保护措施……若用户在公司之前发现自己的数据遭到泄露，那无疑是在伤口上撒盐”。
基于法律层面，Kolochenko 认为源码发布者可能会因侵犯版权或违反计算机法而被起诉，但通常大型公司不会上诉，他们宁愿从存储库中快速删除源代码并修复其内部 DevOps 安全流程。
为此，Kolochenko 建议“企业应修改并持续监控 DevOps 操作，将其转换为敏捷的 DevSecOps”。
② live555移植到hi3516做rtsp服务器
live555库本身实现了做rtsp服务器，客户端可以通过rtsp客户端访问服务器上的文件并播放，支持的文件格式如下:
本次任务实现了把live555移植到嵌入式海思芯片hi3516上做rtsp服务器，除了支持客户端播放服务器上上面格式文件外，另添加了实时播放hi3516摄像头图像与音频的功能。
live555源码目录如下:
四个基本的库分别是:BasicUsageEnvironment, groupsock, liveMedia和UsageEnvironment。
编译后即生成这4个库文件:
这里我只简单说下liveMedia库的功能，其他三个库是live555运行的基础库，太(mei)简(yan)单(jiu),就不说了。
liveMedia库包含了音视频相关的所有功能，包含音视频文件的解析，RTP传输封装等，我们可以看到这个目录下有对h264、AAC等文件解析的支持:
交叉编译过程：略
这里我主要是修改mediaServer文件夹下的示例程序，添加实时预览摄像头图像与mic声音功能。
hi3516芯片，视频编码格式为h264,音频编码格式为AAC。
1.添加音频AAC支持
添加类 ADTSAudioLiveSource ,继承自FramedSource
在该类的doGetNextFrame函数里实现获取hi3516音频数据做为rtsp服务器音频源。
注意点：
1.1 adts默认是带7字节或者9字节的头，传给rtsp的时候是要去掉头的，实际上RTSP通过rtp传输AAC帧的时候是不带adts头的，而是带4个字节的mpeg4-generic头。
1.2 从FramedSource继承而来的变量
每次doGetNextFrame帧时，从FIFO里取一个完整的AAC帧，把帧拷贝到fTo buf里面，然后比较帧大小与fMaxSize来赋值几个关键的变量:
注意，不管帧长是否大于fMaxSize，每次都需要把完整的帧拷贝到fTo指针，live555内部会根据fNumTruncatedBytes等变量自行处理分包。
1.3 doGetNextFrame函数最后不管有没有取到帧，都需要执行FramedSource::afterGetting
1.4 采样率，通道数，configstr等的计算
这几个变量在mediaSubbsession建立RTPsink时要用到，它直接影响了SDP里对于AAC音频描述字段的产生
添加类 ,继承自
createNewStreamSource函数创建上面的ADTSAudioLiveSource做为音频输入源，参数estBitrate为预估的码率，海思AAC编码码率设置为24kbps,所以estBitrate设置为24.
createNewRTPSink有必要继承，因为需要根据音频源的采样率、通道数等创建RTPSink.
2.添加h264支持
添加 H264FramedLiveSource ,继承自FramedSource
unsigned maxFrameSize()函数必须继承，里面设置帧最大可能的大小，我设置为100000，如果不继承就是默认的，会出现画面马赛克
doGetNextFrame函数里面和AAC取帧的处理差不多，我加多了一个步骤，就是第一次取帧的时候会调用接口去产生一个关键帧，并且等待这个关键帧到来才处理，这样连接后出图会比较快。
添加类 ,继承自
这个类就是实现createNewStreamSource时创建H264FramedLiveSource
3.修改DynamicRTSPServer
修改类DynamicRTSPServer，在lookupServerMediaSession函数里动点手脚，默认在这个函数里面会根据文件名去寻找服务器下相应的文件做为直播源，我这里比较如果是我特定的live源名字则直接返回，相应的live源创建rtsp服务器的时候就添加好
4.初始化rtsp server
初始化rtsp服务器，添加一个ServerMediaSession，该mediaSession添加一个和一个，然后把该mediaSession添加给rtsp服务器。
客户端访问 rtsp://x.x.x.x/ch0.live 时就可以看到实时的摄像头图像与声音啦!