Re: [MSE] MPEG audio byte stream format spec.

Hi Jerry,

I agree with your points here. I was not overly excited about the
"segments" mode behavior myself, but I wasn't sure how sensitive people
would be to changes in the algorithms if they never intended to support
MP3. Since we're likely going to have to go back to LC anyways, I'm
definitely open to making changes so that this has more consistent behavior
and is actually included in the MSE spec. Based on your comments, here is
what I propose.

1. Creating some sort of "byte stream has timestamps flag" that byte stream
format specs explicitly specify as being true or false. MP4, MP2TS, and
WebM would all specify this at true and things like raw MP3 and ADTS would
specify false.
2. When "byte stream has timestamps flag" is false, SourceBuffer.mode will
default to "sequence". Otherwise it will default to "segments" like it does
today.
3. When "byte stream has timestamps flag" is false, setting
SourceBuffer.mode to anything other than "sequence" will throw an
InvalidAccessError like we do for other types of invalid input.
4. When "byte stream has timestamps flag" is false, steps 1.1 & 1.2 of
the coded
frame processing
algorithm<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#sourcebuffer-coded-frame-processing>
will
specify the presentation timestamp and decode timestamp to be 0.
5. Add a step 1.23 that sets timestampOffset to frame end timestamp


On Mon, Apr 21, 2014 at 5:21 PM, Jerry Smith (WINDOWS) <
jdsmith@microsoft.com> wrote:

>  Aaron:
>
>
>
> We’ve reviewed this document at Microsoft and think it’s very useful.
> Thanks.
>
>
>
> We do have one topic to discuss:  On other formats, timestampOffset is not
> modified internally when the sourceBuffer is set to “segments” append
> mode.   It seems that timestampOffset shouldn’t get updated for one format
> and not for others.  The website using MSE is not likely to care as much
> about which format is being used, but does need to care about
> timestampOffset as it is part of the API.
>
>
>
> We suggest that sourceBuffer be restricted to operate in “sequence” append
> mode only for these byte stream formats.   Sequence append mode already
> handles updating the timestampOffset (although there may need to be some
> edits to state that the coded frame duration should be used rather than the
> presentation timestamp if the byte stream format does not carry timestamp
> information).
>
>
>
> Regards,
>
>
>
> Jerry
>
>
>
> *From:* Aaron Colwell [mailto:acolwell@google.com]
> *Sent:* Monday, March 31, 2014 2:36 PM
> *To:* <public-html-media@w3.org>
> *Subject:* [MSE] MPEG audio byte stream format spec.
>
>
>
> I just wanted to let people know that I just posted a draft of the MPEG
> audio byte stream format spec<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/mpeg-audio-byte-stream-format.html> that
> Chrome has been experimenting with for a while. It allows MP3 & ADTS
> streams to be used with MSE.
>
>
>
> Assuming that there are no major objections, I'd like to add it to the byte
> stream format registry<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/byte-stream-format-registry.html> in
> the next week or two.
>
>
>
> Aaron
>