This bug is to track the replacement of int64_t that is used thorough the media code by TimeUnit objects.

Jean-Yves, Uploaded the WIP patches I have. I tried to keep each self-contained to aid reviewing. This means that there are places where TimeUnit -> uint64_t -> TimeUnit happens, or TimeUnit -> uint64_t. I have a list of notes of such things to clean up as I saw them, such as: * WebM - SeekInternal - replace magic with TimeUnit * WaveReader - Seek - replace magic with TimeUnit * OggReader - SeekInternal - update to use TimeUnit * SeekTarget - change mTime from int64 to TimeUnit * mAudioSeekTimeUs - change to TimeUnit * mediaData - mTime - change from int64_t to TimeUnit * MaybeSetChannelStartTime - change TimeUnit * DecodedAudioDataSink - replace mStartTime * mCurrentTimeBeforeSeek MDSM. I don't know any of these are useful. You mentioned that you didn't think all uint64_t should be changed to TimeUnit. Use of TimeUnit certainly helped make clear what units some calculations are in, especially code that converted between seconds, microseconds and nanoseconds.

I've done SeekTarget ; overall comment, const SeekTarget& should probably be used whenever possible, prevent a construction + copy. Can't use references however whenever InvokeAsync is involved.

Mass change P2 -> P3