BreakingY
v4l2_ioctl卡死
你好，我用demo拉取海康H265视频流进行解码，程序总会在正常运行20s左右卡死在NvV4l2ElementPlane::dqBuffer的v4l2_ioctl上，用select对文件句柄进行监控也无法解决，请问是否有解决的办法，谢谢
感谢您的回复，我们不止rtsp 还有很多其他的流媒体格式，所以希望通过接入ffmpeg 来获取264或者265的裸流支持更多的格式。您说已经解决这个问题，是更换rtspclient的方式解决，还是修改了调用方式解决的？ 在 2024年11月29日，19:01，BreakingY @.***> 写道： 每个摄像头都new一个RtspClientProxy就行了啊，用项目里的rtsp client是有什么问题吗，阻塞的问题我已经解决了
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
好的，那我这样理解是否可以， 不正常或者异常的裸数据会导致 v4l2接口阻塞？ 只要保持数据的正确性，接口就不会阻塞 在 2024年11月29日，19:40，BreakingY @.***> 写道： 之前rtsp client处理心跳包有问题，已经修复，如果你想用ffmpeg接入摄像头，得需要改一下，我没用ffmpeg接入过摄像头
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
我理解您的意思。我的场景是这样的，频繁的重启解码器，接口有概率阻塞（我看官方api说这是阻塞函数），例如我调用析构函数关闭解码器 abort为true 时，队列里面有10个数据，我循环取出并释放（这个接口的功能），正常是循环十次然后数据长度为0跳出循环，但是我的是循环长度为1时 最后一次调用释放接口则阻塞 ，长度按照 9 8 7 6 5 4 3 2 1 阻塞的顺序，我有没有办法让这个1不阻塞，正常的去释放这个buffer ，并不会每次都触发而是小概率的 在 2024年11月29日，21:31，BreakingY @.***> 写道： 是这样的，v4l2阻塞不是问题，也不是bug，没有数据，程序肯定就暂停了啊，是正常的
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
你方便把你的main.cpp发给我吗，我下周测试一下，我没遇到过阻塞的情况
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2024年11月29日 21:42 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [BreakingY/jetpack-dec-enc] v4l2_ioctl卡死 (Issue #3) |
我理解您的意思。我的场景是这样的，频繁的重启解码器，接口有概率阻塞（我看官方api说这是阻塞函数），例如我调用析构函数关闭解码器 abort为true 时，队列里面有10个数据，我循环取出并释放（这个接口的功能），正常是循环十次然后数据长度为0跳出循环，但是我的是循环长度为1时 最后一次调用释放接口则阻塞 ，长度按照 9 8 7 6 5 4 3 2 1 阻塞的顺序，我有没有办法让这个1不阻塞，正常的去释放这个buffer ，并不会每次都触发而是小概率的 在 2024年11月29日，21:31，BreakingY @.***> 写道： 是这样的，v4l2阻塞不是问题，也不是bug，没有数据，程序肯定就暂停了啊，是正常的
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
好的，我下周先看一下是不是裸流没处理对的问题，如果还是不行的话我搞一个最小的测试代码发给您，非常感谢 🙏 另外再问一句，之前因为心跳包导致阻塞的问题，核心原因是因为 心跳包没有正常续约无法产生新的数据，接口阻塞等待。是这个逻辑吗？在 2024年11月29日，21:52，BreakingY @.***> 写道： 你方便把你的main.cpp发给我吗，我下周测试一下，我没遇到过阻塞的情况
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2024年11月29日 21:42 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [BreakingY/jetpack-dec-enc] v4l2_ioctl卡死 (Issue #3) |
我理解您的意思。我的场景是这样的，频繁的重启解码器，接口有概率阻塞（我看官方api说这是阻塞函数），例如我调用析构函数关闭解码器 abort为true 时，队列里面有10个数据，我循环取出并释放（这个接口的功能），正常是循环十次然后数据长度为0跳出循环，但是我的是循环长度为1时 最后一次调用释放接口则阻塞 ，长度按照 9 8 7 6 5 4 3 2 1 阻塞的顺序，我有没有办法让这个1不阻塞，正常的去释放这个buffer ，并不会每次都触发而是小概率的 在 2024年11月29日，21:31，BreakingY @.***> 写道： 是这样的，v4l2阻塞不是问题，也不是bug，没有数据，程序肯定就暂停了啊，是正常的
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
是的
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2024年11月29日 22:04 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [BreakingY/jetpack-dec-enc] v4l2_ioctl卡死 (Issue #3) |
好的，我下周先看一下是不是裸流没处理对的问题，如果还是不行的话我搞一个最小的测试代码发给您，非常感谢 🙏 另外再问一句，之前因为心跳包导致阻塞的问题，核心原因是因为 心跳包没有正常续约无法产生新的数据，接口阻塞等待。是这个逻辑吗？在 2024年11月29日，21:52，BreakingY @.***> 写道： 你方便把你的main.cpp发给我吗，我下周测试一下，我没遇到过阻塞的情况
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2024年11月29日 21:42 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [BreakingY/jetpack-dec-enc] v4l2_ioctl卡死 (Issue #3) |
我理解您的意思。我的场景是这样的，频繁的重启解码器，接口有概率阻塞（我看官方api说这是阻塞函数），例如我调用析构函数关闭解码器 abort为true 时，队列里面有10个数据，我循环取出并释放（这个接口的功能），正常是循环十次然后数据长度为0跳出循环，但是我的是循环长度为1时 最后一次调用释放接口则阻塞 ，长度按照 9 8 7 6 5 4 3 2 1 阻塞的顺序，我有没有办法让这个1不阻塞，正常的去释放这个buffer ，并不会每次都触发而是小概率的 在 2024年11月29日，21:31，BreakingY @.***> 写道： 是这样的，v4l2阻塞不是问题，也不是bug，没有数据，程序肯定就暂停了啊，是正常的
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
@BreakingY 您好
我对比官方的example和目前仓库的代码，发现了导致阻塞的原因，在 dec_capture_loop_fcn 解码函数中，退出的条件应该是判断got_eos 而不是 m_abort 错误链接
- 应该由decode_proc 分析nalu时,判断是否eos，如果是eos则将队列中还没有解码的数据全部释放掉，当释放掉时，got_eos = true，这时解码函数则会在while中判断got_eos ==true 并且退出线程
- dec_capture_loop_fcn线程应该由decode_proc 函数来创建，因为decode_proc在打开解码器时，有可能阻塞（创建时间较长）或者失败 导致dec_capture_loop_fcn 的dec的地址为0x0
- decode_proc got_eos ==true 后，不能直接delete ctx.dec 因为dec_capture_loop_fcn 可能还在使用，需要在delete 之前，join dec_capture_loop_fcn的handle ，这样修改完后，目前重启1000 次没有任何阻塞，没有任何崩溃，以上三步，少修改任何一步，则会阻塞或者使用空指针
另外不断重启enc也会有问题，EncPollThread线程会有概率不退出阻塞在 wait code 原因是退出时，可能会没有唤醒这部分的等待 ，需要在sem_destroy(&ctx.pollthread_sema);前，先sem_post(&ctx.pollthread_sema);唤醒等待
不知您是否认同我的观点，如果可以我将提交一个PR来修复这部分问题
第1点：这个项目要从摄像头实时流中拉取视频，也就是视频流永远不会断，所以分析nalu的时候不会出现eos的情况，就算没有视频数据，也要等待数据到来，不能把got_eos 设置为true，用m_abort的目的就是为了强制结束解码，官网的demo是判断文件读取完毕之后就设置got_eos ==true，和这个项目的场景不一样。我就是把原来demo中的got_eos用m_abort替换掉 第2点：创建完dec_capture_loop_fcn 线程，我会判断self->proc_ready，如果解码器没有初始化好，dec_capture_loop_fcn 线程会一直阻塞。不会出现dec的地址为0x0的情况 第3点：确实会有你说的问题。 我看来第1点不应该改，第2点和第3点可以按照你说的改 你可以在测试一下第1点，或者我们在讨论一下，然后你提一个PR 还有你说的Enc编码阻塞，我也发现这个问题了，还没来得及修复，你PR一起提给我把
@BreakingY 您好，昨天因为一些事情这么晚才回复，抱歉。
关于第一点是这样子的 ，他是有eos 和 got_eos 两个变量，在decode_proc函数内，循环调用nalu 读取数据，在nalu内，根据abort来判断是否被强制结束，如果结束则设置byteused =0 表示流结束，当nalu返回后 ，在循环内会判断byteused==0 ，如果==0 则将eos 设置成true，并且退出第一个循环 loop 1 第二个循环逻辑类似，但是这时got_eos还是false。
在第三个循环中 loop 3 ，先将所有的数据取出，释放并退出循环，将got_eos == true , join capture 线程， 在capture线程中，判断got_eos 则退出当前线程。（因为在写入的线程中已经将所有数据取出并释放，这时不会阻塞） ， join结束后，退出 decode_proc线程。
这个逻辑跟读文件或者读视频流没有关系， 读取nalu，以nalu返回bytesused ==0 为结束，结束后退出写入循环，进入读取循环，读取所有已经添加的数据并释放，再通知并且等待解码线程退出 。
如果不按照这个逻辑，有可能解码线程退出后，decode_proc 再去取数据会阻塞。 我使用mp4测试 ，也会有这个问题，按照 五秒打开 五秒关闭的顺序不断循环
@AadeIT 关于解码的部分我已经按照你的建议修改更新了，对于EncPollThread问题，我测试了一下，在sem_destroy(&ctx.pollthread_sema);前调用sem_post(&ctx.pollthread_sema)会报错，我在video_encode_main.cpp中不断的重启编码器也没有复现阻塞的问题。
更新一下：delete编码器的时候，如果队列里面还有数据会出问题，在delete前需要通过test->GetQueueSize()判断队列中是否还有数据，没有数据delete才不会出问题。不知道你遇到的阻塞是不是这个原因导致的
再更新一下：JetsonEnc和之前解码的问题一样，我的释放有问题，已修复