On Mon, Aug 3, 2015 at 9:33 PM, wm4 <nfx...@googlemail.com> wrote: > On Mon, 3 Aug 2015 22:25:20 +0300 > Ivan Uskov <ivan.us...@nablet.com> wrote: > >> Hello Michael, Hendrik, >> >> I would like to make sure about following moment regarding handling of >> sequence header changing. The decoder has buffering of decoded frames, >> so when new frame dimensions are detected we can not just reset >> decoder, we should to deffer re-init and switch decoder to some >> "flushing" state and still deliver "old" frames until buffer will >> empty. >> Main issue that upstream still deliver new packets at this time. I >> tried to return 0 from ff_qsv_decode() to indicate that packet not >> consumed at all and should be re-send later but upstream does not >> understand this at least if I return non-zero 'got_frame' flag and >> decoded frame. > > Video packets are always fully consumed. Yes, this can be a problem for > such APIs. But currently we don't have anything better. This was > extensively discussed, and the best fix would be a new API, which won't > happen within near time. > > So you have to deal with this situation. > >> Looks like decoder should to buffer income packets at at flushing >> state. Else decoder loses first gop after new sequence header detected. >> Is it acceptable way? Any other alternatives. By my private opinion it >> would be much better if upstream did not try to push new packet if 0 >> was returned from decoder together with decoded frame. >> >> By the way, about old implementation which "worked fine". >> It just did drop all buffered frames at decoder re-init on new >> sequence header, there is nice comment inside old qsvdec_h264.c: >> /* TODO: flush delayed frames on reinit */ >> >> Of course, I can provide same behavior for first time but it very ugly >> solution. > > I was under the impression that the original Libav code handled this > correctly.
It looks like the libav code drops all buffered frames in this case, which is still better than not doing anything at all - but of course nowhere near perfect. > >> >> >> Monday, August 3, 2015, 3:44:17 PM, you wrote: >> >> [...] >> MN> thanks, ill leave qsv review & patch apply to you. >> MN> I had until recently not even a setup to build qsv as the stuff didnt >> MN> like my main development box. And still dont have a setup to runtime >> MN> test, just to build. > > Don't top-post, fix your email client to use standard quote marks. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
