- 当前 Bug 的表现（可附上截图） 调用live-pusher进行推流，几秒钟后，如下图所示，视频窗口会变黑，返回-1307错误代码（含义：网络断连,且经三次抢救无效，可以放弃治疗，更多重试请自行重启推流），重启推流，恢复几秒钟后，问题依旧： [图片] [图片] - 预期表现 正常情况下应该会持续正常推流，不会隔几秒钟就断开 - 复现路径 用于调试的代码就是官网https://developers.weixin.qq.com/miniprogram/dev/component/live-pusher.html提供的实例代码，使用的推流服务器就是默认的"https://domain/push_stream"，如下图所示： [图片] - 提供一个最简复现 Demo 用微信开发者工具编译上述代码在苹果手机上真机调试就可以复现上述现象

- 当前 Bug 的表现（可附上截图） [图片] 一直是上行带宽不足,直播没有成功 用live-pusher组件,加上自己的推流地址,一直提示上行带宽不足; - 预期表现 正常推流,正常直播 - 复现路径 - 提供一个最简复现 Demo https://developers.weixin.qq.com/s/go5zmfmA7S8U

- 当前 Bug 的表现（可附上截图） live-room中关闭live-pusher的摄像头，听不到声音，打开摄像头正常 - 预期表现 能正常听到声音 - 复现路径 官方示例：https://github.com/TencentVideoCloudMLVBDev/roomservice_server_java 在新建live-room时选择纯音频推流；观众进入直播间听不到声音 [图片]

websocket 在安卓真机下使用。 执行close 后 会间隔大概 3秒到4秒 才执行 onclose 事件。 而ios下不会，ios下会马上就执行。 这个已经影响业务了。请给予解决办法。 测试代码片段，荣耀magic2 坚果pro 还有其他安卓手机都有这样的问题。但是ios下正常。 图片可以看出来 我执行 close 是17:31:22   websocket执行 onclose 时是 17:31:27 延时比较明显 [图片] 经测试，当我去连接ws 的服务时，安卓端不会出现延时。只有wss 的服务时会出现这样的延时

## 问题 小程序开发，创建websocket连接来通信，通信完成便释放掉。再通信再打开。当通信到第22次/34次时，websocket的onOpen将不再触发。 测试用的微信版本为7.0.3和7.0.4，基础库版本为2.6.6。 经测试，该问题有以下特点： 1.  若出现该问题，则100%一定复现。例如A手机在第22次出现了该问题，则下次运行小程序，必然还是22次出问题。且出问题后，本次运行小程序的websocket再也无法恢复正常。 2. 清除小程序的后台进程，再次打开小程序，依然可以正常websocket通信22次。之后问题再次出现。 3. 有的是卡在第22次，有的是卡在第34次。这是在真机调试，没有打开开发者工具调试界面情况下。若使用开发者工具，开着开发者工具的调试界面，则是卡在第20/32次。 4. 与Android系统无关。目前测试出问题的手机Android系统有：Android 5.0，Android 6.0，Android 7.1.2，Android 8.1.0。 5. 与手机无关。写一个网页，使用js的websocket实现同样的逻辑。用小程序出问题的手机的浏览器打开，经测试无连接次数限制。 6. 与手机厂家无关。目前试过小米，魅族，原生谷歌系统，都出现过。 7. 与手机型号无关。有一台出问题的手机为小米Note3，测试另一台同一批次参数完全相同的小米Note3，两台都为同一版本的MIUI与Android，将两台手机的各个设置全部调为一样，一台依然是正常的，不出现该问题；另一台则100%会在第34次通信出现该问题。 8. 试过调整微信的权限，无效；试过清空微信的数据和缓存，无效；重装微信，绝大多数可以解决。有一台是谷歌原生系统7.1.2，重装也无法解决。   9. 小程序与插件都存在该问题。 ## 测试方法 定义一个变量count用于记录websocket成功连接的次数。   调用wx.connectSocket创建socketTask并暂存，在socketTask.onOpen中关闭该socketTask并令count++，在socketTask.onClose中调用wx.connectSocket来创建一个新的socketTask。重复上述步骤。 于是，只要websocket成功创建并触发onOpen，count就会+1。当该websocket成功关闭后，再重复该流程。一旦websocket没有触发onOpen，流程就会卡住。由此，当websocket卡住的时候，就可以知道已经成功建立了多少次websocket连接。 在此过程中是先关闭上次websocket完成后再开始创建下一个websocket，自始至终同一时间只有一个websocket，因此不存在超出5个websocket的问题。另外是在onOpen与onClose中执行的关闭与创建操作，所以也不存在时序问题。

预期行为： 在更新live-player组件的url属性时候 应当等待音视频流成功建立连接以后应当渲染最新的音视频数据 实际行为： 在更新live-player组件的url属性时候 等待音视频流成功建立连接以后应当渲染黑屏 日志如下： 2019/04/24 19:38:39:885: live-player id: player-129477967, code: -2302 2019/04/24 19:38:40:32: live-player id: player-129477967, code: 2001 2019/04/24 19:38:40:241: live-player id: player-129477967, code: 2002 2019/04/24 19:38:40:255: live-player id: player-129477967, code: 2007 2019/04/24 19:38:40:328: live-player id: player-129477967, code: 2004live-player 并不会渲染画面 显示的是黑屏

基于小程序live-pusher和live-player做多人视频会议。 现在在小程序端有一个需求，发送双流，即本地端既推送摄像头画面，又推送手机端content桌面画面流。 这个需求在app和pc终端很好实现。但想移植到小程序端，请问，现在小程序有支持推送双流的能力吗？ 如果有，有对应的api吗？ 如果没有，是否有评估实现？ 多谢。

- 需求的场景描述（希望解决的问题） 在使用live-player控件时，使用object-fit='contain'时，画面完整但是两侧有黑边；使用object-fit='fillCrop'时，会铺满整个组件，但是画面被裁剪，显示不完整 可以根据原始画面比例自动拉伸么？ - 希望提供的能力 live-player控件在点击全屏时，可以调整显示的画面大小么？

手机上的调试工具vConsole的层级没有其他原生组件的层级高，导致vConsole被遮挡

今天开发的时候又有客户反馈说弹窗Modal出现空白（上一次为cover-view，改为modal并没有解决问题），客户反馈回来的机型为iphone7 ios 10.2.1 基础库为2.6.2。迄今为止出现了三例这样的问题了。除开第一次没记录到ios版本外，上次cover-view弹窗全白的ios版本为10.3.3.都是版本比较低的。 还翻找了下有关低版本与小程序之间关系的历史提问。发现还是有蛮多帖子的。不知道官方有么有解决。 先前开发的时候出现过scroll-view在ios上不滚动的问题，加上固定px高度就解决了当时，就没去深究它，刚看完一些帖子也是反馈过这个问题。反馈ios是10多的。现在想想我当时遇到这个scroll-view问题的手机版本也有可能是了。 希望官方能多测试下低版本的ios手机。以及解答下我该怎么解决Modal变白这个问题。 如下： [图片]