Use decoder's timestamp instead of the timestamp from AU during prerolling

media/base/android/media_decoder_job.cc

 // Copyright 2013 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/base/android/media_decoder_job.h"
 
 #include "base/bind.h"
 #include "base/callback_helpers.h"
 #include "base/debug/trace_event.h"
 #include "base/message_loop/message_loop_proxy.h"
@@ skipping 332 matching lines @@
     callback.Run(status, kNoTimestamp(), 0);
     return;
   }
 
   // TODO(xhwang/qinmin): This logic is correct but strange. Clean it up.
   if (output_eos_encountered_)
     status = MEDIA_CODEC_OUTPUT_END_OF_STREAM;
   else if (input_status == MEDIA_CODEC_INPUT_END_OF_STREAM)
     status = MEDIA_CODEC_INPUT_END_OF_STREAM;
 
-  // Check whether we need to render the output.
-  // TODO(qinmin): comparing most recently queued input's |unit.timestamp| with
-  // |preroll_timestamp_| is not accurate due to data reordering and possible
-  // input queueing without immediate dequeue when |input_status| !=
-  // |MEDIA_CODEC_OK|. Need to use the |presentation_timestamp| for video, and
-  // use |size| to calculate the timestamp for audio. See
-  // http://crbug.com/310823 and http://b/11356652.
-  bool render_output  = unit.timestamp >= preroll_timestamp_ &&
+  bool render_output  = presentation_timestamp >= preroll_timestamp_ &&

[wolenetz, 2014/01/02 19:24:53]

The previous implementation had a comment mentioning audio is a special case for
which |size| should be used to calculate the timestamp. Was that comment
incorrect, or if correct, where is |presentation_timestamp| calculated correctly
for audio prior to this line of code?

Also, the adjusted unit tests feed decoder with the same data repeatedly with
only AU timestamp changing (e.g., MSPUT::PrerollDecoderToTime()). Is it
guaranteed that all MediaCodec implementations will similarly increment the
output |presentation_timestamp| regardless of the encoded content being a series
of duplicate AUs?

It looks like usage and implementation of MCB::QueueInputBuffer() tells
MediaCodec that the encoded unit's presentation time is the AU's timestamp. Is
this always the case (even in out-of-order decodes?) I suspect this is incorrect
and more tests are necessary to confirm.

[qinmin, 2014/01/02 22:57:01]

audio timestamp is equal to input AU's timestamp, so it is not as accurate as
the clock_(which uses size） we maintained in MSP. However, since both Audio and
video presentation timestamp are obtained from AU's timestamp, so the same
inaccuracy will be contained in both streams. If we currently relying on AU's
timestamp to do preroll, then using presentation timestamp should not introduce
extra inaccuracies.
Yes, MediaCodec uses the relies on the input AU's timestamp to calculate the
output |presentation_timestamp|. If input AU's presentation timestamp is
changed, so do output if they are all I-frames.
For audio, the decoded presentation timestamp is equal to the input timestamp.
For video, i have no idea how timestamp for out-of-order cases are calculated.

       (status != MEDIA_CODEC_OUTPUT_END_OF_STREAM || size != 0u);
   base::TimeDelta time_to_render;
   DCHECK(!start_time_ticks.is_null());
   if (render_output && ComputeTimeToRender()) {
     time_to_render = presentation_timestamp - (base::TimeTicks::Now() -
         start_time_ticks + start_presentation_timestamp);
   }
 
   if (time_to_render > base::TimeDelta()) {
     decoder_task_runner_->PostDelayedTask(
@@ skipping 58 matching lines @@
       // Do nothing.
       break;
   };
 
   stop_decode_pending_ = false;
   base::ResetAndReturn(&decode_cb_).Run(status, presentation_timestamp,
                                         audio_output_bytes);
 }
 
 }  // namespace media