Use FFmpeg's reordered_opaque for presentation timestamp reordering.

Use FFmpeg's reordered_opaque for presentation timestamp reordering.

This fixes numerous audio/video synchronization issues caused by PtsHeap getting out of sync due to the decoder silently dropping/reordering frames.

Most decoder libraries (including FFmpeg and OpenMAX) feature some form of presentation timestamp reordering.  This is the first step in moving away from using PtsHeap and instead requireing VideoDecodeEngines + their libraries to handle presentation timestamp reordering.

This change also removes VideoFrame::GetRepeatCount() as it is an FFmpeg-specific detail.  The duration is now properly calculated inside FFmpegVideoDecodeEngine.

BUG=26036
TEST=videos linked in bugs remain in sync, as do all other videos

[jiesun, 2010-04-28 16:42:35]

LGTM with comments for future improvement

http://codereview.chromium.org/1726015/diff/2001/3003
File media/filters/ffmpeg_video_decode_engine.cc (right):

http://codereview.chromium.org/1726015/diff/2001/3003#newcode151
media/filters/ffmpeg_video_decode_engine.cc:151: //   duration = (1 / fps) +
(repeat_pict) / (2 * fps)
just my comment, repeat_pict is used for field picture and 3:2 pulldown in most
possible scenario. in that case, top_field_first also need to pass to render to
be display correctly, that's why repeat_pict(or repeat_first_field in some
specs, and top_field_first should be part of the video frame abstraction. but we
do not have any de-interlaced display anyway, and interlaced content is not
important to us?

[scherkus (not reviewing), 2010-04-28 17:00:23]

thanks for the review1

http://codereview.chromium.org/1726015/diff/2001/3003
File media/filters/ffmpeg_video_decode_engine.cc (right):

http://codereview.chromium.org/1726015/diff/2001/3003#newcode151
media/filters/ffmpeg_video_decode_engine.cc:151: //   duration = (1 / fps) +
(repeat_pict) / (2 * fps)
On 2010/04/28 16:42:36, jiesun wrote:
> just my comment, repeat_pict is used for field picture and 3:2 pulldown in
most
> possible scenario. in that case, top_field_first also need to pass to render
to
> be display correctly, that's why repeat_pict(or repeat_first_field in some
> specs, and top_field_first should be part of the video frame abstraction. but
we
> do not have any de-interlaced display anyway, and interlaced content is not
> important to us?

yep -- we've been intentionally ignoring interlaced content :)

[fbarchard, 2010-04-28 17:07:24]

if interlaced content comes up, it will be 1080i cameras for media player.  I
have example content, if you want it.

The description of your change sounds like a step in the right direction.