Fixing AudioBuffer params and channel layout bugs

media/renderers/audio_renderer_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/renderers/audio_renderer_impl.h"
 
 #include <math.h>
 #include <stddef.h>
 #include <algorithm>
 #include <utility>
@@ skipping 517 matching lines @@
 
     DCHECK(buffer_converter_);
     buffer_converter_->AddInput(buffer);
     while (buffer_converter_->HasNextBuffer()) {
       if (!splicer_->AddInput(buffer_converter_->GetNextBuffer())) {
         HandleAbortedReadOrDecodeError(AUDIO_RENDERER_ERROR_SPLICE_FAILED);
         return;
       }
     }
   } else {
+    // TODO(chcunningham, tguilbert): Figure out if we want to support implicit

[chcunningham, 2016/04/19 00:28:56]

Implicit config changes for AAC actually work with today's src= code because
ffmpeg figures figures out the implicit AAC profile when it first opens it up.
We have src= tests for the various aac files here [0]. I'm not aware of other
containers that do implicit signalling nor am I aware of anyone asking for
additional src= support. Decode error LGTM for now :)


0:
https://code.google.com/p/chromium/codesearch#chromium/src/media/test/pipelin...

[tguilbert, 2016/04/19 18:17:57]

Discussed offline. Currently, the media used to test signaling doesn't work
properly on src= playback.

+    // config changes during src=. Doing so requires resampling each individual
+    // stream which is inefficient when there are many tags in a page.
+    //
+    // Check if the buffer we received matches the expected configuration.
+    // Note: We explicitly do not check channel layout here to avoid breaking
+    // weird behavior with multichannel wav files: http://crbug.com/600538.
+    if (!buffer->end_of_stream() &&
+        (buffer->sample_rate() != audio_parameters_.sample_rate() ||
+         buffer->channel_count() != audio_parameters_.channels())) {
+      MEDIA_LOG(ERROR, media_log_)
+          << "Unsupported midstream configuration change!"
+          << " Sample Rate: " << buffer->sample_rate() << " vs "
+          << audio_parameters_.sample_rate()
+          << ", Channels: " << buffer->channel_count() << " vs "
+          << audio_parameters_.channels();
+      HandleAbortedReadOrDecodeError(PIPELINE_ERROR_DECODE);
+      return;
+    }
+
     if (!splicer_->AddInput(buffer)) {

[chcunningham, 2016/04/19 00:28:56]

IIUC, prior to adding the decode error above, we were doing a buffer overflow in
AudioBuffer::ReadFrames. I notice that method has a few DCHECKS [0] for this
scenario... What do you guys think about making them CHECKS instead? 


0:
https://code.google.com/p/chromium/codesearch#chromium/src/media/base/audio_b...

[tguilbert, 2016/04/19 18:17:56]

SGTM, but please get a second opinion :)

       HandleAbortedReadOrDecodeError(AUDIO_RENDERER_ERROR_SPLICE_FAILED);
       return;
     }
   }
 
   if (!splicer_->HasNextBuffer()) {
     AttemptRead_Locked();
     return;
   }
 
@@ skipping 332 matching lines @@
            << buffering_state;
   DCHECK_NE(buffering_state_, buffering_state);
   lock_.AssertAcquired();
   buffering_state_ = buffering_state;
 
   task_runner_->PostTask(FROM_HERE,
                          base::Bind(buffering_state_cb_, buffering_state_));
 }
 
 }  // namespace media