blocks|key|chbp5|type|unstyled|text|您好，开启大小画面双路编码模式的接口如下：|depth|inlineStyleRanges|entityRanges|8sdim|iOS&Mac：enableEncSmallVideoStream|offset|length|ch2ui|Android：enableEncSmallVideoStream|3hrkp|Windows（C%2B%2B）：enableSmallVideoStream|d6q1n|Windows（C#）：enableSmallVideoStream|9s66c|Electron：enableSmallVideoStream|d6opd|atomic|[image.png]|1a2b5| 相关问题：|au313|[实时音视频是否支持视频画面截图功能？]|4rhdb|[实时音视频TRTC本地画面和远端画面左右相反]|ed5t0|[实时音视频TRTC如何配置画面质量参数？]|dofnj|[实时音视频TRTC调整画面旋转和缩放]|entityMap|0|LINK|mutability|MUTABLE|data|url|http://doc.qcloudtrtc.com/group__TRTCCloud__ios.html#a2aa9c464203b1c62cbb9ccabccc6334a|1|http://doc.qcloudtrtc.com/group__TRTCCloud__android.html#a3a040c5012cf572b9dfabcca87f2cbb7|2|http://doc.qcloudtrtc.com/group__ITRTCCloud__cplusplus.html#a80648f76afbda35c9bf5d96701c62a9e|3|http://doc.qcloudtrtc.com/group__ITRTCCloud__csharp.html#a4a83369f8798e273caf0a6550cb19cfe|4|https://trtc-1252463788.file.myqcloud.com/electron_sdk/docs/TRTCCloud.html?_ga=1.219472345.1562552652.1542703643#enableSmallVideoStream|5|IMAGE|IMMUTABLE|imageUrl|https://img-cdn.wezhuiyi.com/yibot/456786921/images/ckxzp7ta189f8vyc2lnlh4.png|name|image.png^0|0|0|8|P|0|1|8|P|0|2|D|M|0|3|C|M|0|4|9|M|0|5|0|B|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1M|8|@]|9|@]]|$1|A|3|4|5|B|7|1N|8|@]|9|@$1|1O|C|1P|D|1Q]]]|$1|E|3|4|5|F|7|1R|8|@]|9|@$1|1S|C|1T|D|1U]]]|$1|G|3|4|5|H|7|1V|8|@]|9|@$1|1W|C|1X|D|1Y]]]|$1|I|3|4|5|J|7|1Z|8|@]|9|@$1|20|C|21|D|22]]]|$1|K|3|4|5|L|7|23|8|@]|9|@$1|24|C|25|D|26]]]|$1|M|3|N|5|O|7|27|8|@]|9|@$1|28|C|29|D|2A]]]|$1|P|3|4|5|Q|7|2B|8|@]|9|@]]|$1|R|3|4|5|S|7|2C|8|@]|9|@]]|$1|T|3|4|5|U|7|2D|8|@]|9|@]]|$1|V|3|4|5|W|7|2E|8|@]|9|@]]|$1|X|3|4|5|Y|7|2F|8|@]|9|@]]]|Z|$10|$3|11|12|13|14|$15|16]]|17|$3|11|12|13|14|$15|18]]|19|$3|11|12|13|14|$15|1A]]|1B|$3|11|12|13|14|$15|1C]]|1D|$3|11|12|13|14|$15|1E]]|1F|$3|1G|12|1H|14|$1I|1J|1K|1L]]]]

