[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