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 > 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.
ok, understand 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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
