MSE: Record counts of detected MSE audio, video and text tracks

MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported. Further, 'sbtl' handler_type is detected as text tracks in
ISO BMFF, going beyond what the spec describes currently, but enabling
detection of this subtitle track embedding produced by some ffmpeg
encodes.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
Committed: https://crrev.com/792762d71f66b64b5ac4b569a397058c1a8a0176
Cr-Commit-Position: refs/heads/master@{#383886}

[wolenetz, 2016-03-23 01:45:49]

wolenetz@chromium.org changed reviewers:
+ chcunningham@chromium.org, holte@chromium.org

[wolenetz, 2016-03-23 01:45:50]

Please take a look. This is the MSE version of the src= CL I landed yesterday
(https://codereview.chromium.org/1811413004/).

Like that other CL, the intent is to obtain better data around current
multitrack A/V/Text usage. If curious, see also the internal doc referenced in
https://crbug.com/595128.

chcunningham@: everything
holte@: histograms.xml

Thanks!

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/box_defin...
File media/formats/mp4/box_definitions.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/box_defin...
media/formats/mp4/box_definitions.cc:464: } else if (hdlr_type == FOURCC_META ||
hdlr_type == FOURCC_SUBT ||
Note, this follows the logic in
https://dev.w3.org/html5/html-sourcing-inband-tracks/#mpeg4
Note also that 608/708 caption data inside a video track is not yet detected
(see also new https://crbug.com/597073 and new MSE spec bug
https://github.com/w3c/media-source/issues/58). tl;dr: we don't have enough
information in just an initialization segment to detect that caption data.
Discussion is ongoing in the spec bug to see how the spec might need to change
to support 608 / 708 caption data population into SourceBuffer.textTracks and
HTMLMediaElement.textTrcks.

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
File media/formats/webm/webm_tracks_parser.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
media/formats/webm/webm_tracks_parser.cc:247: detected_text_track_count_++;
aside: For better data (and similar to ffmpeg_demuxer.cc), we detect and report
even if the actual use later in the parser/pipeline of text track is not
enabled.

[wolenetz, 2016-03-23 01:46:10]

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

[commit-bot: I haz the power, 2016-03-23 01:46:30]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826583003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826583003/1

[wolenetz, 2016-03-23 01:47:50]

Description was changed from

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128
==========

to

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
==========

[commit-bot: I haz the power, 2016-03-23 03:00:41]

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

[commit-bot: I haz the power, 2016-03-23 03:00:41]

Dry run: This issue passed the CQ dry run.

[Steven Holte, 2016-03-23 18:37:16]

histograms lgtm

[chcunningham, 2016-03-23 23:05:56]

Nice change :)

https://codereview.chromium.org/1826583003/diff/1/media/filters/chunk_demuxer.cc
File media/filters/chunk_demuxer.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer.cc:972: // Wait until all streams have initialized.
OK, we chatted f2f quite a bit. For posterity, let me state the problem and the
new plan:

PROBLEM:
This check is crucial to guarding the code below from over reporting (as well as
protecting code after that from executing too early). The gotcha is this check
is bad because:


1) the existence of video_ or audio_ does not guarantee that OnSourceInitDone is
called for those streams (which is really what you want to check). It happens
that the stream parser's (at least MP4) are written in such a way that the order
is correct (the callback for stream creation is made just a few lines above the
init done callback), but its really fragile and hard to verify for all parsers.

2) there is no check at all for text_ streams, so if you have a text stream in
separate source buffer, you will definitely over report here.


