-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
调用MPP解码,帧数不完全/不确定 #690
Comments
像 mpi_dec_test 里一样把 eos 在最后一包码流上做标记,然后要输出端一直要取到带 eos 标记的帧再退出。 |
谢谢你的解答。我尝试直接封装的mpi_dec_test的实现,仅改写reader slot那块,按照4096的大小将码流送入解码器;日志中也确实看到,get frame eos为true了;但是获得的总帧数并不一致,解码得到的图片,也与原始demo的,有部分图片哈希值不一样。这可能是哪些原因呢?在码流最终输入解码器的地方,我dump了数据,demo/我的实现,原始给到解码器的输入是一致的 |
按 4096 固定大小其实是不太好的,最好外部做个分帧,这样一次输入就是一帧的码流,这样解码器可以不用做内部分帧 |
因为mpi_dec_test的demo本身,是可以完整的解出所有帧的;我现在以demo为基准做测试,所以输入也跟demo一样按4096输入。我封装后,图像本身看起来并没有问题,只是与demo中相同索引的帧,不一致(也不是全部都不一致,有部分帧是完全一致的)。解码器的cache怎么关呢?没看到具体示例;eos是标记在最后一包的,日志中看到了set eos时,size不足4096 |
解码输出顺序不同? 解码器 cache 问题可以试下把 mpp_buffer_impl.cpp 里的 mpi_dec_test 里应该是有配置 packet eos 和 判断 frame 的 eos 流程 Line 207 in 4a71a39
|
把这两行注释掉,顺序解码时确实匹配上了;我的H264流中只有I帧跟P帧,设计了一个跳帧逻辑,即一段码流,指定跳到某帧时,先解码离他最近的I帧,再顺序解码到这一帧;但是从结果上看,即使是I帧,也并不是所有I帧都能完全匹配上;这可能是什么原因呢?我的理解上来看,当一个新的I帧码流给到解码器,解码器得到的应该是完全符合预期的,因为I帧不依赖其他帧 |
参考demo示例中mpi_dec_test,将mpp解码集成到自己的项目中;示例中是静态链接的,我的项目中是动态链接的,除此以外调用逻辑没有区别;但是我的实现,始终会出现视频流最后几帧图片不能够被解码,始终死循环;对于不同视频用例,不能解码的帧数不一样,有的可能是10帧,有的可能是3帧,或者全部可以解码。
这样的问题可能是什么原因呢?我也尝试过静态链接,这样的问题似乎就没有出现了,烦请分享你的看法,谢谢~
The text was updated successfully, but these errors were encountered: