This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21327 - Clarifications required to fading recommendations
Summary: Clarifications required to fading recommendations
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-18 23:36 UTC by Pierre Lemieux
Modified: 2013-04-08 21:15 UTC (History)
3 users (show)

See Also:


Attachments

Description Pierre Lemieux 2013-03-18 23:36:18 UTC
Below are miscellaneous comments and/or questions.

> The fade in coded frame equals new coded frame.

What about if new coded frame duration is less than 5 ms?

> Convert fade out samples and fade in samples to a common
> sample rate and channel layout.

The specification should mandate no sample rate conversion unless necessary.

>Apply a linear gain fade out

From where to where?

> the difference between decode timestamp and last decode timestamp is greater than 100 milliseconds

Why 100 ms?
Comment 1 Adrian Bateman [MSFT] 2013-03-19 14:46:55 UTC
Retitling bug to describe comment.
Comment 2 Aaron Colwell (c) 2013-03-25 21:47:33 UTC
(In reply to comment #0)
> Below are miscellaneous comments and/or questions.
> 
> > The fade in coded frame equals new coded frame.
> 
> What about if new coded frame duration is less than 5 ms?

This is covered in the audio splice rendering algorithm, but I will also add a note in step 13 of the Audio Splice Frame Algorithm calling out this case. I don't want to handle this explicitly in the algorithm because it will just make things unnecessarily confusing.

> 
> > Convert fade out samples and fade in samples to a common
> > sample rate and channel layout.
> 
> The specification should mandate no sample rate conversion unless necessary.

Does this really need to be explictly called out?

> 
> >Apply a linear gain fade out
> 
> From where to where?

What do you mean? If this isn't clear enough please provide text that you consider more clear. I assumed that this plus the picture in the spec was sufficient to convey the intended meaning.

> 
> > the difference between decode timestamp and last decode timestamp is greater than 100 milliseconds
> 
> Why 100 ms?

It seemed like a reasonable default. It is an arbitrary value chosen to ensure that coded frames can't be too far apart before an out-of-order append error is signalled.
Comment 3 Aaron Colwell (c) 2013-03-26 18:02:02 UTC
Changes committed.
https://dvcs.w3.org/hg/html-media/rev/1e6898152c5b

Clarified what to do if 'new coded frame' is less than 5ms long.
Comment 4 Pierre Lemieux 2013-04-04 17:03:36 UTC
> > The specification should mandate no sample rate conversion unless necessary.
> 
> Does this really need to be explictly called out?

Yes.

> > >Apply a linear gain fade out
> > 
> > From where to where?
> 
> What do you mean?

I think the specification should at least recommend a fade in/out slope.

(In reply to comment #2)
> (In reply to comment #0)
> > Below are miscellaneous comments and/or questions.
> > 
> > > The fade in coded frame equals new coded frame.
> > 
> > What about if new coded frame duration is less than 5 ms?
> 
> This is covered in the audio splice rendering algorithm, but I will also add
> a note in step 13 of the Audio Splice Frame Algorithm calling out this case.
> I don't want to handle this explicitly in the algorithm because it will just
> make things unnecessarily confusing.
> 
> > 
> > > Convert fade out samples and fade in samples to a common
> > > sample rate and channel layout.
> > 
> > The specification should mandate no sample rate conversion unless necessary.
> 
> Does this really need to be explictly called out?
> 
> > 
> > >Apply a linear gain fade out
> > 
> > From where to where?
> 
> What do you mean? If this isn't clear enough please provide text that you
> consider more clear. I assumed that this plus the picture in the spec was
> sufficient to convey the intended meaning.
> 
> > 
> > > the difference between decode timestamp and last decode timestamp is greater than 100 milliseconds
> > 
> > Why 100 ms?
> 
> It seemed like a reasonable default. It is an arbitrary value chosen to
> ensure that coded frames can't be too far apart before an out-of-order
> append error is signalled.
Comment 5 Aaron Colwell 2013-04-08 21:15:14 UTC
Changes committed.
https://dvcs.w3.org/hg/html-media/rev/f7f2b7226543

- Made sample rate & channel layout conversion only occur when necessary.
- Specified starting & ending gains for the fades. I think this is a little easier to understand then just specifying a slope since the slope units aren't exactly clear. The gain & time ranges are now specified so implementers should have no problem computing the appropriate slope for their needs.