Re: [MSE] Alternate proposal for resolving Bug 24370

HI Aaron,

I think the proposal works but I think that byteStreamTrackID should be
optional in the case that only one set of default track settings is
provided. In that case, if there is only one track in the stream, it gets
the provided defaults and if there is more than one track in the stream the
defaults are ignored.

This would avoid the need to know the byteStreamTrackID for the common case
where there is only one track for each SourceBuffer.

...Mark



On Fri, Apr 25, 2014 at 7:25 AM, Aaron Colwell <acolwell@google.com> wrote:

> On Thu, Apr 24, 2014 at 9:46 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> On Fri, Apr 25, 2014 at 2:32 PM, Aaron Colwell <acolwell@google.com>
>> wrote:
>> >
>> > No. The web application adds default information to the
>> trackDefaultList on
>> > the SourceBuffer. The SourceBuffer code consults these defaults when
>> data
>> > gets appended that would result in xxxTrack objects getting created (ie
>> when
>> > the initialization segment received algorithm is invoked.)
>>
>> OK, thanks, I get it. Why would .trackDefaults be in every
>> SourceBuffer object rather than just in the MediaSource ?
>>
>
> Because different SourceBuffer objects can have byte streams that contain
> the same underlying byteStreamTrackID and there would be no way to
> differentiate the two.
> For example, in the case were a SourceBuffer is used for the audio track
> and a different SourceBuffer is used for the video track, it is highly
> likely that the track in each byte stream will have a byteStreamTrackID of
> '1' because in each case there is only 1 track. Putting the defaults on the
> MediaSource would require specifying a SourceBuffer parameter to
> TrackDefaultList to disambiguate this case, which seems a little odd to me
> since this is really a matter that is internal to the SourceBuffer and not
> a MediaSource wide concern.
>
> Aaron
>
>
>>
>> Silvia.
>>
>
>