[FFmpeg-devel] [PATCH] examples/muxing: zero AVPacket before av_read_frame()

[Andrey Utkin]

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);

-- 
Andrey Utkin