learnframework的博客

MiracastMiracast是由Wi-Fi联盟于2012年所制定，以Wi-Fi直连（Wi-Fi Direct）为基础的无线显示标准。支持此标准的消费性电子产品（又称3C设备）可透过无线方式分享视频画面，例如手机可透过Miracast将影片或照片直接在电视或其他设备播放而无需任何连接线，也不需透过无线热点（AP，Access Point）。

Wav简单介绍WAV即波形声音文件格式 (Waveform Audio File Format，简称WAVE，因后缀为*.wav故简称WAV文件)，其采用RIFF（Resource Interchange File Format，资源互换文件格式）结构，并符合（RIFF）规范，用于保存Windows平台的音频信息资源，被Windows平台及其应用程序所广泛支持。

学习rtsp协议实战时候，一般需要有一个rstp的服务进行测试和验证，这个rtsp服务器最好是大家可以手写一个，但是这样可能比较耗费时间，初学者建议可以先拿开源的rtsp服务进行验证抓包学习流程等。​ 一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了对标准流媒体传输是一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了对标准流媒体传输协议如RTP/RTCP、RTSP、SIP等的支持。

下面就来讲解为啥有了这个通用Miracast投屏还需要自定义投屏？它们各自有啥优缺点？优点：1、可以丰富定制各种用户的投屏需求，比如车载多屏幕投屏，游戏扩展投屏，平行空间等。因为source和sink端都属于自己开发功能，所以想要怎么定制功能就可以怎么定制，灵活性非常高，这也才可以方便的满足用户各种各样不同的需求。2、因为sink和source两端都是自己开发的功能，所以使用体验和性能方面有比较好的保证，毕竟二者属于一个厂商的产品，所以测试也是比较全面的。

这个比较常见一些，比如在一些背景大屏幕上，其实厂家一般没办法直接做出一个巨大屏幕的背景，主要原因还是因为面板尺寸太大，成本太高，而且也不是很常用，只是在很小一部分景使用。这个需求其实嵌入式相关很多有现成的方案，我们这里实现方式就不是说嵌入式层面方案，而是让大家考虑一下在framework层面，应该如何实现？近来学员vip群里讨论屏幕相关的需求比较多，有2个需求属于粉丝朋友都比较感兴趣一起讨论的，这里刚好做一个记录，方便其他粉丝朋友看看。2、车载多屏互动相关知识。3、input相关知识。

即已经实现了手机和车机投屏互动，车机上手机画面屏幕可以与手机实体屏幕一样就是常见的Mirror模式，如果不一样就是课程里面讲的扩展投屏，平行空间，多屏异显。上面需求是课程手把手带大家讲解实战的，相信大家做出来完全没啥问题，但有同学提出马哥课程都做出来了，有没有更有难度挑战的项目布置过来呢？即画面可以看出来，车机上展示了手机的3个画面，而且3个画面还是内容都不一样，其实就是有3个扩展虚拟屏幕可以展示各自不一样内容。2、实现3个虚拟屏幕的车载手机互联投屏且3个画面各不一样。刚好有一个如下的需求亮点功能。

简单说就是在多屏互动过程中，需要把Activity从这个屏幕移动到另一个屏幕，必然就导致原来屏幕的Activity相关会有移除，体现在input端就是相关的InputWindow会被remove，这个时候input派发事件发现根本没有可以用的window了，所以自然就无法派发事件了，因为不知道派发给谁。这个其实就需要对相关的InputDispatch代码进行详细的分析了。只能拖到一小段，然后在接收事件的部分就收到了一个CANCEL事件，但是在导航手势模式下却没有该问题。

在学习了马哥的wms和多屏互动课程后，大家普遍都可以跟着做出如下图效果的多屏互动

