[FFmpeg-devel] QSV Decoding - Issues and Regressions

[Ivan Uskov]

Hello Hendrik,

Thank you very much for the bugreport, I believe I will able to fix all these issues
quick.
In general all these issues are known and in my todo list.


Monday, August 3, 2015, 3:18:04 PM, you wrote:

HL> Hey,

HL> after a discussion on IRC about the declining quality of the QSV
HL> decoders, I decided to do actual tests and document the results, so we
HL> can get these fixed.

HL> A lot of these issues are regressions from recent changes, and work
HL> fine in the original qsv decoders merged from libav, so they should be
HL> given extra attention.

HL> 1)
HL> Content with frame size changes is not handled at all.
HL> A change to a smaller frame size will result in image corruption, and
HL> a change to a bigger frame size will cause decoding to fail entirely.

HL> Sample (large to small):
HL> http://fate-suite.ffmpeg.org/h264/reinit-large_420_8-to-small_420_8.h264

HL> In this case, as hardware buffers are re-used, the images after the
HL> change to a smaller size result in showing parts of the old image and
HL> the new smaller image in the top left corner instead.

HL> 2)
HL> Seeking is broken. For some reason refactoring of the qsv decoders has
HL> resulted in their flush functions to become void. Seeking using ffplay
HL> and the qsv decoder results in serious playback disruption.

HL> 3)
HL> AV_PIX_FMT_QSV output is no longer functional. Refactoring has removed
HL> the ff_get_format call, which results in API users no longer being
HL> able to select the QSV pix fmt.

HL> These 3 issues are regression from the original decoder, and should be
HL> corrected before further decoders are merged. As additional code using
HL> the common qsv may require further changes in the future, its best to
HL> fix the common code before adding even more.

HL> I'll make sure to review future qsv patches more actively to hopefully
HL> avoid big regressions like these in the future as well. I have a
HL> system setup now to test qsv, so that should be easier in the future.

HL> - Hendrik



-- 
Best regards,
 Ivan                            mailto:ivan.uskov at nablet.com