MSE test for two SourceBuffers with clashing bytestream track ids

MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993
Committed: https://crrev.com/ac29e2565ea5d0bb7891297b6160ae26fd6f6a00
Cr-Commit-Position: refs/heads/master@{#404292}

[servolk, 2016-07-01 20:58:29]

Description was changed from

==========
MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993
==========

to

==========
MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993
==========

[servolk, 2016-07-01 20:58:29]

servolk@chromium.org changed reviewers:
+ wolenetz@chromium.org

[servolk, 2016-07-01 21:00:24]

Note that currently bytestream track ids are inaccessible from JS, so I've
verified manually that indeed bytestream track ids in two source buffers match.
But I wonder if we should expose bytestream track ids as one of the media track
properties in addition to the generated unique id.

[wolenetz, 2016-07-01 21:12:47]

On 2016/07/01 21:00:24, servolk wrote:
> Note that currently bytestream track ids are inaccessible from JS, so I've
> verified manually that indeed bytestream track ids in two source buffers
match.
> But I wonder if we should expose bytestream track ids as one of the media
track
> properties in addition to the generated unique id.

Hmm. Those bytestream IDs could change throughout the lifetime of a track. I
wonder therefore how useful. You could use TrackDefaults to enforce the
expectation of bytestream IDs matching (with the risk of TrackDefaults API being
at-risk currently in MSE spec, so may have to revert back to manual check on
test media if that TrackDefaults is deprecated in Chrome).

e.g. audio bsid 0 in a trackdefault with label='audio-track-with-bs-0-found'
(and similar for video), then verify that the trackdefaults apply correctly,
therefore proving that the bsid's matched (and were both 0).

WDYT?

[servolk, 2016-07-01 21:21:34]

On 2016/07/01 21:12:47, wolenetz wrote:
> On 2016/07/01 21:00:24, servolk wrote:
> > Note that currently bytestream track ids are inaccessible from JS, so I've
> > verified manually that indeed bytestream track ids in two source buffers
> match.
> > But I wonder if we should expose bytestream track ids as one of the media
> track
> > properties in addition to the generated unique id.
> 
> Hmm. Those bytestream IDs could change throughout the lifetime of a track. I
> wonder therefore how useful. You could use TrackDefaults to enforce the
> expectation of bytestream IDs matching (with the risk of TrackDefaults API
being
> at-risk currently in MSE spec, so may have to revert back to manual check on
> test media if that TrackDefaults is deprecated in Chrome).
> 
> e.g. audio bsid 0 in a trackdefault with label='audio-track-with-bs-0-found'
> (and similar for video), then verify that the trackdefaults apply correctly,
> therefore proving that the bsid's matched (and were both 0).
> 
> WDYT?

Yes, it's true that bytestream ids might change in subsequent init segments, so
we should make that very clear and ensure that clients never rely on bsids
staying constant. But it just seems weird to me that TrackDefaults might be
assigned based on bsid and not unique ids and yet clients have no direct way to
see actual bsid values without somehow analyzing the bitstream via third party
tools.
And now that you reminded me that bsids might change I've started wondering
about another thing - perhaps we should provide a way to assign TrackDefaults
based on unique ids and not bsids? Or else TrackDefaults might not apply if they
specify an explicit bsid value and bsid of the media track changes in subsequent
init segments.

[servolk, 2016-07-01 21:22:27]

On 2016/07/01 21:21:34, servolk wrote:
> On 2016/07/01 21:12:47, wolenetz wrote:
> > On 2016/07/01 21:00:24, servolk wrote:
> > > Note that currently bytestream track ids are inaccessible from JS, so I've
> > > verified manually that indeed bytestream track ids in two source buffers
> > match.
> > > But I wonder if we should expose bytestream track ids as one of the media
> > track
> > > properties in addition to the generated unique id.
> > 
> > Hmm. Those bytestream IDs could change throughout the lifetime of a track. I
> > wonder therefore how useful. You could use TrackDefaults to enforce the
> > expectation of bytestream IDs matching (with the risk of TrackDefaults API
> being
> > at-risk currently in MSE spec, so may have to revert back to manual check on
> > test media if that TrackDefaults is deprecated in Chrome).
> > 
> > e.g. audio bsid 0 in a trackdefault with label='audio-track-with-bs-0-found'
> > (and similar for video), then verify that the trackdefaults apply correctly,
> > therefore proving that the bsid's matched (and were both 0).
> > 
> > WDYT?
> 
> Yes, it's true that bytestream ids might change in subsequent init segments,
so
> we should make that very clear and ensure that clients never rely on bsids
> staying constant. But it just seems weird to me that TrackDefaults might be
> assigned based on bsid and not unique ids and yet clients have no direct way
to
> see actual bsid values without somehow analyzing the bitstream via third party
> tools.
> And now that you reminded me that bsids might change I've started wondering
> about another thing - perhaps we should provide a way to assign TrackDefaults
> based on unique ids and not bsids? Or else TrackDefaults might not apply if
they
> specify an explicit bsid value and bsid of the media track changes in
subsequent
> init segments.

Oh, and yes, I guess for the short-term solution we could do this bsid
verification via TrackDefaults. I'll give it a try.

[servolk, 2016-07-01 21:33:19]

On 2016/07/01 21:22:27, servolk wrote:
> On 2016/07/01 21:21:34, servolk wrote:
> > On 2016/07/01 21:12:47, wolenetz wrote:
> > > On 2016/07/01 21:00:24, servolk wrote:
> > > > Note that currently bytestream track ids are inaccessible from JS, so
I've
> > > > verified manually that indeed bytestream track ids in two source buffers
> > > match.
> > > > But I wonder if we should expose bytestream track ids as one of the
media
> > > track
> > > > properties in addition to the generated unique id.
> > > 
> > > Hmm. Those bytestream IDs could change throughout the lifetime of a track.
I
> > > wonder therefore how useful. You could use TrackDefaults to enforce the
> > > expectation of bytestream IDs matching (with the risk of TrackDefaults API
> > being
> > > at-risk currently in MSE spec, so may have to revert back to manual check
on
> > > test media if that TrackDefaults is deprecated in Chrome).
> > > 
> > > e.g. audio bsid 0 in a trackdefault with
label='audio-track-with-bs-0-found'
> > > (and similar for video), then verify that the trackdefaults apply
correctly,
> > > therefore proving that the bsid's matched (and were both 0).
> > > 
> > > WDYT?
> > 
> > Yes, it's true that bytestream ids might change in subsequent init segments,
> so
> > we should make that very clear and ensure that clients never rely on bsids
> > staying constant. But it just seems weird to me that TrackDefaults might be
> > assigned based on bsid and not unique ids and yet clients have no direct way
> to
> > see actual bsid values without somehow analyzing the bitstream via third
party
> > tools.
> > And now that you reminded me that bsids might change I've started wondering
> > about another thing - perhaps we should provide a way to assign
TrackDefaults
> > based on unique ids and not bsids? Or else TrackDefaults might not apply if
> they
> > specify an explicit bsid value and bsid of the media track changes in
> subsequent
> > init segments.
> 
> Oh, and yes, I guess for the short-term solution we could do this bsid
> verification via TrackDefaults. I'll give it a try.

Ok, implemented this in PS #2

[servolk, 2016-07-07 22:06:40]

On 2016/07/01 21:33:19, servolk wrote:
> On 2016/07/01 21:22:27, servolk wrote:
> > On 2016/07/01 21:21:34, servolk wrote:
> > > On 2016/07/01 21:12:47, wolenetz wrote:
> > > > On 2016/07/01 21:00:24, servolk wrote:
> > > > > Note that currently bytestream track ids are inaccessible from JS, so
> I've
> > > > > verified manually that indeed bytestream track ids in two source
buffers
> > > > match.
> > > > > But I wonder if we should expose bytestream track ids as one of the
> media
> > > > track
> > > > > properties in addition to the generated unique id.
> > > > 
> > > > Hmm. Those bytestream IDs could change throughout the lifetime of a
track.
> I
> > > > wonder therefore how useful. You could use TrackDefaults to enforce the
> > > > expectation of bytestream IDs matching (with the risk of TrackDefaults
API
> > > being
> > > > at-risk currently in MSE spec, so may have to revert back to manual
check
> on
> > > > test media if that TrackDefaults is deprecated in Chrome).
> > > > 
> > > > e.g. audio bsid 0 in a trackdefault with
> label='audio-track-with-bs-0-found'
> > > > (and similar for video), then verify that the trackdefaults apply
> correctly,
> > > > therefore proving that the bsid's matched (and were both 0).
> > > > 
> > > > WDYT?
> > > 
> > > Yes, it's true that bytestream ids might change in subsequent init
segments,
> > so
> > > we should make that very clear and ensure that clients never rely on bsids
> > > staying constant. But it just seems weird to me that TrackDefaults might
be
> > > assigned based on bsid and not unique ids and yet clients have no direct
way
> > to
> > > see actual bsid values without somehow analyzing the bitstream via third
> party
> > > tools.
> > > And now that you reminded me that bsids might change I've started
wondering
> > > about another thing - perhaps we should provide a way to assign
> TrackDefaults
> > > based on unique ids and not bsids? Or else TrackDefaults might not apply
if
> > they
> > > specify an explicit bsid value and bsid of the media track changes in
> > subsequent
> > > init segments.
> > 
> > Oh, and yes, I guess for the short-term solution we could do this bsid
> > verification via TrackDefaults. I'll give it a try.
> 
> Ok, implemented this in PS #2

Ping. Patchset #2 implements bytestream id checking by assigning custom labels
to a/v tracks, so I believe it should be good to land.

[servolk, 2016-07-07 22:06:48]

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

[commit-bot: I haz the power, 2016-07-07 22:07:46]

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

[wolenetz, 2016-07-07 22:14:53]

On 2016/07/07 22:06:40, servolk wrote:
> On 2016/07/01 21:33:19, servolk wrote:
> > On 2016/07/01 21:22:27, servolk wrote:
> > > On 2016/07/01 21:21:34, servolk wrote:
> > > > On 2016/07/01 21:12:47, wolenetz wrote:
> > > > > On 2016/07/01 21:00:24, servolk wrote:
> > > > > > Note that currently bytestream track ids are inaccessible from JS,
so
> > I've
> > > > > > verified manually that indeed bytestream track ids in two source
> buffers
> > > > > match.
> > > > > > But I wonder if we should expose bytestream track ids as one of the
> > media
> > > > > track
> > > > > > properties in addition to the generated unique id.
> > > > > 
> > > > > Hmm. Those bytestream IDs could change throughout the lifetime of a
> track.
> > I
> > > > > wonder therefore how useful. You could use TrackDefaults to enforce
the
> > > > > expectation of bytestream IDs matching (with the risk of TrackDefaults
> API
> > > > being
> > > > > at-risk currently in MSE spec, so may have to revert back to manual
> check
> > on
> > > > > test media if that TrackDefaults is deprecated in Chrome).
> > > > > 
> > > > > e.g. audio bsid 0 in a trackdefault with
> > label='audio-track-with-bs-0-found'
> > > > > (and similar for video), then verify that the trackdefaults apply
> > correctly,
> > > > > therefore proving that the bsid's matched (and were both 0).
> > > > > 
> > > > > WDYT?
> > > > 
> > > > Yes, it's true that bytestream ids might change in subsequent init
> segments,
> > > so
> > > > we should make that very clear and ensure that clients never rely on
bsids
> > > > staying constant. But it just seems weird to me that TrackDefaults might
> be
> > > > assigned based on bsid and not unique ids and yet clients have no direct
> way
> > > to
> > > > see actual bsid values without somehow analyzing the bitstream via third
> > party
> > > > tools.
> > > > And now that you reminded me that bsids might change I've started
> wondering
> > > > about another thing - perhaps we should provide a way to assign
> > TrackDefaults
> > > > based on unique ids and not bsids? Or else TrackDefaults might not apply
> if
> > > they
> > > > specify an explicit bsid value and bsid of the media track changes in
> > > subsequent
> > > > init segments.
> > > 
> > > Oh, and yes, I guess for the short-term solution we could do this bsid
> > > verification via TrackDefaults. I'll give it a try.
> > 
> > Ok, implemented this in PS #2
> 
> Ping. Patchset #2 implements bytestream id checking by assigning custom labels
> to a/v tracks, so I believe it should be good to land.

lgtm. Note: bsid's cannot change if more than 1 track of that track's type
exists in the first initialization segment. So, bsid change is allowed only for
single-track-for-a-type changes. I'm not sure of the benefit of generating
something unique that would supplant the in-band track bsID, nor exposing that
bsID to the app. The latter might especially be confusing it it changes, since
appends can be out-of-order in time versus the set of current tracks for the
media element. And if it changes, there's required to be maximum 1 track of that
type in the appends for that sourcebuffer, so even a degenerate track default
with empty bsID can allow matching and filling in of default label, kinds,
language. If you have a concrete suggestion that would demonstrably help apps,
please file a spec bug :)

Thanks for fixing this and also for making it a more interoperable test.

[servolk, 2016-07-07 22:17:56]

The CQ bit was unchecked by servolk@chromium.org

[servolk, 2016-07-07 22:18:02]

The CQ bit was checked by servolk@chromium.org

[commit-bot: I haz the power, 2016-07-07 22:19: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-07-08 00:11:17]

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

[commit-bot: I haz the power, 2016-07-08 00:11:18]

Try jobs failed on following builders:
  mac_chromium_gyp_rel on master.tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)

[servolk, 2016-07-08 00:11:39]

The CQ bit was checked by servolk@chromium.org

[commit-bot: I haz the power, 2016-07-08 00:12:35]

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-07-08 01:10:01]

Description was changed from

==========
MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993
==========

to

==========
MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993
==========

[commit-bot: I haz the power, 2016-07-08 01:10:02]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-07-08 01:12:01]

Description was changed from

==========
MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993
==========

to

==========
MSE test for two SourceBuffers with clashing bytestream track ids

BUG=624993

Committed: https://crrev.com/ac29e2565ea5d0bb7891297b6160ae26fd6f6a00
Cr-Commit-Position: refs/heads/master@{#404292}
==========

[commit-bot: I haz the power, 2016-07-08 01:12:02]

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