fjko

> 用的是 RS 编码，简单做了个demo，测了下部分数据然后推测的结果，如果丢包率为10%，上下行包的速度为 18000 / S，包的大小为100字节，预计只是编解码部分，CPU的占用率估计能到160%。请问这样是否正常呢？ 还是这种场景下，不应该这样使用呢。先感谢下，期待您的回复。 你好，可以把代码发出来么？我这边也想测试下你说的这个情况，谢谢

> 你好，这个可以同时推流H.264和AAC，可以参考这个 https://github.com/PHZ76/DesktopSharing 感谢回复，我这边还有个语法上的问题向你请教下： 就是addTriggerEvent 触发事件的使用场景问题，比如rtmp publish中，使用handshake完成握手。如下所示： m_taskScheduler->addTriggerEvent([this](){ m_rtmpConn->handshake(); }); 在rtsp server 代码中也使用此类触发事件完成channel 的增加和删除，但我看rtmp server代码中有的地方注释掉了addTriggerEvent，比如 //m_taskScheduler->addTriggerEvent([=]() { m_rtmpConn->sendAudioData(timestamp, payload, payloadSize); //}); 我实际注释掉了握手部分的addTriggerEvent，如下所示，也是可以运行的。并在源码中实现时是采用将回调函数压栈，然后通过lambda表达式的方式进行事件触发。貌似不压栈也可以？ //m_taskScheduler->addTriggerEvent([this](){ m_rtmpConn->handshake(); //}); 所以向你请教下，TriggerEvent使用场景是什么时候呢？为什么有的地方适合调用这个函数，有的地方不适用，需要注释掉呢？

> 暂时还未支持，正在开发中。敬请期待。 > 暂时还未支持，正在开发中。敬请期待。 期待中，同时是否需要相应的协助，版主设计好框架，剩下的交给大家来开发

> 直播需要重复调用playlist，目前点播就调用了一次。通过loadercontroller控制多次调用playlist，然后在loadData中不断更新segmentPool.剩下的流程跟点播就是都一样的了 十分感谢，哈 我先试试看，不过还是期待版主能够更新一波支持hls直播流的。

> 你好，是的，这个主要是用于唤醒EventLoop执行触发事件。在RtspServer那边通过TriggerEvent来转发音视频数据 我采用的是win调试的，未在linux进行调试， 然后采用test_echo_server.cpp进行测试的，其中EventLoop::loop()调用TaskScheduler::start()进行循环处理事件（handleTriggerEvent），调试上看，每次addTriggerEvent 事件只需要压入栈中，然后handleTriggerEvent事件时，再从栈中弹出即可，并不需要PIPE进行唤醒触发。 您说的 “用于唤醒EventLoop执行触发事件” ，可否是指调用_wakeupPipe->write时，如果不进行wake()，会卡在这里呢？还是会出现什么样的异常呢？ 对这部分很困惑，希望大佬能多多指教，谢谢了

> EventLoop的在window下使用select做IO复用, 实际上我设置了一个超时时间，所以EventLoop在没有任何事件的情况下也不会真的一直阻塞。wakeupPipe在window下使用socket模拟的，并且由select监听，所以write之后select会检测到读事件触发，如果没有进行wake读走数据, select会一直触发读事件，而且pipe的底层缓冲区也会满的，最后会造成wirte失败。 > 我也不是大佬。。。大家互相学习，交流讨论。 我按照你说的进行调试下看看，从这部分代码学到了不少知识，感谢感谢

> EventLoop的在window下使用select做IO复用, 实际上我设置了一个超时时间，所以EventLoop在没有任何事件的情况下也不会真的一直阻塞。wakeupPipe在window下使用socket模拟的，并且由select监听，所以write之后select会检测到读事件触发，如果没有进行wake读走数据, select会一直触发读事件，而且pipe的底层缓冲区也会满的，最后会造成wirte失败。 > 我也不是大佬。。。大家互相学习，交流讨论。 已经完全搞懂这部分了，再次多谢 如果有后来者看到这里，也有困惑的话，建议把延时时间调长一点，比如5秒，结合作者上面的回复，很容易看到其中的区别

> go没有类似ffmpeg的解码库，需要的话，可以用cgo的办法去调用 > 性能消耗主要在cgo的数据传递上，开销在容忍范围内 最近在调研下媒体服务，相比C++ ，go做集群太方便了。不足之处就是类似这种转码有些麻烦，有时间我试试cgo 这种开销性能怎么样，如果可以的话，后续服务要向go进行转换了。 谢谢提供的开源项目

版本信息如下，编译ffmpeg4.1 ，ffmpeg4.2 版本均有此问题。其中禁用了--disable-pthreads ，否则编译无法通过 emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.39.18 clang version 11.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 613c4a87ba9bb39d1927402f4dd4c1ef1f9a02f7) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/emscripten/emsdk/upstream/bin Found candidate GCC installation:...

> 我们用的编译代码就是github上的版本，没有额外的更改，也没有设置--disable-pthreads。 > 看emcc的版本，你的好像还要更新一些 > emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.38.45 > clang version 6.0.1 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-emscripten--core-emscripten--fastcomp--clang 98df4be387dde3e3918fa5bbb5fc43e1a0e1daac) (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-emscripten--core-emscripten--fastcomp 6c7e775325067e33fa60611e619a8b987b6d0c35) (emscripten 1.38.31 : 1.38.31) > Target: x86_64-unknown-linux-gnu...