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.
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
