gateslu

> For arbitrary thread pool, you can bridge them with a channel, like > > ``` > let (tx, rx) = ::futures_channel::oneshot(); > thread::spawn(move || { > sleep(10); > tx.send(());...

> > ...使用C++版本的grpc是直接支持并发请求的.. > > @gateslu can you show me a C++ version that supports concurrency and works different than the rust version? > > The code is just an...

我也遇到了类似的问题，画面会开几秒，然后到下个画面又卡几秒，而我用rtsp请求相同media，则没有这个问题 ，通过wireshark抓包分析了一下rtp包，发现webrtc发送的payload是有问题的，无法通过正常的方法解析nal的类型 常规的解析nal类型方法： uint8_t nal_type = (rtp_payload[0] & kHevcTypeMask) >> 1; 这是正常能解析rtp包的rtsp抓包  这是无法正常解析rtp包的webrtc抓包，都是一些奇怪的数值  

> 0x62的是vlc请求zlm的rtsp/h265的payload第一个字节 下面那些无规则的是请求zlm的webrtc/h265的payload第一个字节 不过我看了wiki，貌似有没提及webrtc支持h265，不知道是不是这个原因

> 浏览器已经改过了，是定制的chromium，已经支持请求265，但是收到的rtp包看着不对，无法按照正常的265解析方法解析nal type

> > 无法按照正常的 > > 怎么会不对，你不信可以rtsp播放试试 zlm中rtsp和webrtc是互通的 这个是我的问题，srtp搞错了，我再检查一下解码的代码吧，谢谢

> For people experiencing this problem, if you have SSH access to the mac in question, the `caffeinate` command can be used to wake the machine and allow RustDesk connectivity;...

字节应该给你磕一个