[FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.

[Ivan Uskov]

Hello Michael,

Thursday, July 23, 2015, 11:47:28 PM, you wrote:
>> For several test streams I'm observing that 2-3 bytes copying appear
>> only at begin of decoding, for first 5-10 frames.

MN> what are these additional bytes?
MN> why are they not consumed ?

At least for h.264 looks like absolutely arbitrary data at access unit
end. I.e. it is not zero padding or annex-b prefixes.
In general intel QSV decoder are stream-based and does guarantee
complete edit unit consumption by itself.
The quote from Intel's documentation directly says following about
MFXVideoDECODE_DecodeFrameAsync:
========
<...>
The input bitstream bs can be of any size. If there are not enough
bits to decode a frame, the function returns MFX_ERR_MORE_DATA, and
consumes all input bits except if a partial start code or sequence
header is at the end of the buffer. In this case,
*the_function_leaves_the_last_few_bytes_in_the_bitstream_buffer*.
If there is more incoming bitstream, the_application_should_append the
incoming bitstream to the bitstream buffer.
<...>
========
I.e. in general case we should be always ready that "few bytes" of
packet can be not consumed by decoder and it is necessary to join this
data with next packet at next time.


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