PLAN:
Add a counter for OnSourceInitDones such that you only proceed past this line
when inits_done_ == num_source_buffers_ (or whatever the equivalent variables
are).

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/box_defin...
File media/formats/mp4/box_definitions.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/box_defin...
media/formats/mp4/box_definitions.cc:464: } else if (hdlr_type == FOURCC_META ||
hdlr_type == FOURCC_SUBT ||
On 2016/03/23 01:45:50, wolenetz wrote:
> Note, this follows the logic in
> https://dev.w3.org/html5/html-sourcing-inband-tracks/#mpeg4
> Note also that 608/708 caption data inside a video track is not yet detected
> (see also new https://crbug.com/597073 and new MSE spec bug
> https://github.com/w3c/media-source/issues/58). tl;dr: we don't have enough
> information in just an initialization segment to detect that caption data.
> Discussion is ongoing in the spec bug to see how the spec might need to change
> to support 608 / 708 caption data population into SourceBuffer.textTracks and
> HTMLMediaElement.textTrcks.

Acknowledged.

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

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser.cc:416: params.detected_text_track_count =
detected_text_track_count;
Might be good to add a test for these to mp4_stream_parser_unittest.cc... may be
as simple as adding some params and checks to InitializeParserAndExpectLiveness
(InitializeParserAndExpect(liveness, audio_track_count, ....)

https://codereview.chromium.org/1826583003/diff/1/media/formats/mpeg/mpeg_aud...
File media/formats/mpeg/mpeg_audio_stream_parser_base.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/mpeg/mpeg_aud...
media/formats/mpeg/mpeg_audio_stream_parser_base.cc:229:
params.detected_audio_track_count = 1;
Some quick googling for multitrack mpeg audio didn't turn up anything. I assume
you're good here :)

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_str...
File media/formats/webm/webm_stream_parser.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_str...
media/formats/webm/webm_stream_parser.cc:246: params.detected_audio_track_count
=
Should also do a test for this guy. Should be easy in
webm_stream_parser_unittests.cc

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
File media/formats/webm/webm_tracks_parser.cc (left):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
media/formats/webm/webm_tracks_parser.cc:51: track_num_(-1),
Nit: You might be better off with a private method "reset" method that you can
call here and in the top of ::Parse

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
File media/formats/webm/webm_tracks_parser.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
media/formats/webm/webm_tracks_parser.cc:247: detected_text_track_count_++;
On 2016/03/23 01:45:50, wolenetz wrote:
> aside: For better data (and similar to ffmpeg_demuxer.cc), we detect and
report
> even if the actual use later in the parser/pipeline of text track is not
> enabled.

Acknowledged.

[wolenetz, 2016-03-25 23:25:08]

PS2 is WIP: Not all comments are addressed yet.
It's an interim update to get my comment linked from
https://bugs.chromium.org/p/chromium/issues/detail?id=597447#c1 satisfied.

Pending work:
1) add new mp4 and webm test media containing text track(s) and verify their
detection.
2) update the webm parser tests to verify track count detection like I did in
PS2 for mp4.

https://codereview.chromium.org/1826583003/diff/1/media/filters/chunk_demuxer.cc
File media/filters/chunk_demuxer.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer.cc:972: // Wait until all streams have initialized.
On 2016/03/23 23:05:56, chcunningham wrote:
> OK, we chatted f2f quite a bit. For posterity, let me state the problem and
the
> new plan:
> 
> PROBLEM:
> This check is crucial to guarding the code below from over reporting (as well
as
> protecting code after that from executing too early). The gotcha is this check
> is bad because:
> 
> 
> 1) the existence of video_ or audio_ does not guarantee that OnSourceInitDone
is
> called for those streams (which is really what you want to check). It happens
> that the stream parser's (at least MP4) are written in such a way that the
order
> is correct (the callback for stream creation is made just a few lines above
the
> init done callback), but its really fragile and hard to verify for all
parsers.
> 
> 2) there is no check at all for text_ streams, so if you have a text stream in
> separate source buffer, you will definitely over report here.
> 
> 
> PLAN:
> Add a counter for OnSourceInitDones such that you only proceed past this line
> when inits_done_ == num_source_buffers_ (or whatever the equivalent variables
> are).

All current Chromium stream parsers (not just mp4) adhere to the contract of
only calling init_cb *after* config_cb.

https://crbug.com/597447 filed to fix the text-only stream init race problem
described in 2), above.

