[FFmpeg-devel] [PATCH] examples/muxing: zero AVPacket before av_read_frame()
andrey.krieger.utkin at gmail.com
Tue Jan 28 16:07:00 CET 2014
2014-01-28 Hendrik Leppkes <h.leppkes at gmail.com>:
> Fact remains that ->data is never read by av_read_frame, only written
> to. The API does NOT require you to init the AVPacket in any way.
> If it would, it would be smarter to actually make it clear it itself.
We don't need `data` now at all, since data is now pointed to by `buf`.
See below for av_read_frame() description in avformat.h, "If pkt->buf
is NULL, then...".
By this i consider that av_read_frame() relies on initial state of AVPacket.buf.
* Return the next frame of a stream.
* This function returns what is stored in the file, and does not validate
* that what is there are valid frames for the decoder. It will split what is
* stored in the file into frames and return one for each call. It will not
* omit invalid data between valid frames so as to give the decoder the maximum
* information possible for decoding.
* If pkt->buf is NULL, then the packet is valid until the next
* av_read_frame() or until avformat_close_input(). Otherwise the packet
* is valid indefinitely. In both cases the packet must be freed with
* av_free_packet when it is no longer needed. For video, the packet contains
* exactly one frame. For audio, it contains an integer number of frames if each
* frame has a known fixed size (e.g. PCM or ADPCM data). If the audio frames
* have a variable size (e.g. MPEG audio), then it contains one frame.
* pkt->pts, pkt->dts and pkt->duration are always set to correct
* values in AVStream.time_base units (and guessed if the format cannot
* provide them). pkt->pts can be AV_NOPTS_VALUE if the video format
* has B-frames, so it is better to rely on pkt->dts if you do not
* decompress the payload.
* @return 0 if OK, < 0 on error or end of file
int av_read_frame(AVFormatContext *s, AVPacket *pkt);
More information about the ffmpeg-devel