这类问题要分析的话就不得不需要对设备录屏，然后对录屏进行逐帧播放查看现象，看看到底是怎么回事，比如闪黑，闪白看肯定就是中间有一帧黑了，或者白了，导致前后帧的视觉差异太大，但是这个又是一瞬间的现象，导致给人就是闪黑，闪白现象。所以就不得不先拿录制的视频来进行分析，分析就需要对视频进行逐帧进行播放，那么下面马哥就给大家推荐几个工作中可以逐帧播放的视频播放器。这个是个完全命令行的播放器，不可以鼠标操作，具体逐帧播放其实是有按键可以控制的，这个按键就是“s”这个按键。点击 “工具”进入“自定义界面”

SPS（Sequence Paramater Set）又称作序列参数集。对应的是针对一段连续编码视频序列的参数。包含 帧数、POC的约束、参考帧数目、解码图像尺寸和帧场编码模式选择标识等信息。PPS（Picture Parameter Set）又称作图像参数集。对应的是一个序列中某一副图像或者某几幅图像的参数。包含 熵编码模式选择标识、片组数目、初始量化参数和去方块滤波系数调整标识等信息。SPS、PPS的内容都是编码器写入的。

所以每一张图像的裸数据都是很大的。国际上主流制定视频编解码技术的组织有两个，一个是“国际电联（ITU-T）”，它制定的标准 有 H.261、H.263、H.263+、H.264 等，另一个是“国际标准化组织（ISO）”它制定的标准有 MPEG-1、MPEG-2、 MPEG-4 等。采集解决了数据从哪里来的问题，渲染解决的是数据怎么崭新的问题，处理解决的是数据怎么加工的问题，传输解决的是数据怎么共享的问题。描述一段 PCM 数据需要几个量化指标，常用的量化指标是采样率，位深度，字节序，声道数。

android投屏的使用场景以前在新能源车机还没火爆时候，大部分停留在手机小屏幕投屏到大屏幕的情况及整个多端设备的互动，整体需求和技术发展其实也就是比较有限，但是新能源车机火爆后，那么这种手机和车机互联互动的需求出现了爆发性增长，车机上各种创新类的交互都和这个手机车机之间的投屏有关系，因为手机的app生态和更新换代肯定比车机频繁，这样做好了手机车机互动投屏，可以让车机复用手机的强大功能。手机–>车机 --复用丰富的手机生态，和手机互动互联，弥补车机生态不足短板。├── 6-ByteBuffer的详细讲解。

这里主要讲解一下ubunutu系统上的编译和安装，其他系统windows，mac直接有编译好的，所以也就不介绍，自行下载安装使用既可以，不过程序员最看重源码，有了源码自己编译的软件，使用起来还可以观摩观摩github上大神的开源作品。经常做音视频相关的开发都知道，经常需要查看yuv文件，rgb这类原始图片数据文件，所以非常需要一个好用的软件，而且支持ubuntu等linux系统的，这里极力推荐YUView这个开源的软件，有源码可以自己进行编译使用。直接build目录进行make既可以。

AAC（Advanced Audio Coding）是一种现代的音频编码技术，用于数字音频的传输和存储领域。AAC是MPEG-2和MPEG-4标准中的一部分，可提供更高质量的音频数据。AAC被认为是MP3的继任者。AAC比MP3的压缩率更高，压缩后的文件越小，二是保真性比MP3强。ACC最开始是基于MPEG-2的音频编码技术，MPEG-4标准出现后，AAC重新集成了其特性，加入了SBR技术和PS技术。特点：更好的声音质量和更低的压缩比，减少了由于压缩而引入的失真和噪音。

1.确定是否有 /data/misc/audioserver目录，这个目录来获取相关AudioFlinger里面的音频输出目录 2.确定是否有 af.tee property，prop值主要有1，2，4，具体值含义可以frameworks/av/services/audioflinger/NBAIO_Tee.h查看。整个音频流程中，首先是各个app的AudioTrack的数据，传入AudioFlinger，由AudioFlinger进行了混音后，再送入Hal，kernel等。

这里面主屏幕的Layer都会在虚拟屏幕有一个对应的Mirror Layer即直接对主屏幕的每一个layer进行了Mirror

