Re: [whatwg] Gapless playback problems with web audio standards
On Sun, Oct 26, 2014 at 2:30 AM, David Kendal m...@dpk.io wrote: Hi, http://w3.org/mid/10b10a1d-8b84-4015-8d49-a45b87e4b...@dpk.io Web Audio should be usable for this. If it doesn't work due to brower bugs, we should fix the browser bugs. I know we've fixed bugs related to this in Firefox this year so I'd like to know if obvious techniques still don't work. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] Gapless playback problems with web audio standards
On 27 Oct 2014, at 12:08, Robert O'Callahan rob...@ocallahan.org wrote: Web Audio should be usable for this. If it doesn't work due to brower bugs, we should fix the browser bugs. I know we've fixed bugs related to this in Firefox this year so I'd like to know if obvious techniques still don't work. Can you suggest an ‘obvious technique’ I don’t describe in my email? Given that none of the techniques there work even remotely directly with samples, but rather with approximate durations, I don’t see how it’s possible to get sample-accurate transitions. Silvia Pfeiffer suggested using Media Source Extensions, which looks more promising, but I don’t see how they can be used to ‘join’ the samples from two different audio files into the same buffer. Rob dpk
Re: [whatwg] How to expose caption tracks without TextTrackCues
On Sun, Oct 26, 2014 at 8:28 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Thu, Oct 23, 2014 at 2:01 AM, Philip Jägenstedt phil...@opera.com wrote:
On Sun, Oct 12, 2014 at 11:45 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Hi all,
In the Inband Text Tracks Community Group we've recently had a
discussion about a proposal by HbbTV. I'd like to bring it up here to
get some opinions on how to resolve the issue.
(The discussion thread is at
http://lists.w3.org/Archives/Public/public-inbandtracks/2014Sep/0008.html
, but let me summarize it here, because it's a bit spread out.)
The proposed use case is as follows:
* there are MPEG-2 files that have an audio, a video and several caption
tracks
* the caption tracks are not in WebVTT format but in formats that
existing Digital TV receivers are already capable of decoding and
displaying (e.g. CEA708, DVB-T, DVB-S, TTML)
* there is no intention to standardize a TextTrackCue format for those
other formats (statements are: there are too many formats to deal
with, a set-top-box won't need access to cues)
The request was to expose such caption tracks as textTracks:
interface HTMLMediaElement : HTMLElement {
...
readonly attribute TextTrackList textTracks;
...
}
Then, the TextTrack interface would list them as a kind=captions,
but without any cues, since they're not exposed. This then allows
turning the caption tracks on/off via JavaScript. However, for
JavaScript it is indistinguishable from a text track that has no
captions. So the suggestion was to introduce a new kind=UARendered.
My suggestion was to instead treat such tracks as burnt-in video
tracks (by combination with the main video track):
interface HTMLMediaElement : HTMLElement {
...
readonly attribute VideoTrackList videoTracks;
...
}
Using the VideoTrack interface it would list them as a kind=captions
and would thus also be able to be activated by JavaScript. The
downside would that if you have N video tracks and m caption tracks in
the media file, you'd have to expose NxM videoTracks in the interface.
So, given this, should we introduce a kind=UARendered or expose such
tracks a videoTracks or is there another solution that we're
overlooking?
VideoTrackList can have at most one video track selected at a time, so
representing this as a VideoTrack would require some additional
tweaking to the model.
The captions video track is one that has video and captions rendered
together, so you only need the one video track active. If you want to
turn off captions, you merely activate a different video track which
is one without captions.
There is no change to the model necessary - in fact, it fits perfectly
to what the spec is currently describing without any change.
Ah, right! Unless I'm misunderstanding again, your suggestion is to
expose extra video tracks with kind captions or subtitles, requiring
no spec change at all. That sounds good to me.
Philip
Re: [whatwg] Gapless playback problems with web audio standards
Hi, Chrome developer here, gapless playback should work with both WebAudio and Media Source Extensions (MSE). I've fixed bugs in both implementations, so if you have some test cases in Chrome that fail, I'd love to see them. As luck has it, I've recently put an article together on how to use MSE for gapless playback: http://dalecurtis.github.io/llama-demo/index.html We'll be posting it to HTML5Rocks in the near future. Feel free to contact me if you have any questions. You also note that setTimeout() is not precise enough for your usage; you should take a look at the WebAudio scheduler or using WebWorkers: http://www.html5rocks.com/en/tutorials/audio/scheduling/ https://github.com/chrisguttandin/worker-timers If you only need your project to work in the foreground using requestAnimationFrame is also an option. I'd first try to schedule as much as you can in advance though. - dale
[whatwg] Markup-related feedback
On Fri, 24 Jan 2014, Jukka K. Korpela wrote:
2014-01-22 2:28, Ian Hickson wrote:
On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
Thank you for the clarifications. I may have been stuck to an idea
of a submittable element, possibly adopted from some earlier version
or proposal. I think an explicit short note like The output element
is not submittable would be useful.
I am reluctant to add that kind of comment for a couple of reasons.
First, there's the problem of determining when one would add these
notes. Should the spec be explicit about everything it doesn't say?
No, but it should be explicit about things that could easily be
misunderstood.
Fair enough. I've added some text to this effect.
What I would rather do is clarify whatever led to the confusion in the
first place. Do you have any idea what it is in the output section
that might lead you to think that it would be submittable?
Well, it is under the heading 4.10 Forms. As an element for the result
of some scripted operation (which output seems to be meant for),
output need not have anything to do with forms. But when it is under
Forms, a natural idea is oh, this is for some computed value, like a
total, to be submitted.
In the sentence I added, I added a mention of why there's a relationship
to forms.
(A submittable output element would a natural thing to have in many
cases, e.g. in showing some calculated total to the user and
submitting it along with form data, for checking purposes.)
Can you elaborate on this use case? I'm not sure how it would work.
When you calculate the total with JavaScript, mainly to be shown to the
user, you might as well submit it along with the form, as an extra
check. If it does not match the total calculated in the server,
something went very wrong. What you do then is a different question, but
the important thing is that you detect a problem, instead of charging an
amount that differs from what the user saw.
Fair enough. You can do this with type=hidden, for what it's worth.
The main reason for not submitting it so far has been that it would
risk authors relying on the client's computation and thus not doing it
on the server,
Authors often rely too much on checks and computations made client-side
- including new features like @pattern and @required attributes and new
values of the @type attribute. They have always been able to do that
with calculated totals, for example - just using an input element
(possibly with @readonly).
Right. But this makes it easier.
Without name=, the main purpose of output -- making it easy to
update non-form-control values in script -- is lost.
The @name attribute in general, except for submittable controls, is
legacy markup that has caused much confusion. It was introduced long
ago, before @id was added to HTML, for scripting purposes, on @img and
@form, as well as on @a for link destinations, but it was unsuitable
from the beginning. It was not defined to be unique in the document, and
there have been many attempts to phase out/deprecate/obsolete @name
(except for submittable fields, where it need not be unique).
So it looks a bit odd to introduce @name for a new element.
What you say is true for some uses of name=, but in the form API in
particular, name= works pretty well, due to the elements object.
Consider what this would look like without the form.elements API:
form name=main
Result: output name=result/output
script
document.forms.main.elements.result.value = 'Hello World';
/script
/form
With output id=result/output, it would have
document.getElementById('result').value = 'Hello World'
and if jQuery is used (and more than half of the world uses it, or
something similar), it would have
$('#result') = 'Hello World'
I would say that both ways are simpler than the property chain
document.forms.main.elements.result.value and, moreover, a way that can
be used to access any element, not just output.
I guess this is an area where opinions differ.
Well, more or less by definition, [if] output is appropriate for
something, it's more appropriate than span would be, since span is
more generic. span is like the fall back element, it has
essentially no semantics at all.
That's a rather theoretical proposition. You say that output is for a
result of a calculation or user agent and call this semantics.
That's basically how that works, yes. :-)
But how would that be a tangible benefit.
The main benefit is the one I describe above, the way it interacts with
the form elements API. The benefit of the semantics is the same as the
benefits of any semantics, mainly that it makes code maintenance easier,
makes it easier for new authors to enter a project and know what's going
on, etc.
I think the improvement of o relative to
document.getElementById('o') should be
Re: [whatwg] How to expose caption tracks without TextTrackCues
On Tue, Oct 28, 2014 at 2:41 AM, Philip Jägenstedt phil...@opera.com wrote:
On Sun, Oct 26, 2014 at 8:28 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Thu, Oct 23, 2014 at 2:01 AM, Philip Jägenstedt phil...@opera.com wrote:
On Sun, Oct 12, 2014 at 11:45 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Hi all,
In the Inband Text Tracks Community Group we've recently had a
discussion about a proposal by HbbTV. I'd like to bring it up here to
get some opinions on how to resolve the issue.
(The discussion thread is at
http://lists.w3.org/Archives/Public/public-inbandtracks/2014Sep/0008.html
, but let me summarize it here, because it's a bit spread out.)
The proposed use case is as follows:
* there are MPEG-2 files that have an audio, a video and several caption
tracks
* the caption tracks are not in WebVTT format but in formats that
existing Digital TV receivers are already capable of decoding and
displaying (e.g. CEA708, DVB-T, DVB-S, TTML)
* there is no intention to standardize a TextTrackCue format for those
other formats (statements are: there are too many formats to deal
with, a set-top-box won't need access to cues)
The request was to expose such caption tracks as textTracks:
interface HTMLMediaElement : HTMLElement {
...
readonly attribute TextTrackList textTracks;
...
}
Then, the TextTrack interface would list them as a kind=captions,
but without any cues, since they're not exposed. This then allows
turning the caption tracks on/off via JavaScript. However, for
JavaScript it is indistinguishable from a text track that has no
captions. So the suggestion was to introduce a new kind=UARendered.
My suggestion was to instead treat such tracks as burnt-in video
tracks (by combination with the main video track):
interface HTMLMediaElement : HTMLElement {
...
readonly attribute VideoTrackList videoTracks;
...
}
Using the VideoTrack interface it would list them as a kind=captions
and would thus also be able to be activated by JavaScript. The
downside would that if you have N video tracks and m caption tracks in
the media file, you'd have to expose NxM videoTracks in the interface.
So, given this, should we introduce a kind=UARendered or expose such
tracks a videoTracks or is there another solution that we're
overlooking?
VideoTrackList can have at most one video track selected at a time, so
representing this as a VideoTrack would require some additional
tweaking to the model.
The captions video track is one that has video and captions rendered
together, so you only need the one video track active. If you want to
turn off captions, you merely activate a different video track which
is one without captions.
There is no change to the model necessary - in fact, it fits perfectly
to what the spec is currently describing without any change.
Ah, right! Unless I'm misunderstanding again, your suggestion is to
expose extra video tracks with kind captions or subtitles, requiring
no spec change at all. That sounds good to me.
Yes, that was my suggestion for dealing with UA rendered tracks.
Cheers,
Silvia.
Re: [whatwg] Gapless playback problems with web audio standards
On Tue, Oct 28, 2014 at 1:13 AM, David Kendal m...@dpk.io wrote:
On 27 Oct 2014, at 12:08, Robert O'Callahan rob...@ocallahan.org wrote:
Web Audio should be usable for this. If it doesn't work due to brower
bugs, we should fix the browser bugs. I know we've fixed bugs related to
this in Firefox this year so I'd like to know if obvious techniques still
don't work.
Can you suggest an ‘obvious technique’ I don’t describe in my email? Given
that none of the techniques there work even remotely directly with samples,
but rather with approximate durations, I don’t see how it’s possible to get
sample-accurate transitions.
Durations are floating point, and browsers should round them to the nearest
sample boundary, so there shouldn't be a problem there.
If you have a set of AudioBuffers that you want to play gaplessly, you
should just be able to do this:
var audioBuffers = ...;
var audioContext = new AudioContext();
var t = 0;
for (var i = 0; i audioBuffers.length; ++i) {
var node = audioContext.createBufferSource();
node.buffer = audioBuffers[i];
node.start(t);
t += buffer.duration;
}
For best results the audioBuffers' sample rate should match the sample rate
of audioContext, though I think Firefox should work even when that's not
the case.
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