关于小程序和webrtc。如果跟我一样是一个实用主义者，那我就简单从实用主义角度说一下我的结论：小程序搞定了手机，WebRTC拿下了PC。 如果你对技术比较感兴趣，那我们就可以从多个技术的角度去列举两者的区别，下面是一张详细对比的表格： 📷 实现原理： 小程序音视频是将腾讯视频云的 liteavsdk 嵌入到微信内部实现的，然后通过 <live-pusher> 和 <live-player> 两个标签将 SDK 内部的音视频能力开放出来。所以小程序的标签起到了开发者 API 的作用，而内部的 SDK 则是真正用来实现音视频功能。 WebRTC 由谷歌收购 GIPS 得来（这里不得不提一下，我加入腾讯时所在的第一个团队就是 QQ 团队，当时 QQ 的音视频还是购买的 GIPS 公司的产品，不过由于各种不靠谱，后来就转为自研路线了）。所以其技术被完整的保留并且加入到了 Google 的 Chrome 浏览器内核当中。而且最近苹果也已经开始在 Safari 浏览器中支持 WebRTC 的相关能力。 底层协议 小程序音视频的主要协议是目前在直播领域最为常用的 RTMP 推流协议，以及 HTTP-FLV 播放协议，这两种协议都已经有多年的沉淀而且在互联网上的资料也是汗牛充栋。 WebRTC的底层则是使用RTP和RTCP两种数据协议，其中RTP主要用于音视频数据传输，而RTCP则一般用于控制。 移动端碎片化问题 小程序音视频由于是微信统一实现的，而且微信团队每个版本都尽量要求功能对齐，否则宁可不上，所以在碎片化问题上基本不存在。 WebRTC在这里则要尴尬的多，一方面Android系统的碎片化本身让WebRTC的具体表现呈现“百花齐放”的景象，同时，iOS 目前的内嵌WebView（也就是在微信等APP里打开的各种内嵌网页）不支持WebRTC也还是个很麻烦的问题。 扩展性 小程序音视频跟随微信的版本发布，有什么问题一般是当前代码流修正，然后跟随下一个版本发布，所以一般一个功能点（比如给 pusher 加一个美颜的功能）或者一个问题点（比如不支持手势放大）从确立到最终实现（或解决）仅需要一个月的时间，而且微信APP新版本的覆盖速度也确实挺快。 相比之下，WebRTC则不是一个团队或者一家公司的问题了，因为它现在已经走标准路线，所以每一个新特性都是先确定标准，然后再推动浏览器厂商（包括苹果）进行跟随。这里面的故事就多了，时间也就更久了。 桌面浏览器 相信您已经发现，在前面几个问题的分析上，我的观点都倾向小程序音视频。确实，在目前国内的移动领域里，谷歌和苹果都不能一家说了算，真正说了算的还是微信。 但是在桌面浏览器这个部分，Chrome目前在PC浏览器市场上留到地位的存在决定了 WebRTC 的优势就很大了，开发者可以在不安装插件的情况下就可以实现自己想要的功能。 相比之下，由于没有 Chrome 的原生支持，所以如果我们要在 PC 上对接小程序音视频，就需要安装浏览器插件或者通过 wxlite://start 这样的伪协议唤起本地 exe 应用程序（类似在网页上打开 QQ 聊天窗口）。 并非零和博弈 小程序音视频和WebRTC支架并非零和博艺，双方都有自己的优势和不足，所以本着“打不过他们，就加入他们”的思路，腾讯视频云团队在2018年春节回来后，就马不停蹄地开始了小程序音视频和WebRTC互通的相关工作。 目前，需要向各位开发者汇报的是，在最新版本的微信中，小程序音视频已经可以跟WebRTC打通，目前在PC 的Chrome浏览器上就可以跟小程序进行实时音视频互通。 // to-do 当然，如果您想知道这个功能是怎么实现的，可以继续看下去： 充分了解WebRTC 就像结婚一样，既然你决定要选择另一个人作为人生下半辈子的伴侣，那你肯定会先深入地了解一下TA这个人，比如性格，脾气，爱好等各个方面。 同样，我们要想很好的将小程序音视频和WebRTC打通，那也必须要多了解一下WebRTC，这里我就说一下我对 WebRTC 这个“人” 在性格上的一些理解。 首先，她虽然长得不太好看，但很有内涵。 说WebRTC长得不好看，只是我的一种比喻，我的意思是想说WebRTC的学习成本不低，虽然Google做了很多浅显易懂的PPT来教你怎么 Getting Start，但真要完整的学进去，还是需要静下心来，慢慢地把她当成自己认可的目标去学下去。但是如果你是第一次恋爱（也就是第一次接触实时音视频），你会发现学习WebRTC的过程，本身就是了解一个实时音视频技术细节的过程。 其次，她非常喜欢迁就别人，各种架构方案她都能支持到。 说WebRTC喜欢迁就比人，也是一种比喻，WebRTC所支持的后台架构非常多（比如 Mixer， Mesh，Router），而且谷歌认为这些后台实现都比较简单，所以既没有开放后台相关的源码，也没有提供统一的后台解决方案。这种开放式的设计思路非常好，但副作用就是实现成本高。在真刀真枪的项目落地时，小规模的公司或者开发者就很容易被这种技术门槛挡在门外。尤其是想要将 WebRTC 真正应用到企业级解决方案中，面对录制和存档的刚性需求，就需要花费大量时间进行定制开发。 方案的确立 了解到 WebRTC 的这些特点后，我们的互通方案也就比较清晰了： 首先，小程序音视频的特点是接口简单，快速上手，这是小程序的优势；而这一点恰恰是WebRTC的劣势，所以我们没有必要在小程序端为WebRTC暴露十几个接口类，而是继续采用小程序音视频的 <live-pusher> 和 <live-player> 标签来解决问题。 其次，WebRTC 的后台没有官方实现，那就意味着这里有很大的发挥空间，腾讯视频云就可以实现一套WebRTC后台并将其同小程序音视频所使用RTMP后台进行打通。简单来说，腾讯视频云要在小程序音视频和WebRTC之间充当红娘（更确切的说，应该是翻译员）的角色。 但是看过《新闻联播》里国家领导人之间谈话镜头的人都知道，这种翻译是会影响交流速度的。小程序音视频和WebRTC之间互通，中间引入一个翻译员，是不是通讯延时也就增加了？ 其实不会，因为小程序音视频和WebRTC的视频编码标准在常规应用场景中是一致的，都是H.264标准，这是音频格式不同而已。这就意味着，翻译员要做的事情很少，两边基本都能挺对对方在说什么，所以延时不会增加太多。 成功的握手 下图所展示的就是腾讯视频云在小程序音视频和WebRTC互通问题上所采取的方案： 📷 （1）首先，微信端的小程序通过腾讯视频云SDK将音视频流推送到腾讯云 RTMP 服务器。 （2）其次，腾讯云 RTMP 服务器的会对音视频数据进行初步的转化处理，然后透传给腾讯视频云的实时音视频后台集群。 （3）再次，实时音视频后台会再次将数据交给一个叫做 WebRTC-Proxy 的模块，就在这里， WebRTC-Proxy 要将来自小程序音视频的音视频数据翻译成 WebRTC 理解的“语言”。 （4）最后，在PC上的Chrome浏览器，就可以通过浏览器内置的WebRTC模块跟 WebRTC-Proxy 通讯，进而看到小程序端的视频影像。 （5）上面的四个过程倒过来，就可以实现双向视频通话；而将腾讯视频云作为星型结构的中心节点，多个端（不管是小程序还是Chrome浏览器）都接入进来，那就可以形成多人音视频解决方案。 打通房间逻辑 仅仅完成了音视频数据在小程序和WebRTC之间的握手还远远不够，因为在一次成功的音视频通话背后，不仅仅是把一端的音视频数据传递到另一端这么简单，还有状态的同步和成员间的状态协同。 比如多人视频通话中，涉及到呼叫和接通的流程，其中一方如果挂断了，其他人要收到挂断的通知。同时，如果有新的参与者加入，那么其他人也要收到相应的通知。WebRTC 中有很多组件，比如 RTCPeerConnection 就在处理上诉林林种种的逻辑。但是 WebRTC 的接口中引入的新名词非常多，对于初学者来说还是有一定的入门门槛，为了简化这里的逻辑，我们引入一个叫做“房间”的概念。 所谓房间（Room），就是把同时参与视频通话的各方圈在一起的一个东西。比如双人通话中，通话中的两个人 A 和 B 就可以认为在一个房间中。再比如在多人通话中，通话中的五个人（A B C D E）也可以认为是在一个房间里。 有了房间的概念，那我们就可以对刚才说的状态协同用两个简单的动作描述一下：如果有一个人加入了视频通话，那么就可以理解为他/她已经进房（EnterRoom）了；如果有一个退出了视频通话，那么就可以理解为他/她已经离开房间（LeaveRoom）了。而房间的门板上始终写着：“目前在房间里有哪几个人”。 有了房间的概念，我们就可以将小程序的两个简单的 <live-pusher> 和 <live-player> 标签，同 WebRTC 那一套复杂的 API 进行功能上的对齐，我们甚至不需要修改我们在第一版中定义的接口，就可以达成这个目标： 📷 （1）<live-pusher> 的 url 接口不再传递 rtmp:// 协议的推流地址，而是传递 room:// 协议的推流地址。room:// 协议的使用方式可以参考我们的原理版文档 DOC。 （2）<live-pusher> 标签在 start 成功之后，就相当于成功进入一个 room，之后，您可以通过 onPushEvent (PUSH_EVT_ROOM_USERLIST = 1020) 事件，收到房间里还有那些人的信息。在视频通话期间，房间内各个成员的进进出出，也都会通过这个事件通知给您的小程序代码。 （3）ROOM_USERLIST 里每一项都是一个二元组（如果是 1v1 的视频通话，ROOM_USERLIST 里只会有一个人）: userid 和 playurl。 userid 代表是哪个用户， playurl 则是这个用户远程画面的播放地址。您要做的只是使用 <live-player> 标签播放这些远程画面的图像和声音而已。 （4）在 WebRTC 这一端，您可以参考我们的 webrtc API，这套 API 相对于 WebRTC 原生的 API，更适合初学者使用。

