Added EncodedImage::GetBufferPaddingBytes.

webrtc/modules/video_coding/codecs/h264/h264.cc

Index: webrtc/modules/video_coding/codecs/h264/h264.cc
diff --git a/webrtc/modules/video_coding/codecs/h264/h264.cc b/webrtc/modules/video_coding/codecs/h264/h264.cc
index 645ed2cad7af3bdf99643ee0fc5972a20e0b96d8..2b86977a3a8682b178a8c0f500e9e8cd1eaa2f79 100644
--- a/webrtc/modules/video_coding/codecs/h264/h264.cc
+++ b/webrtc/modules/video_coding/codecs/h264/h264.cc
@@ -20,6 +20,10 @@
 
 namespace webrtc {
 
+// TODO(hbos): The FFmpeg video decoder will require up to 8 bytes, update this
+// when the FFmpeg decoder is added.

[stefan-webrtc, 2016/01/19 15:06:20]

Should we also file a bug to the ffmpeg project? Seems like something they
should be able to fix.

[hbos, 2016/01/19 16:50:34]

It is documented in their source code
(https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...)
so they already know about it. Think I should create a bug anyway?

[stefan-webrtc, 2016/01/21 10:34:47]

I think we should at least ask whether they would consider fixing it. I don't
see any reason why it should behave in this way, as they can read the whole
frame except the end as chunks of 64 bits. I'd be surprised if that would end up
being a performance issue.

[hbos, 2016/01/21 11:17:26]

Agreed, I created a ticket (https://trac.ffmpeg.org/ticket/5176).

Got a reply: "[...] if we wouldn't have padding we would have to check every
time if we're at the end of the buffer [...] Don't expect any changes, this is a
clear design decision."

+const size_t kEncodedImagePaddingH264 = 0;
+
 // We need this file to be C++ only so it will compile properly for all
 // platforms. In order to write ObjC specific implementations we use private
 // externs. This function is defined in h264.mm.