timav: any idea if there's a way around this?

Btw, the size difference looks to be 34kb:

[ERROR:media_codec_bridge.cc(57)] Input buffer size 111492 exceeds MediaCodec input buffer capacity: 76800

I've never seen it before. I do not immediately understand from the MediaCodec API how can we set the input buffer capacity, or how it is set by the system.
Min, do you have an idea here?
It seems 112kb is not that much...

76800 is suspiciously 320*240. Which is the size we configure MediaCodec with. Will test configuring with 1080.

Looks like that's it. Configuring with 1080p gives us input buffers sized 1920*1088.

wow -- nice catch.  however, it makes little sense why they do that. :)

unclear that we want to set it at 1080p in all cases though.

As a stop-gap for M50 we could configure MC with 720p? That's ~900kb per input buffer. Anecdotally more than enough for anybody :)

Eventually we need to propogate the video config to AVDA so that we get the size on each config change.

i've plumbed coded_size_ to the vda as part of fixing 599908, which should also fix this.

Can you cc me the CL, please?

sure, added you to https://codereview.chromium.org/1869103002/ .

Nice. I didn't think this would work for MSE config changes though? i.e., an MSE stream that starts with coded size 320x240 and changes to 720p?

Good point, we should probably still set Key.MAX_INPUT_SIZE based on the same heuristics ExoPlayer is using:

https://github.com/google/ExoPlayer/blob/master/library/src/main/java/com/google/android/exoplayer/MediaCodecVideoTrackRenderer.java

We can do that in a follow up patch.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/62cf4f1fab4e0cc2560983465d3fd15fde537f00

commit 62cf4f1fab4e0cc2560983465d3fd15fde537f00
Author: liberato <liberato@chromium.org>
Date: Fri Apr 08 16:05:39 2016

Enable adaptive playback for spitzer, use conservative size.

Android MediaCodec allocates memory for adaptive playback (dynamic
resolution change) based on hints provided to the codec during
construction about the maximum expected decoded frame dimensions.
That can signficantly increate the memory usage / reduce the number
of concurrent codec instances that chrome can use.

On some devices (Samsung S3), adaptive playback also entirely breaks
decoding.  Decoded frames can be tiled / black and white / generally
quite incorrect.

Spitzer had previously turned off dynamic resolution support to fix
both of these.

However, it turns out that enabling adaptive support is necessary:

- returning unused decoded buffers to MediaCodec without rendering
can incorrectly stop MediaCodec from decoding more frames without
adaptive playback enabled.
- some videos on some devices (N7) play very slowly otherwise.

This CL requests adaptive playback when AVDA creates the MediaCodec
instance.  It also plumbs the inital coded size to AVDA, and send it
to MediaCodecBridge.  MediaCodecBridge now uses this size, rather
than 1920x1080, as the max adaptive size hint to save memory.

For devices like the S3, MediaCodecBridge ignores the request for
adaptive playback, and keeps it off.

Providing the size to MediaCodec will also allow it to choose an
appropriate input buffer size.  Previously, it used the requested
size of 320x240 when estimating the size of an encoded frame.

BUG=599908, 596211 , 601066 

Review URL: https://codereview.chromium.org/1869103002

Cr-Commit-Position: refs/heads/master@{#386091}

[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/content/common/gpu/media/android_video_decode_accelerator.cc
[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/content/common/gpu/media/android_video_decode_accelerator.h
[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java
[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java
[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/filters/gpu_video_decoder.cc
[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/gpu/ipc/common/media_param_traits_macros.h
[modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/video/video_decode_accelerator.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/264d294d945e1beaaf4734a3824addae7d5c2dda

commit 264d294d945e1beaaf4734a3824addae7d5c2dda
Author: watk <watk@chromium.org>
Date: Thu May 19 23:04:52 2016

Estimate the required MediaCodec decoder max input buffer size

In some cases MediaCodec doesn't give us input buffers that are big
enough to contain the encoded data. Now we guess at the required size
and set the KEY_MAX_INPUT_SIZE property. The heuristics come from
exoplayer.

BUG= 596211 

Review-Url: https://codereview.chromium.org/1987963004
Cr-Commit-Position: refs/heads/master@{#394894}

[modify] https://crrev.com/264d294d945e1beaaf4734a3824addae7d5c2dda/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java
[modify] https://crrev.com/264d294d945e1beaaf4734a3824addae7d5c2dda/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java