这个问题可能是由于 iOS 系统中的浏览器对于 WebRTC 的兼容性和处理方式与 Android 系统不同导致的。在 iOS 中，由于系统限制，浏览器可能在网络切换时需要重新建立连接。为了解决这个问题，您可以尝试以下方法： 1. 确保您的 iOS 设备上的浏览器支持 WebRTC。虽然大多数现代浏览器都支持 WebRTC，但某些较旧的浏览器可能不支持。建议使用最新版本的 Safari 或其他支持 WebRTC 的浏览器。 2. 在网络切换时，尝试手动重新加入房间。您可以通过监听网络状态变化来实现这一点。当检测到网络切换时，可以先退出当前房间，然后重新加入房间以重新建立连接。 3. 如果问题仍然存在，您可以尝试使用其他的 WebRTC 库，如 Adobe Media SDK 或 Jitsi Meet，看看它们是否能解决 iOS 设备上的问题。 4. 如果可能的话，您还可以尝试使用原生应用程序而不是浏览器来解决此问题。原生应用程序通常能更好地处理 WebRTC 连接，因此可能不会遇到与浏览器相关的问题。 希望这些建议能对您有所帮助。如果问题仍然存在，请提供更多详细信息，以便我们能更好地帮助您解决问题。 以上为腾讯混元大模型提供,仅提供参考价值. ---杨不易呀自动回复

