Log codec IDs for MediaSource content.

Log codec IDs for MediaSource content.

This adds code to log the audio & video codec IDs to chrome:media-internals
so that content providers can easily see what codec ID's they should be
using for their content. A message was also added to warn people about
what they need to do with implicitly signalled HE-AAC content.

BUG=370927
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=269221

[scherkus (not reviewing), 2014-05-07 20:25:53]

OOC does your feedback you gave me in https://codereview.chromium.org/76483005/
apply here? I see a fair bit of plumbing of a LogCB...

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
media/filters/ffmpeg_audio_decoder.cc:360: MEDIA_LOG(log_cb_) << "Implicit
HE-AAC signalling is being used."
should this be moved closer to MSE code instead of being inside of the decoder?

[acolwell GONE FROM CHROMIUM, 2014-05-07 20:47:44]

On 2014/05/07 20:25:53, scherkus wrote:
> OOC does your feedback you gave me in
https://codereview.chromium.org/76483005/
> apply here? I see a fair bit of plumbing of a LogCB...

The information I'm providing here is more detailed than what you have in that
CL. It basically tells you exactly what should be specified in the mimetype for
addSourceBuffer() based on information provided in the bytestream. It doesn't
clarify which SourceBuffer this info is associated with, but I don't think that
is a huge deal right now.

I don't remember the exact context of my original comments, but I think my
primary concern was that if we just cared about what codecs were actually
selected, we should just track that in pipeline instead of in the ChunkDemuxer
code. I could see your CL being modified to use log_cb to capture what type &
codecs the user actually passed to addSourceBuffer(). That might actually
compliment this CLs since it would show what was provided, AND what should have
been provided.

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
media/filters/ffmpeg_audio_decoder.cc:360: MEDIA_LOG(log_cb_) << "Implicit
HE-AAC signalling is being used."
On 2014/05/07 20:25:53, scherkus wrote:
> should this be moved closer to MSE code instead of being inside of the
decoder?

We can't. Implict signalling of HE-AAC can only be detected by decoding the
packet. All the info in the header looks like AAC-LC. The only way to tell that
it is HE-AAC is to decode the AAC-LC data and notice that some HE-AAC follows
it. This is a backwards compatibility "feature". 

The REAL fix here is to defer audio device initialization until after the first
frame is decoded, but that is a non-trivial change. This is a stopgap measure to
help people understand what to do until we actually make the hard change.

[scherkus (not reviewing), 2014-05-08 00:26:14]

lgtm w/ nit

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
media/filters/ffmpeg_audio_decoder.cc:359: av_frame_->sample_rate == 2 *
config_.samples_per_second()) {
nit: it's funny you put the ()'s around the simple comparison to kCodecAAC but
not the 2 * config_.samples_per_second() bit :)

[acolwell GONE FROM CHROMIUM, 2014-05-08 00:57:01]

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/276503002/diff/1/media/filters/ffmpeg_audio_d...
media/filters/ffmpeg_audio_decoder.cc:359: av_frame_->sample_rate == 2 *
config_.samples_per_second()) {
On 2014/05/08 00:26:14, scherkus wrote:
> nit: it's funny you put the ()'s around the simple comparison to kCodecAAC but
> not the 2 * config_.samples_per_second() bit :)
Yeah. Not sure why I did that. () removed.

[acolwell GONE FROM CHROMIUM, 2014-05-08 00:57:04]

The CQ bit was checked by acolwell@chromium.org

[commit-bot: I haz the power, 2014-05-08 00:59:05]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/acolwell@chromium.org/276503002/20001

[commit-bot: I haz the power, 2014-05-08 06:04:57]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
  linux_chromium_chromeos_rel on tryserver.chromium
  linux_chromium_clang_dbg on tryserver.chromium
  linux_chromium_rel on tryserver.chromium

[commit-bot: I haz the power, 2014-05-08 06:33:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-08 06:33:57]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel on tryserver.chromium
  linux_chromium_rel on tryserver.chromium

[acolwell GONE FROM CHROMIUM, 2014-05-08 15:26:57]

The CQ bit was checked by acolwell@chromium.org

[commit-bot: I haz the power, 2014-05-08 15:30:46]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/acolwell@chromium.org/276503002/40001

[commit-bot: I haz the power, 2014-05-09 11:07:27]

Change committed as 269221