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

Hi Aaron;

This change looks good, and completely addresses the discussion topic I raised.  Thanks.

Jerry

From: Aaron Colwell [mailto:acolwell@google.com]
Sent: Thursday, April 24, 2014 11:01 AM
To: Jerry Smith (WINDOWS)
Cc: <public-html-media@w3.org>
Subject: Re: [MSE] MPEG audio byte stream format spec.

Oops. Hit "send" too early.

Item 5 should have been conditional.
5. Add a step 1.23 that sets timestampOffset to frame end timestamp if "byte stream has timestamps flag" is false.

I believe these changes would address your concerns and allow timestampOffset to always reflect the start position of the next append while preserving the existing behavior for all other formats. Please let me know what you think so I can file a bug and make the appropriate changes.

Aaron

On Thu, Apr 24, 2014 at 10:56 AM, Aaron Colwell <acolwell@google.com<mailto:acolwell@google.com>> wrote:
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<mailto: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<mailto:acolwell@google.com>]
Sent: Monday, March 31, 2014 2:36 PM
To: <public-html-media@w3.org<mailto: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