alex
alex
所以, 也就是在回调中看不到flag==MPEG_FLAG_PACKET_CORRUPT? 因为断言提前触发了 Chen ***@***.***> 于2022年1月22日周六 19:13写道： > 如果发生了音频丢包就会出现MPEG_FLAG_PACKET_CORRUPT。 > > assert(pes->pkt.size == pes->len || (pkt->flags & > MPEG_FLAG_PACKET_CORRUPT)); > 这个assert两个条件，正常情况下应该是满足pes->pkt.size == pes->len，发生丢包时会pkt->flags & > MPEG_FLAG_PACKET_CORRUPT. > 当然，丢包也可能能满足第一个条件，但是长时间运行肯定会触发pkt->flags & MPEG_FLAG_PACKET_CORRUPT....
``` if(thiz->_on_decode){ if(flags & MPEG_FLAG_PACKET_CORRUPT) { WarnL
提交晚了, 没发现大佬8.0已经合并主线了, 冲突了. 另外估计也过不了ci, 因为代码是在ffmpeg5+以上, 好像ci的使用的还是4.x.
好的, 我明天做一个详细的性能测试 夏楚 ***@***.***> 于2023年4月26日周三 14:32写道： > 最好对比下性能吧 这个是高频操作。 > hls/ts这块我觉得你全权负责算了 我就不本地测试验证了 > > — > Reply to this email directly, view it on GitHub > , > or unsubscribe...
对, 所以这里是否直接断言终止了有点不合理吧? 因为有时候源方是无法控制的.
还有假设一个节目4个流, pmt->stream_count == 4 sizeof(pmt->streams) / sizeof(pmt->streams[0]) == 4 这时候就触发断言了阿
streams数组调大的确可以解决, 但是有时候是不知道track数量的, 有些流可能一个视频track带5-6个不同语言的音频track. 所以总不好streams数组调整的很大.
很难复现这个问题.是我通过日志发现的. 我也认真的阅读了您的代码, 从逻辑上看, 这些应该都属于局部变量. 也就是再次调用ts_demuxer_input应该不会再次触发才对. 但是实际上接下去会一直不停的触发. 所以我现在捕捉错误后, 按照以下流程重新创建demuxer后就不在触发了. ts_demuxer_destroy ts_demuxer_create ts_demuxer_set_notify 我现在不排除是程序其他逻辑上的问题.但是仔细检查后并没有发现有不妥的地方.
**reasons** 1. overwrites 2. add the date-time or other prefix to file name is good for manager. like slug 3. good for privacy protection, Because many files`s name is privacy
I think guys need this feature.Because many guys do not want to change local file name before upload.