Delete EncodedImage::GetBufferPaddingBytes

For the ffmpeg H.264 decoder, rely on ffmpeg being configured with
CONFIG_SAFE_BITSTREAM_READER.

Bug: webrtc:9378
Change-Id: Ia7a46580d520808e36581252a95feeb5f9c57bf9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/119665
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27124}

modules/video_coding/codecs/h264/h264_decoder_impl.h

@@ -16,6 +16,20 @@
 
 #include "modules/video_coding/codecs/h264/include/h264.h"
 
+// CAVEAT: According to ffmpeg docs for avcodec_send_packet, ffmpeg requires a
+// few extra padding bytes after the end of input. And in addition, docs for
+// AV_INPUT_BUFFER_PADDING_SIZE says "If the first 23 bits of the additional
+// bytes are not 0, then damaged MPEG bitstreams could cause overread and
+// segfault."
+//
+// WebRTC doesn't ensure any such padding, and REQUIRES ffmpeg to be compiled
+// with CONFIG_SAFE_BITSTREAM_READER, which is intended to eliminate
+// out-of-bounds reads. ffmpeg docs doesn't say explicitly what effects this
+// flag has on the h.264 decoder or avcodec_send_packet, though, so this is in
+// some way depending on undocumented behavior. If any problems turn up, we may
+// have to add an extra copy operation, to enforce padding before buffers are
+// passed to ffmpeg.
+
 extern "C" {
 #include "third_party/ffmpeg/libavcodec/avcodec.h"
 }  // extern "C"