[FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.
michael at niedermayer.cc
Fri Jul 24 00:16:29 CEST 2015
On Fri, Jul 24, 2015 at 12:23:04AM +0300, Ivan Uskov wrote:
> 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
> 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,
> 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.
thanks for explaining
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel