Motown: Various fixes related to video playback support

Motown: Various fixes related to video playback support
1) Fix end-of-stream handling in MediaTimelineController so that seeking
   resets end-of-stream properly.
2) Fix decoder output packet lifetime issue. Previously, Motown took
   sole possession of decoder output packets once decoding was complete.
   The video decoder, however, needs some decoded frames to stay around
   a long time as a basis for decoding 'delta' (e.g. B and P) frames.
   This CL makes Motown honor ffmpeg's frame reference counting scheme
   so that the frames stay around as long as they're needed.
3) Now DCHECKing that packets have no side data, because we aren't
   currently supporting that. Side data will need to be supported in the
   future to accommodate some formats.
4) Turn on ffmpeg multiproc decoding.
5) Translate video decoder pts (presentation timestamps) from a simple
   frame count to nanoseconds.
6) Increase the max number of outstanding packets a producer will
   produce and increase the shared buffer size. This measure is required
   to accommodate the offset between audio and video. This is a
   temporary measure...max outstanding packets should be dynamic and
   shared buffer allocation needs to get a lot smarter.

R=kulakowski@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/47f0ffbb4503478a586c20bce8e041f2deb16ef1

[dalesat, 2016-06-20 16:31:50]

Description was changed from

==========
Motown: Various fixes related to video playback support
1) Fix end-of-stream handling in MediaTimelineController so that seeking
   resets end-of-stream properly.
2) Fix decoder output packet lifetime issue. Previously, Motown took
   sole possession of decoder output packets once decoding was complete.
   The video decoder, however, needs some decoded frames to stay around
   a long time as a basis for decoding 'delta' (e.g. B and P) frames.
   This CL makes Motown honor ffmpeg's frame reference counting scheme
   so that the frames stay around as long as they're needed.
3) Now DCHECKing that packets have no side data, because we aren't
   currently supporting that. Side data will need to be supported in the
   future to accommodate some formats.
4) Turn on ffmpeg multiproc decoding.
5) Translate video decoder pts (presentation timestamps) from a simple
   frame count to nanoseconds.
6) Increase the max number of outstanding packets a producer will
   produce and increase the shared buffer size. This measure is required
   to accommodate the offset between audio and video. This is a
   temporary measure...max outstanding packets should be dynamic and
   shared buffer allocation needs to get a lot smarter.
==========

to

==========
Motown: Various fixes related to video playback support
1) Fix end-of-stream handling in MediaTimelineController so that seeking
   resets end-of-stream properly.
2) Fix decoder output packet lifetime issue. Previously, Motown took
   sole possession of decoder output packets once decoding was complete.
   The video decoder, however, needs some decoded frames to stay around
   a long time as a basis for decoding 'delta' (e.g. B and P) frames.
   This CL makes Motown honor ffmpeg's frame reference counting scheme
   so that the frames stay around as long as they're needed.
3) Now DCHECKing that packets have no side data, because we aren't
   currently supporting that. Side data will need to be supported in the
   future to accommodate some formats.
4) Turn on ffmpeg multiproc decoding.
5) Translate video decoder pts (presentation timestamps) from a simple
   frame count to nanoseconds.
6) Increase the max number of outstanding packets a producer will
   produce and increase the shared buffer size. This measure is required
   to accommodate the offset between audio and video. This is a
   temporary measure...max outstanding packets should be dynamic and
   shared buffer allocation needs to get a lot smarter.
==========

[dalesat, 2016-06-20 16:31:50]

dalesat@chromium.org changed reviewers:
+ kulakowski@chromium.org

[dalesat, 2016-06-20 16:32:12]

PTAL

Needs to be merged with https://codereview.chromium.org/2081753002/ to be
functional.

[kulakowski, 2016-06-20 22:21:38]

On 2016/06/20 16:32:12, dalesat wrote:
> PTAL
> 
> Needs to be merged with https://codereview.chromium.org/2081753002/ to be
> functional.

I'm finding this pretty hard to review. E.g. point 4 says that "multiproc
decoding" is turned on. The word multiproc doesn't show up in the diff, or any
word like it, and I am not sure what changes are for the lifetime issue, the
multiproc thing, or the pts format change.

[dalesat, 2016-06-20 22:42:53]

On 2016/06/20 22:21:38, kulakowski wrote:
> On 2016/06/20 16:32:12, dalesat wrote:
> > PTAL
> > 
> > Needs to be merged with https://codereview.chromium.org/2081753002/ to be
> > functional.
> 
> I'm finding this pretty hard to review. E.g. point 4 says that "multiproc
> decoding" is turned on. The word multiproc doesn't show up in the diff, or any
> word like it, and I am not sure what changes are for the lifetime issue, the
> multiproc thing, or the pts format change.

The things you mention are both in ffmpeg_video_decoder.cc. I've added some
comments and made a name change to clarify things.

[kulakowski, 2016-06-20 23:19:19]

lgtm

[dalesat, 2016-06-21 01:11:32]

Description was changed from

==========
Motown: Various fixes related to video playback support
1) Fix end-of-stream handling in MediaTimelineController so that seeking
   resets end-of-stream properly.
2) Fix decoder output packet lifetime issue. Previously, Motown took
   sole possession of decoder output packets once decoding was complete.
   The video decoder, however, needs some decoded frames to stay around
   a long time as a basis for decoding 'delta' (e.g. B and P) frames.
   This CL makes Motown honor ffmpeg's frame reference counting scheme
   so that the frames stay around as long as they're needed.
3) Now DCHECKing that packets have no side data, because we aren't
   currently supporting that. Side data will need to be supported in the
   future to accommodate some formats.
4) Turn on ffmpeg multiproc decoding.
5) Translate video decoder pts (presentation timestamps) from a simple
   frame count to nanoseconds.
6) Increase the max number of outstanding packets a producer will
   produce and increase the shared buffer size. This measure is required
   to accommodate the offset between audio and video. This is a
   temporary measure...max outstanding packets should be dynamic and
   shared buffer allocation needs to get a lot smarter.
==========

to

==========
Motown: Various fixes related to video playback support
1) Fix end-of-stream handling in MediaTimelineController so that seeking
   resets end-of-stream properly.
2) Fix decoder output packet lifetime issue. Previously, Motown took
   sole possession of decoder output packets once decoding was complete.
   The video decoder, however, needs some decoded frames to stay around
   a long time as a basis for decoding 'delta' (e.g. B and P) frames.
   This CL makes Motown honor ffmpeg's frame reference counting scheme
   so that the frames stay around as long as they're needed.
3) Now DCHECKing that packets have no side data, because we aren't
   currently supporting that. Side data will need to be supported in the
   future to accommodate some formats.
4) Turn on ffmpeg multiproc decoding.
5) Translate video decoder pts (presentation timestamps) from a simple
   frame count to nanoseconds.
6) Increase the max number of outstanding packets a producer will
   produce and increase the shared buffer size. This measure is required
   to accommodate the offset between audio and video. This is a
   temporary measure...max outstanding packets should be dynamic and
   shared buffer allocation needs to get a lot smarter.

R=kulakowski@chromium.org

Committed:
https://chromium.googlesource.com/external/mojo/+/47f0ffbb4503478a586c20bce8e...
==========

[dalesat, 2016-06-21 01:11:34]

Committed patchset #3 (id:40001) manually as
47f0ffbb4503478a586c20bce8e041f2deb16ef1 (presubmit successful).