[FFmpeg-devel] QSV Decoding - Issues and Regressions

[Hendrik Leppkes]

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
>> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel