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> 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> 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
>>
>
>