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

media/base/android/media_decoder_job.cc

Index: media/base/android/media_decoder_job.cc
diff --git a/media/base/android/media_decoder_job.cc b/media/base/android/media_decoder_job.cc
index 75b72ce5fc224b4b4db3a9a60323a5a9d18f04e2..08b56aa145c5fc46b2afd2f4ffcd3a3e9c4d1c6a 100644
--- a/media/base/android/media_decoder_job.cc
+++ b/media/base/android/media_decoder_job.cc
@@ -350,14 +350,7 @@ void MediaDecoderJob::DecodeInternal(
   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());