AadeIT

我理解您的意思。我的场景是这样的，频繁的重启解码器，接口有概率阻塞（我看官方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,...

好的，我下周先看一下是不是裸流没处理对的问题，如果还是不行的话我搞一个最小的测试代码发给您，非常感谢 🙏 另外再问一句，之前因为心跳包导致阻塞的问题，核心原因是因为 心跳包没有正常续约无法产生新的数据，接口阻塞等待。是这个逻辑吗？在 2024年11月29日，21:52，BreakingY ***@***.***> 写道： 你方便把你的main.cpp发给我吗，我下周测试一下，我没遇到过阻塞的情况 ---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 日期 | 2024年11月29日 21:42 | | 收件人 | ***@***.***> | | 抄送至 |...

@BreakingY 您好 我对比官方的example和目前仓库的代码，发现了导致阻塞的原因，在 dec_capture_loop_fcn 解码函数中，退出的条件应该是判断got_eos 而不是 m_abort [错误链接](https://github.com/BreakingY/jetpack-dec-enc/blob/674ddae6bb90ad67567399b19b76330cd2bfdce2/jetson_dec_5.0.2/JetsonDec.cpp#L396) 1. 应该由decode_proc 分析nalu时,判断是否eos，如果是eos则将队列中还没有解码的数据全部释放掉，当释放掉时，got_eos = true，这时解码函数则会在while中判断got_eos ==true 并且退出线程 2. dec_capture_loop_fcn线程应该由decode_proc 函数来创建，因为decode_proc在打开解码器时，有可能阻塞（创建时间较长）或者失败 导致dec_capture_loop_fcn 的dec的地址为0x0 3. decode_proc got_eos ==true 后，不能直接delete ctx.dec 因为dec_capture_loop_fcn 可能还在使用，需要在delete 之前，join dec_capture_loop_fcn的handle...

@BreakingY 您好，昨天因为一些事情这么晚才回复，抱歉。 关于第一点是这样子的 ，他是有eos 和 got_eos 两个变量，在decode_proc函数内，循环调用nalu 读取数据，在nalu内，根据abort来判断是否被强制结束，如果结束则设置byteused =0 表示流结束，当nalu返回后 ，在循环内会判断byteused==0 ，如果==0 则将eos 设置成true，并且退出第一个循环 [loop 1](https://github.com/BreakingY/jetpack-dec-enc/blob/674ddae6bb90ad67567399b19b76330cd2bfdce2/jetson_dec_5.0.2/JetsonDec.cpp#L538) 第二个循环逻辑类似，但是这时got_eos还是false。 在第三个循环中 [loop 3](https://github.com/BreakingY/jetpack-dec-enc/blob/674ddae6bb90ad67567399b19b76330cd2bfdce2/jetson_dec_5.0.2/JetsonDec.cpp#L608) ，先将所有的数据取出，释放并退出循环，将got_eos == true , join capture 线程， 在capture线程中，判断got_eos 则退出当前线程。（因为在写入的线程中已经将所有数据取出并释放，这时不会阻塞） ，...

@BreakingY 不好意思这么晚才回复您。 我看您的回复，现在已经修复了解码和编码的问题，我也会更新测一下，谢谢