在做android投屏时候，如果知识简单的是实现一下类似scrcpy同屏幕大小传递，其实根本不需要深入了解啥VirtualDisplay相关源码的探索。但是现在车载投屏，手机游戏小窗投屏等高大上功能出现后，这个时候就不得不认认真真学习一下创建VirtualDisplay相关的知识。

VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR设置1、会在DisplayContent的mApplySurfaceChangesTransaction中对Display是否有内容进行确定2、一旦涉及了Display的上有内容到无内容的变化会调用setDisplayLayerStack来重新设置layerStack3、在sf中layer会对layerStack进行匹配然后决定显示哪个Display本文章更多详细代码和资料需要购买课程获取。

也就从SurfaceFlinger的图层中只可以发现一个线索，那就是这个图层本质是systemui负责创建的window，但是这个window的名字其实并没有，只知道systemui进程创建的。那么也不是我们自己自定义显示的，那这个画面到底在哪里？上面window相关的dump信息又相对多了一些线索，比如这里的 ty=KEYGUARD_DIALOG，即可以知道window创建的类型。在搞虚拟多屏和投屏相关业务时候，发现在锁屏时候一个画面比较特殊，但是明显我们自己也没有给虚拟屏幕和投屏有绘制过这个页面。

参考链接：https://github.com/Genymobile/scrcpymeson : https://mesonbuild.com/ninja : https://ninja-build.org/pronounced “screen copy”This application mirrors Android devices (video and audio) connected via USB or over TCP/IP, and allows to control the devic

上面就是ndk编译ffmepg的64位库简单过程哈，同理32位库也是一样，只需要改动一点config参数既可以，具体也给出对应sh脚本。然后对它进行解压既可以，这里也可以使用as自带的版本，或者不是ndk的r22版本试试，最好就下载和这里一样的版本。这些库和include的头文件放好，然后开始编写对应的CMakeList进行相关的修改。一般上面脚本可以直接拷贝使用，只需要改如下两项和路径直接关联的。有了相关的so和include后，既可以把它们用于开发app啦。建立一个简单的native c++的工程。

这种跨设备的投屏场景，流畅的体验是最重要的，这里就会要求投屏中最重要的一个性能指标，那就是投屏的延时。说到了有延时，那么如何科学的评估或者测量延时到底多少呢，人的感觉其实是最不靠谱的，因为我们一般很难感知几十毫秒的差异，除非有几百毫秒以上的差异才可能可以感知到？针对延时测量，首先的知道一个测量延时的数量级，这个延时其实一般都是在毫秒级别，所以测量工具开发时候就需要有一个毫秒表进行展示。2、进入复杂的游戏画面，比如王者荣耀，和平精英等画面，这里需要把毫秒表变成一个悬浮窗口，然后测量延时。

这里setMatrix和setPosition一般都是客户端进程的Transaction相关对SurfaceControl进行的设置，所以这里可以考虑去对应的SurfaceControl加入对应追踪，这个课程已经讲解很多遍了，就不需要多讲解。横屏情况比较好理解，因为只需要对录屏的数据进行等比例缩放既可以，但是竖屏数据就明显需要额外处理，让竖屏居中显示，不然直接等比例缩放，肯定会产生形变。大家可以看到手机屏幕自身是竖屏，但是模拟屏幕是横屏情况，这里看到会有一个自动的竖屏数据放到横屏中间，然后两边啥也不显示。

大家好！这个主要实现是同一个屏幕大小尺寸的投屏情况，即和车载互联的屏幕显示手机镜像一样，以及很多市场上的投屏。

在针对线程无故卡死情况，日志方面也不打印输出情况，需要考虑多个手段来尝试定位分析出目前的线程状态

今天刚好使用了一下新版本的scrcpy，发现了竟然新版本scrcpy支持了音频，这个不得不说让我十分的感兴趣，这里我刚好给出一下相关的调研结果。