Fix mpeg-1 layer2 parsing typo.

Fix mpeg-1 layer2 parsing typo.

Path was rejecting all valid files and passing on all invalid ones :/

BUG=693962
TEST=new unittest

Review-Url: https://codereview.chromium.org/2705353002
Cr-Commit-Position: refs/heads/master@{#452136}
Committed: https://chromium.googlesource.com/chromium/src/+/333c4148fe97a5a5e9964b0e390edf2a3fb36cf7

[DaleCurtis, 2017-02-21 23:39:56]

dalecurtis@chromium.org changed reviewers:
+ chcunningham@chromium.org

[chcunningham, 2017-02-22 00:49:04]

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
File media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc (right):

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:52: // 2" field size
assumptions.
Is this just theoretical? I'm not aware of any powers of two assumptions in
media segment length. The API is pretty high level.

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:57: "{ 0K }"
Why are the timestamps not increasing?

[DaleCurtis, 2017-02-22 00:53:11]

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
File media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc (right):

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:52: // 2" field size
assumptions.
On 2017/02/22 at 00:49:04, chcunningham wrote:
> Is this just theoretical? I'm not aware of any powers of two assumptions in
media segment length. The API is pretty high level.

Yes I think it's just theoretical, but that's how all of these parser tests are
written so I just kept the style.

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:57: "{ 0K }"
On 2017/02/22 at 00:49:03, chcunningham wrote:
> Why are the timestamps not increasing?

Timestamps restart per append; so the small append size results in a restart of
timestamping everytime. I forget how MSE cleans this up internally; but note
this is the same as the test above.

[chcunningham, 2017-02-22 01:13:48]

lgtm

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
File media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc (right):

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:52: // 2" field size
assumptions.
On 2017/02/22 00:53:11, DaleCurtis wrote:
> On 2017/02/22 at 00:49:04, chcunningham wrote:
> > Is this just theoretical? I'm not aware of any powers of two assumptions in
> media segment length. The API is pretty high level.
> 
> Yes I think it's just theoretical, but that's how all of these parser tests
are
> written so I just kept the style.

Sorry, missed that. Your first segment isn't prime (4), so I'd just kill that
comment.

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:57: "{ 0K }"
On 2017/02/22 00:53:11, DaleCurtis wrote:
> On 2017/02/22 at 00:49:03, chcunningham wrote:
> > Why are the timestamps not increasing?
> 
> Timestamps restart per append; so the small append size results in a restart
of
> timestamping everytime. I forget how MSE cleans this up internally; but note
> this is the same as the test above.

Ah, yeah. timestampOffset gets updated at the boundary of the append.

[DaleCurtis, 2017-02-22 01:20:14]

The CQ bit was checked by dalecurtis@chromium.org

[DaleCurtis, 2017-02-22 01:20:15]

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
File media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc (right):

https://codereview.chromium.org/2705353002/diff/1/media/formats/mpeg/mpeg1_au...
media/formats/mpeg/mpeg1_audio_stream_parser_unittest.cc:52: // 2" field size
assumptions.
On 2017/02/22 at 01:13:48, chcunningham wrote:
> On 2017/02/22 00:53:11, DaleCurtis wrote:
> > On 2017/02/22 at 00:49:04, chcunningham wrote:
> > > Is this just theoretical? I'm not aware of any powers of two assumptions
in
> > media segment length. The API is pretty high level.
> > 
> > Yes I think it's just theoretical, but that's how all of these parser tests
are
> > written so I just kept the style.
> 
> Sorry, missed that. Your first segment isn't prime (4), so I'd just kill that
comment.

Done.

[DaleCurtis, 2017-02-22 01:20:15]

The patchset sent to the CQ was uploaded after l-g-t-m from
chcunningham@chromium.org
Link to the patchset: https://codereview.chromium.org/2705353002/#ps20001
(title: "Nuke comment.")

[commit-bot: I haz the power, 2017-02-22 01:21:43]

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, 2017-02-22 03:24:51]

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

[commit-bot: I haz the power, 2017-02-22 03:24:52]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no
build URL)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)

[DaleCurtis, 2017-02-22 03:43:53]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2017-02-22 03:45:05]

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, 2017-02-22 07:22:42]

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

[commit-bot: I haz the power, 2017-02-22 07:22:43]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[DaleCurtis, 2017-02-22 16:52:26]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2017-02-22 16:53:13]

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, 2017-02-22 18:22:13]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1487782346001350,
"parent_rev": "c58ff8ebedea639ba58fb30a2e29faca9f8a0407", "commit_rev":
"333c4148fe97a5a5e9964b0e390edf2a3fb36cf7"}

[commit-bot: I haz the power, 2017-02-22 18:22:50]

Description was changed from

==========
Fix mpeg-1 layer2 parsing typo.

Path was rejecting all valid files and passing on all invalid ones :/

BUG=693962
TEST=new unittest
==========

to

==========
Fix mpeg-1 layer2 parsing typo.

Path was rejecting all valid files and passing on all invalid ones :/

BUG=693962
TEST=new unittest

Review-Url: https://codereview.chromium.org/2705353002
Cr-Commit-Position: refs/heads/master@{#452136}
Committed:
https://chromium.googlesource.com/chromium/src/+/333c4148fe97a5a5e9964b0e390e...
==========

[commit-bot: I haz the power, 2017-02-22 18:22:51]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/333c4148fe97a5a5e9964b0e390e...