在视频通话过程中，关闭摄像头后旋转屏幕，摄像头自动打开的原因可能有以下几种： 1. 软件设置：某些应用程序可能会在检测到屏幕旋转时自动重新启用摄像头。这可能是为了提高用户体验，确保用户在旋转屏幕后能够立即看到对方。 2. 硬件问题：摄像头传感器可能与屏幕旋转传感器相互关联。当屏幕旋转时，传感器可能误认为摄像头被打开，从而导致摄像头自动开启。 3. 系统错误：手机操作系统可能在处理屏幕旋转和摄像头关闭事件时出现错误。这可能导致摄像头在关闭后意外打开。 要解决这个问题，可以尝试以下方法： 1. 检查应用程序设置：检查视频通话应用程序的设置，看是否有选项可以禁用屏幕旋转时自动打开摄像头的功能。 2. 重启手机：尝试重启手机，看看问题是否得到解决。重启可能会刷新系统设置并修复可能的错误。 3. 更新软件：确保视频通话应用程序和操作系统都是最新版本。过时的软件可能导致兼容性问题。 4. 联系客服：如果以上方法都无法解决问题，可以联系手机制造商或应用程序开发商的客服，寻求技术支持和解决方案。 以上为腾讯混元大模型提供,仅提供参考价值. ---杨不易呀自动回复

问下 node 版本是多少 这个应该是执行 configureProject.js 报错导致拷贝文件缺失 这个拷贝没成功 static 下面缺少压缩包导致的

解决了吗，遇到了相同的问题

我出现这个情况是用的1.7.1版本，安卓出现了；后面换成1.7.3. 解决了安卓的这个问题了。但是iOS编译又没通过了。所以仅供参考，具体的还得问腾讯技术客服了。 tencent_calls_engine: 1.7.1

TRTC 后台系统升级维护中，「个人认证」账号暂时无法新建应用，「企业认证」账号不受影响，感谢您的理解与支持。

音视频产品：https://console.cloud.tencent.com/trtc

您好，您这边应该是因为包月套餐的功能限制生效影响，导致小程序端的实时音视频服务受限，这边只需要采购TRTC【包月套餐-尊享版】即可恢复，无需其他开发改动，或者您也可以先在TRTC控制台的应用详情中领取【包月套餐-体验版】来快速恢复业务。 包月套餐于2月15日上线，所有在用的客户均提供了免费缓冲时间至4月1日。后台于4月1日起开始全网进行灰度限制，每个账号实际影响时间可能会因灰度有所偏差。在套餐上线前、缓冲到期前和限制正式生效前均会有通知，您可以检查下是否有消息过滤，避免遗漏后续其他产品变更的影响通知。 目前包月套餐有新上线的限时全网8折活动，推荐您开启自动续期进行订阅，感谢您的关注。 包月套餐上线公告详见：https://cloud.tencent.com/document/product/647/84072

这是因为 tuichat 和 tuiliveroom 都使用了 tuicore这个库，不过前者是直接tuicore的源码集成的后者是maven的aar，可以删除一下：tuiliveroom/build.gradle 里面的 tuicore 依赖，改成：tuicore 就行～

hi https://cloud.tencent.com/document/product/647/66671 参考

hi https://cloud.tencent.com/document/product/647/81015请参考这里 图片

HI 可以呼叫的时候重新调用接口获取一下，再赋值UI，另demo有这个情况吗

排除以下 1. chrome插件实现太麻烦 2. html2canvas性能消耗太大 3. 云直播提供的混流     a. SDK设置混流布局无效    b. 无法还原原来的界面    c. 有一些业务上的操作过一段时间需要断流重新推送新布局

您好 根据您的问题 需要自行发送roomid 请知悉

rtsp 转 webrtc ，浏览器播放，延迟300ms以内

现在支持了