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. > > > 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