Regarding (1), it'll need more than just a counter to make less fragile to code
change. Ideally, the init_cb could be removed from the stream parser interface,
and the contract changed such that the first config_cb_ executed by a stream
parser corresponds to that stream parser signalling "I'm initialized". That'd
make it simpler to enforce across all parsers, in
MediaSourceState::OnNewConfigs(), that the OnSourceInitDone() for that
MediaSourceState (1:1 with a SourceBuffer, and 1:1 with a StreamParser) is done
precisely after the first initialization segment has been reported by the parser
without producing error during OnNewConfigs() configs verification.

I'll add this bit into that same bug to get fixed at the same time (again,
ideally... :) )

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

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser.cc:416: params.detected_text_track_count =
detected_text_track_count;
On 2016/03/23 23:05:56, chcunningham wrote:
> Might be good to add a test for these to mp4_stream_parser_unittest.cc... may
be
> as simple as adding some params and checks to
InitializeParserAndExpectLiveness
> (InitializeParserAndExpect(liveness, audio_track_count, ....)

Yup. I thought you might ask :)
Verification added.
For verifying nonzero *text* tracks related to this and the similar webm
comment, I'm working on getting some content added to this CL. Not there yet.

https://codereview.chromium.org/1826583003/diff/1/media/formats/mpeg/mpeg_aud...
File media/formats/mpeg/mpeg_audio_stream_parser_base.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/mpeg/mpeg_aud...
media/formats/mpeg/mpeg_audio_stream_parser_base.cc:229:
params.detected_audio_track_count = 1;
On 2016/03/23 23:05:56, chcunningham wrote:
> Some quick googling for multitrack mpeg audio didn't turn up anything. I
assume
> you're good here :)

Acknowledged.

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_str...
File media/formats/webm/webm_stream_parser.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_str...
media/formats/webm/webm_stream_parser.cc:246: params.detected_audio_track_count
=
On 2016/03/23 23:05:56, chcunningham wrote:
> Should also do a test for this guy. Should be easy in
> webm_stream_parser_unittests.cc

Upcoming in later patch set.

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
File media/formats/webm/webm_tracks_parser.cc (left):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
media/formats/webm/webm_tracks_parser.cc:51: track_num_(-1),
On 2016/03/23 23:05:56, chcunningham wrote:
> Nit: You might be better off with a private method "reset" method that you can
> call here and in the top of ::Parse

Agreed. Will be in later patch set.

[wolenetz, 2016-03-28 20:41:46]

Still WIP.

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
File media/formats/webm/webm_tracks_parser.cc (left):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_tra...
media/formats/webm/webm_tracks_parser.cc:51: track_num_(-1),
On 2016/03/25 23:25:08, wolenetz wrote:
> On 2016/03/23 23:05:56, chcunningham wrote:
> > Nit: You might be better off with a private method "reset" method that you
can
> > call here and in the top of ::Parse
> 
> Agreed. Will be in later patch set.

I've sent this particular cleanup as a prereq CL [1]. I'll rebase this CL onto
that one, once that one lands.
[1] https://codereview.chromium.org/1842503002

[wolenetz, 2016-03-29 00:13:47]

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

[commit-bot: I haz the power, 2016-03-29 00:14:03]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826583003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826583003/40001

[wolenetz, 2016-03-29 00:14:43]

chcunningham@, please take a look at patch set 3.

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

https://codereview.chromium.org/1826583003/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser.cc:416: params.detected_text_track_count =
detected_text_track_count;
On 2016/03/25 23:25:08, wolenetz wrote:
> On 2016/03/23 23:05:56, chcunningham wrote:
> > Might be good to add a test for these to mp4_stream_parser_unittest.cc...
may
> be
> > as simple as adding some params and checks to
> InitializeParserAndExpectLiveness
> > (InitializeParserAndExpect(liveness, audio_track_count, ....)
> 
> Yup. I thought you might ask :)
> Verification added.
> For verifying nonzero *text* tracks related to this and the similar webm
> comment, I'm working on getting some content added to this CL. Not there yet.

