+servolk to comment on the impact on chromecast.

servolk@: The plan is to rip bitstream conversion out of the Demuxer and apply it later (DecoderStream if necessary, perhaps in the actual Decoders where possible). How can we coordinate this change with Chromecast?

Since we only really care about GpuVideoDecoder for now, we can implement a fix there and not change any APIs for an interim period.

Yes, we can move the bitstream conversion from the Demuxer to Chromecast media pipeline (not to be confused with media::Pipeline/media::PipelineImpl) or Chromecast video decoder backends.

 Issue 632101  has been merged into this issue.

FFmpegVideoDecoder can decode bitstream-converted streams just fine, as long as it knows they have been converted already. I'm testing a small patch that should enable that.

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

commit e4041392035ece38d99818ea1bbe8f912a27a19e
Author: sandersd <sandersd@chromium.org>
Date: Wed Oct 26 19:49:26 2016

FFmpegDemuxer: Clear |extra_data| when enabling bitstream conversion.

After this change, fallback from GpuVideoDecoder to FFmpegVideoDecoder
should work. The exact mechanism is perhaps surprising:

  - After successfully initializing GpuVideoDecoder, bitstream
    conversion is enabled. We can't easily turn it off again when we
    fall back.

  - FFmpegVideoDecoder can decode a converted bitstream, but only if it
    knows the conversion has occurred. It checks for the presence of an
    AVCC record in |extra_data| to deduce the bitstream format.

  - Clearing |extra_data| is reasonable, because the AVCC record serves
    no purpose for an Annex B stream. (Note: the MSE path doesn't
    provide |exta_data| at all.)

  - Converting |extra_data| into a different format (eg. SPS + PPS
    concatenated in Annex B format) would be logical, but currently
    would serve no purpose (in particular because the conversion would
    happen after Initialize()).

  - The result then is that |extra_data| is cleared after initializing
    GpuVideoDecoder. Upon fallback, FFmpegVideoDecoder will interpret
    the alread-converted bitstream correctly. GpuVideoDecoder still
    receives |extra_data|, and on Android actually makes uses of it.

  - Note that if GpuVideoDecoder is not initialized successfully, then
    bitstream conversion is never enabled and FFmpegVideoDecoder works
    exactly as it did before (with |extra_data| passed in the codec
    context).

BUG= 605790 

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

[modify] https://crrev.com/e4041392035ece38d99818ea1bbe8f912a27a19e/media/base/video_decoder_config.cc
[modify] https://crrev.com/e4041392035ece38d99818ea1bbe8f912a27a19e/media/base/video_decoder_config.h
[modify] https://crrev.com/e4041392035ece38d99818ea1bbe8f912a27a19e/media/filters/ffmpeg_demuxer.cc
[modify] https://crrev.com/e4041392035ece38d99818ea1bbe8f912a27a19e/media/test/pipeline_integration_test.cc
[modify] https://crrev.com/e4041392035ece38d99818ea1bbe8f912a27a19e/media/test/pipeline_integration_test_base.cc
[modify] https://crrev.com/e4041392035ece38d99818ea1bbe8f912a27a19e/media/test/pipeline_integration_test_base.h