Audio and video decoders for MediaCodecPlayer

media/base/android/demuxer_stream_player_params.cc

Index: media/base/android/demuxer_stream_player_params.cc
diff --git a/media/base/android/demuxer_stream_player_params.cc b/media/base/android/demuxer_stream_player_params.cc
index 5c2a11fc28498ec31a40e71158b8da4181d1fd8e..e72d8b644702734d906379b5d2938ee5b5c7c7da 100644
--- a/media/base/android/demuxer_stream_player_params.cc
+++ b/media/base/android/demuxer_stream_player_params.cc
@@ -27,3 +27,10 @@ DemuxerData::DemuxerData() : type(DemuxerStream::UNKNOWN) {}
 DemuxerData::~DemuxerData() {}
 
 }  // namespace media
+
+std::ostream& operator<<(std::ostream& os, const media::AccessUnit& au) {
+  os << "status:" << au.status << (au.is_end_of_stream ? " EOS" : "")
+     << (au.is_key_frame ? " KEY_FRAME" : "") << " pts:" << au.timestamp

[wolenetz, 2015/06/19 22:46:42]

nit: it might also be interesting to output dts here as well, since pts isn't
guaranteed to be monotonically non-decreasing (like dts) in out-of-order decode
codecs (like h264).

[Tima Vaisburd, 2015/06/20 02:32:30]

Yes, I even have this situation in the unit test :-)

There is only one |timestamp| field in AccessUnit and I believe this is PTS.
Although there is no DTS, I think we know the decoding order, which is the order
the AU are coming from demuxer. At least this is the order I put them into
MediaCodec, so I made this assumption.
For the logs this order comes naturally as I print the chunk one AU after
another.

[wolenetz, 2015/06/22 21:41:21]

You're right. Ignore my comment - we don't need to add DTS to AU just for
logging, nor in this CL.

+     << " size:" << au.data.size();

[wolenetz, 2015/06/19 22:46:41]

nit: if an AU contains a config change, that would be especially interesting
data to log. Please add that here, too.

[Tima Vaisburd, 2015/06/20 02:32:30]

I added operator<< but used is so far in SetDemuxerConfigs only. Unfortunately
there is a duplication, could not use
https://code.google.com/p/chromium/codesearch#chromium/src/media/base/audio_d...
(and video) because they are not static.

[wolenetz, 2015/06/22 21:41:21]

Duplication is ugly; but unless we jump forward to a mojo-ized world where we
deserialize back into a {Audio,Video}DecoderConfig, then we'll use what you have
here.

+  return os;
+}