Done.

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_str...
File media/formats/webm/webm_stream_parser.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/formats/webm/webm_str...
media/formats/webm/webm_stream_parser.cc:246: params.detected_audio_track_count
=
On 2016/03/25 23:25:08, wolenetz wrote:
> On 2016/03/23 23:05:56, chcunningham wrote:
> > Should also do a test for this guy. Should be easy in
> > webm_stream_parser_unittests.cc
> 
> Upcoming in later patch set.

Done.

[commit-bot: I haz the power, 2016-03-29 02:19:51]

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

[commit-bot: I haz the power, 2016-03-29 02:19:52]

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

[wolenetz, 2016-03-29 17:57:57]

Description was changed from

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
==========

to

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported. Further, 'sbtl' handler_type is detected as text tracks in
ISO BMFF, going beyond what the spec describes currently, but enabling
detection of this subtitle track embedding produced by some ffmpeg
encodes.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
==========

[wolenetz, 2016-03-29 19:39:08]

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

[commit-bot: I haz the power, 2016-03-29 19:39:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826583003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826583003/60001

[wolenetz, 2016-03-29 20:51:21]

On 2016/03/29 19:39:35, commit-bot: I haz the power wrote:
> Dry run: CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1826583003/60001
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1826583003/60001

Hmm. PS3 and PS4 both fail to link, on only win_chromium_compile_dbg_ng. It
seems like a toolchain-specific problem with struct-in-class's explicit ctor not
being exported, while the enclosing class' symbols are exported.
To workaround and get this done, I'll redo the webm_stream_parser_unittests.cc
portion of this change to explicitly verify preset InitParameters expectations,
like done in mp4_stream_parser_unittests.cc.

[commit-bot: I haz the power, 2016-03-29 21:05:36]

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

[commit-bot: I haz the power, 2016-03-29 21:05:38]

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

[wolenetz, 2016-03-29 21:36:42]

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

[wolenetz, 2016-03-29 21:37:12]

chcunningham@, PTAL PS5.

[commit-bot: I haz the power, 2016-03-29 21:37:25]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826583003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826583003/80001

[chcunningham, 2016-03-29 22:14:51]

lgtm

https://codereview.chromium.org/1826583003/diff/1/media/filters/chunk_demuxer.cc
File media/filters/chunk_demuxer.cc (right):

https://codereview.chromium.org/1826583003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer.cc:972: // Wait until all streams have initialized.
On 2016/03/25 23:25:08, wolenetz wrote:
> On 2016/03/23 23:05:56, chcunningham wrote:
> > OK, we chatted f2f quite a bit. For posterity, let me state the problem and
> the
> > new plan:
> > 
> > PROBLEM:
> > This check is crucial to guarding the code below from over reporting (as
well
> as
> > protecting code after that from executing too early). The gotcha is this
check
> > is bad because:
> > 
> > 
> > 1) the existence of video_ or audio_ does not guarantee that
OnSourceInitDone
> is
> > called for those streams (which is really what you want to check). It
happens
> > that the stream parser's (at least MP4) are written in such a way that the
> order
> > is correct (the callback for stream creation is made just a few lines above
> the
> > init done callback), but its really fragile and hard to verify for all
> parsers.
> > 
> > 2) there is no check at all for text_ streams, so if you have a text stream
in
> > separate source buffer, you will definitely over report here.
> > 
> > 
> > PLAN:
> > Add a counter for OnSourceInitDones such that you only proceed past this
line
> > when inits_done_ == num_source_buffers_ (or whatever the equivalent
variables
> > are).
> 
> All current Chromium stream parsers (not just mp4) adhere to the contract of
> only calling init_cb *after* config_cb.
> 
> https://crbug.com/597447 filed to fix the text-only stream init race problem
> described in 2), above.
> 
> Regarding (1), it'll need more than just a counter to make less fragile to
code
> change. Ideally, the init_cb could be removed from the stream parser
interface,
> and the contract changed such that the first config_cb_ executed by a stream
> parser corresponds to that stream parser signalling "I'm initialized". That'd
> make it simpler to enforce across all parsers, in
> MediaSourceState::OnNewConfigs(), that the OnSourceInitDone() for that
> MediaSourceState (1:1 with a SourceBuffer, and 1:1 with a StreamParser) is
done
> precisely after the first initialization segment has been reported by the
parser
> without producing error during OnNewConfigs() configs verification.
> 
> I'll add this bit into that same bug to get fixed at the same time (again,
> ideally... :) )

