[Libav-user] avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet) why most of the time frameFinished is zero ?
Joshua Kordani
jkordani at lsa2.com
Tue May 27 19:55:52 CEST 2014
On 5/27/14 12:21 PM, sithruk sana wrote:
> Thanks for the information. Kindly correct me if my understand is right ?
>
> 1) Packet can be of any type 'I', 'P', or 'B' that we receive from
> av_read_frame. // that ie compressed packet.
>
> 'I" frame represents the compete frame.
> 'P" frame represents the delta. it requires either previous
> 'I' or 'P' frame.
> 'B' frame depends closest preceeding or following 'I' or 'P'
> frame
>
> So, av_read_frame ( context, packet)
> - Allocates the internal memory and keeps the
> compressed packet.
>
> * NOTE: We should not free [ av_free_packet (packet) ] if we are
> using shallow copy of 'packet' . For instance
> *
> * keeping this pointer in the AVPacketList to push
> into decoding thread.
> *
>
> 2) Whatever the frame we get we send it to avcodec_decode_video2
> (... frameFinished, packet);
> -> This API keeps internally the previous frames required to
> decode. if it has sufficient packet to decode,
> it decodes, and sends back saying "You got complete picture".
>
>
> Kindly correct me if i am wrong?
I can't comment on the veracity of Question 1, if the returned packets
are of those types, but when I feed avcodec_decode_video2 by hand, with
my own nalu data, I feed it an entire buffer of IPPPP packets, and get a
frame in return.
So for Question 2, I have been told that the decoder used to be such
that you could feed it packets one at a time, I then P then P then P and
eventually it would signal that it has a new frame, but in current
versions of the code this behavior is no longer the default, requires
special setup steps to be performed, and may not always work anymore.
That is, if I understand your questions correctly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140527/587ef6f6/attachment.html>
More information about the Libav-user
mailing list