Fixing bug that 8bit PCM stream is gabbled...

Fixing bug that 8bit PCM stream is gabbled
The CodecContext passed into FFmpegAudioDecoder by
the FFmpegDemuxer says the output samples are 16bits.
So we tell the audio renderer to create a 16bits
audio output stream. But after the decoder is allocated
by avcodec_find_codec, the sample bits information in
|codec_context_| is changed to 8bit! So we are feeding
16bits output stream with 8bits data.

The decoder should knows more about the actual output
format. So query the sample bits information after
the decoder is allocated.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=18406

[Alpha Left Google, 2009-06-12 00:53:57]

Swapping orders of getting the sample bits/rate values from the decoder. This is
to kick start the discussion and I believe there are more boundary cases... like
when I play a 24 PCM data file, after the decoder is opened, |codec_context_|
says the output format is 32bits..

[scherkus (not reviewing), 2009-06-15 17:40:04]

LGTM after fixing ntis (and don't forget to merge with ToT!)

http://codereview.chromium.org/125027/diff/1/2
File media/filters/ffmpeg_audio_decoder.cc (right):

http://codereview.chromium.org/125027/diff/1/2#newcode52
Line 52: // By doing avcodec_find_decoder(), |codec_context_| maybe altered by
the
nits:
"By doing" -> "When calling"
"maybe" -> "might be"

[Alpha Left Google, 2009-06-15 18:16:58]

On 2009/06/15 17:40:04, scherkus wrote:
> LGTM after fixing ntis (and don't forget to merge with ToT!)
> 
> http://codereview.chromium.org/125027/diff/1/2
> File media/filters/ffmpeg_audio_decoder.cc (right):
> 
> http://codereview.chromium.org/125027/diff/1/2#newcode52
> Line 52: // By doing avcodec_find_decoder(), |codec_context_| maybe altered by
> the
> nits:
> "By doing" -> "When calling"
> "maybe" -> "might be"

Issues addressed.