[FFmpeg-devel] QSV Decoding - Issues and Regressions
h.leppkes at gmail.com
Mon Aug 3 21:37:24 CEST 2015
On Mon, Aug 3, 2015 at 9:33 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Mon, 3 Aug 2015 22:25:20 +0300
> Ivan Uskov <ivan.uskov at 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
>> 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
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 at ffmpeg.org
More information about the ffmpeg-devel