[FFmpeg-devel] QSV Decoding - Issues and Regressions
Ronald S. Bultje
rsbultje at gmail.com
Tue Aug 4 04:24:45 CEST 2015
On Mon, Aug 3, 2015 at 4:50 PM, Ivan Uskov <ivan.uskov at nablet.com> wrote:
> Hello Ronald,
> Monday, August 3, 2015, 11:37:22 PM, you wrote:
> RSB> On Mon, Aug 3, 2015 at 3:25 PM, Ivan Uskov <ivan.uskov at nablet.com>
> >> 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 */
> RSB> Each AVCodec has a flush function which should do this. So as you
> RSB> suggested, you need a flushing state which means you will output "old"
> RSB> frames while consuming new frames and caching them internally in some
> RSB> Then, when the decoder is flushed (either because flush was called, or
> RSB> because all old cached frames have been returned), you can use all
> RSB> packets to reinit the hw and start outputing frames right away.
> Thank you for suggestion but unfortunately AVCodec::flush is useless
> for this issue. The AVCodec::flush intended to *drop* decoded frames
> and reset decoder before seeking and it calls by module outside of decoder.
> My task is keep all frames without losing and decoder initiates
> "flushing" by itself. So it is different kind of "flush".
That's exactly what I said, I think you misunderstood.
Libav's decoder handles AVCodec.flush inside the size-change function. What
I'm saying is to make it a state machine and move that code to
AVCodec.flush (if it's not there already), and otherwise (as part of your
state machine) buffer incoming patches after a size change until all
previous-sized packets have been processed.
Then, N new-sized frames later, you'll have N packets buffered, you can
input them into the decoder all at once and immediately start outputing
frames of the new size without additional delay except for the hw reinit.
More information about the ffmpeg-devel