Avoid unnecessary post task during frame delivery.

media/base/video_decoder.h

Index: media/base/video_decoder.h
diff --git a/media/base/video_decoder.h b/media/base/video_decoder.h
index d6abf03e175355e66e1d67962eec16d8311be8cf..782342b2968193eedd62d19cecd54b74b8bf2947 100644
--- a/media/base/video_decoder.h
+++ b/media/base/video_decoder.h
@@ -65,6 +65,9 @@ class MEDIA_EXPORT VideoDecoder {
   //    Upon reinitialization, all internal buffered frames will be dropped.
   // 2) This method should not be called during pending decode or reset.
   // 3) No VideoDecoder calls should be made before |init_cb| is executed.
+  // 4) VideoDecoders should take care to run |output_cb| as soon as the frame
+  // is ready (i.e. w/o thread trampolining) since it can strongly affect frame
+  // delivery times with high-frame-rate material.

[xhwang, 2016/04/25 21:15:55]

We typically expect callbacks (including the output_cb) to be fired
asynchronously, to avoid reentrancy issues, e.g.

Decode() -> DecodeBuffer() -> output_cb.Run()

Looking at DecoderStream, this may be okay. But it will definitely make our
callstack more complicated. So I wonder how much performance gain does this buy
us? Could you please make it more clear, here and in DecoderStream, that this
means output_cb.Run() could be fired in the same call stack as Decode()?

[DaleCurtis, 2016/04/25 21:31:44]

This definitely buys us a lot of performance gain in the case of
GpuVideoDecoder, i.e. w/o this fix we're unable to play 720p60 content without
constantly underflowing.

[DaleCurtis, 2016/04/25 22:32:22]

Done. Fixed the existing comment too which wasn't true.

   virtual void Initialize(const VideoDecoderConfig& config,
                           bool low_delay,
                           CdmContext* cdm_context,