Acknowledged.

https://codereview.chromium.org/1826583003/diff/40001/media/formats/mp4/mp4_s...
File media/formats/mp4/mp4_stream_parser_unittest.cc (right):

https://codereview.chromium.org/1826583003/diff/40001/media/formats/mp4/mp4_s...
media/formats/mp4/mp4_stream_parser_unittest.cc:519:
ReadTestDataFile("bear-1280x720-avt_subt_frag.mp4");
cool!

[wolenetz, 2016-03-29 22:49:04]

Thanks for reviews. I found the link error is simply I need to MEDIA_EXPORT the
nested StreamParser::InitParameters struct. For some reason, I thought the new
mp4_stream_parser_unittests that used that struct built fine on the bots (before
I added similar to webm_stream_parser_unittests in a later PS), but I didn't run
those bot builds earlier... argh :)

I'll add that export and send to CQ.

[wolenetz, 2016-03-29 22:55:16]

The CQ bit was checked by wolenetz@chromium.org

[wolenetz, 2016-03-29 22:55:16]

The patchset sent to the CQ was uploaded after l-g-t-m from holte@chromium.org,
chcunningham@chromium.org
Link to the patchset: https://codereview.chromium.org/1826583003/#ps100001
(title: "Yet another attempt to fix that link failure. MEDIA_EXPORT should do
it!")

[commit-bot: I haz the power, 2016-03-29 22:55:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1826583003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1826583003/100001

[commit-bot: I haz the power, 2016-03-30 01:19:08]

Description was changed from

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported. Further, 'sbtl' handler_type is detected as text tracks in
ISO BMFF, going beyond what the spec describes currently, but enabling
detection of this subtitle track embedding produced by some ffmpeg
encodes.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
==========

to

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported. Further, 'sbtl' handler_type is detected as text tracks in
ISO BMFF, going beyond what the spec describes currently, but enabling
detection of this subtitle track embedding produced by some ffmpeg
encodes.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
==========

[commit-bot: I haz the power, 2016-03-30 01:19:09]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-03-30 01:20:05]

Description was changed from

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported. Further, 'sbtl' handler_type is detected as text tracks in
ISO BMFF, going beyond what the spec describes currently, but enabling
detection of this subtitle track embedding produced by some ffmpeg
encodes.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926
==========

to

==========
MSE: Record counts of detected MSE audio, video and text tracks

Reworks the StreamParser InitCB interface, MSE stream parsers, and
the handling of CB to sum and record the counts of tracks by
type across SourceBuffers for a MediaSource at the time of transitioning
ChunkDemuxer to INITIALIZED in ChunkDemuxer::OnSourceInitDone().

Reporting of detected text track counts is included for WebM and ISO
BMFF stream types, with minimal support added to the latter's parser in
this CL to support their detection only. Note that CEA 608/708 caption
data embedded within ISO BMFF video tracks is neither detected nor
reported. Further, 'sbtl' handler_type is detected as text tracks in
ISO BMFF, going beyond what the spec describes currently, but enabling
detection of this subtitle track embedding produced by some ffmpeg
encodes.

No other new text track presence detection is added; it is still missing
from some MSE parsers like mp2ts. Further, at most one each of audio and
video tracks are detected by the mp2ts parser.

BUG=595128, 336926

Committed: https://crrev.com/792762d71f66b64b5ac4b569a397058c1a8a0176
Cr-Commit-Position: refs/heads/master@{#383886}
==========

[commit-bot: I haz the power, 2016-03-30 01:20:06]

Patchset 6 (id:??) landed as
https://crrev.com/792762d71f66b64b5ac4b569a397058c1a8a0176
Cr-Commit-Position: refs/heads/master@{#383886}