does av_read_frame add FF_INPUT_BUFFER_PADDING_SIZE?

Question

I'm using libav to read an MPEG stream.
I'm using the function av_read_frame() to read some frames into packets:

av_read_frame(pFormatCtx, &packet)

I then use the function avcodec_decode_video2 to decode the packet into frame.
the documentation of the function avcodec_decode_video2 contains the following warning:

The input buffer must be FF_INPUT_BUFFER_PADDING_SIZE larger than the actual read bytes because some optimized bitstream readers read 32 or 64 bits at once and could read over the end. The end of the input buffer buf should be set to 0 to ensure that no overreading happens for damaged MPEG streams.

I wanted to know if the function av_read_frame doesn't already allocate the additional FF_INPUT_BUFFER_PADDING_SIZE?

Thank you.

Answer 1

Yes, av_read_frame() always adds FF_INPUT_BUFFER_PADDING_SIZE for you. You only need to care about that if you use your own demuxed data as input to avcodec_decode_video2(), eg if you write your own demuxers (like what VLC or mplayer do).