MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32 case

MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32 case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some
cases. Unknown duration is web-app-visible and changes MSE behavior.
Also, it's used as a signal to enable our experimental low-delay
video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization
segment (~1.5k, compared to full original file ~750k), and modified
the mvhd duration field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted
as a real duration) before the rest of the code changes were included
into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org

Committed: https://crrev.com/74582e201d84a1c30258239798f6ad4fcde923e8
Cr-Commit-Position: refs/heads/master@{#421291}

[wolenetz, 2016-09-24 02:04:49]

Description was changed from

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

to

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some cases.
Unknown duration is web-app-visible and changes MSE behavior. Also, it's used as
a signal to enable our experimental low-delay video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization segment
(~1.5k, compared to full original file ~750k), and modified the mvhd duration
field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted as a
real duration) before the rest of the code changes were included into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

[wolenetz, 2016-09-24 02:05:39]

Description was changed from

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some cases.
Unknown duration is web-app-visible and changes MSE behavior. Also, it's used as
a signal to enable our experimental low-delay video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization segment
(~1.5k, compared to full original file ~750k), and modified the mvhd duration
field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted as a
real duration) before the rest of the code changes were included into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

to

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some
cases. Unknown duration is web-app-visible and changes MSE behavior.
Also, it's used as a signal to enable our experimental low-delay
video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization
segment (~1.5k, compared to full original file ~750k), and modified
the mvhd duration field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted
as a real duration) before the rest of the code changes were included
into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

[wolenetz, 2016-09-24 02:05:55]

The CQ bit was checked by wolenetz@chromium.org to run a CQ dry run

[wolenetz, 2016-09-24 02:06:09]

Please take a look. Thanks!

[commit-bot: I haz the power, 2016-09-24 02:06:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-24 05:22:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-24 05:22:14]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[xhwang, 2016-09-24 06:01:19]

LGTM % nits

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
File media/formats/mp4/mp4_stream_parser.cc (right):

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser.cc:429:
std::numeric_limits<uint64_t>::max()))) {
Could you please add some comments? This is getting harder to read :)

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
File media/formats/mp4/mp4_stream_parser_unittest.cc (right):

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser_unittest.cc:299:
"bear-1280x720-av_frag-initsegment-mvhd_version_0-mvhd_duration_bits_all_"
Could you please update media/test/data/README to provide some information about
this new test file, e.g. how it's created, what's special etc.

[wolenetz, 2016-09-26 19:35:24]

Thanks for review.

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
File media/formats/mp4/mp4_stream_parser.cc (right):

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser.cc:429:
std::numeric_limits<uint64_t>::max()))) {
On 2016/09/24 06:01:19, xhwang (slow) wrote:
> Could you please add some comments? This is getting harder to read :)

Done.

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
File media/formats/mp4/mp4_stream_parser_unittest.cc (right):

https://codereview.chromium.org/2368773002/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser_unittest.cc:299:
"bear-1280x720-av_frag-initsegment-mvhd_version_0-mvhd_duration_bits_all_"
On 2016/09/24 06:01:19, xhwang (slow) wrote:
> Could you please update media/test/data/README to provide some information
about
> this new test file, e.g. how it's created, what's special etc.

Done.

[wolenetz, 2016-09-26 19:37:13]

The CQ bit was checked by wolenetz@chromium.org

[wolenetz, 2016-09-26 19:37:13]

The patchset sent to the CQ was uploaded after l-g-t-m from xhwang@chromium.org
Link to the patchset: https://codereview.chromium.org/2368773002/#ps20001
(title: "Address review comments")

[commit-bot: I haz the power, 2016-09-26 19:38:18]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-26 21:42:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-26 21:42:16]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wolenetz, 2016-09-26 23:54:16]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2016-09-26 23:54:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-27 03:07:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-27 03:07:32]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[wolenetz, 2016-09-27 18:40:01]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2016-09-27 18:40:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-27 19:18:07]

Description was changed from

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some
cases. Unknown duration is web-app-visible and changes MSE behavior.
Also, it's used as a signal to enable our experimental low-delay
video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization
segment (~1.5k, compared to full original file ~750k), and modified
the mvhd duration field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted
as a real duration) before the rest of the code changes were included
into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

to

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some
cases. Unknown duration is web-app-visible and changes MSE behavior.
Also, it's used as a signal to enable our experimental low-delay
video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization
segment (~1.5k, compared to full original file ~750k), and modified
the mvhd duration field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted
as a real duration) before the rest of the code changes were included
into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

[commit-bot: I haz the power, 2016-09-27 19:18:09]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-27 19:20:32]

Description was changed from

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some
cases. Unknown duration is web-app-visible and changes MSE behavior.
Also, it's used as a signal to enable our experimental low-delay
video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization
segment (~1.5k, compared to full original file ~750k), and modified
the mvhd duration field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted
as a real duration) before the rest of the code changes were included
into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org
==========

to

==========
MSE: Recognize "unknown duration" in ISOBMFF mvhd version 0, duration max uint32
case

Previously, an "unknown duration" signalled by a mvhd duration
field was only understood to be unknown if it were 0, or a
64-bit (version 1 mvhd) special value of all bits set. This change adds
the same special value handling for a 32-bit (version 0 mvhd).

This change corrects detection of unknown mp4 MSE durations in some
cases. Unknown duration is web-app-visible and changes MSE behavior.
Also, it's used as a signal to enable our experimental low-delay
video rendering path.

I used a hex editor create the new test media file from
bear-1280x720-av_frag.mp4: truncated the file to just the initialization
segment (~1.5k, compared to full original file ~750k), and modified
the mvhd duration field values to be all bits set instead of 0.

The new unit test fails (due the the max-uint32 value being interpreted
as a real duration) before the rest of the code changes were included
into this CL.

TEST=MP4StreamParserTest.UnknownDuration_V0_AllBitsSet
BUG=649882
R=xhwang@chromium.org

Committed: https://crrev.com/74582e201d84a1c30258239798f6ad4fcde923e8
Cr-Commit-Position: refs/heads/master@{#421291}
==========

[commit-bot: I haz the power, 2016-09-27 19:20:33]

Patchset 2 (id:??) landed as
https://crrev.com/74582e201d84a1c30258239798f6ad4fcde923e8
Cr-Commit-Position: refs/heads/master@{#421291}