Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaElementSource should contain all Tracks as outputs #132

Closed
olivierthereaux opened this issue Sep 11, 2013 · 10 comments

Comments

Projects
None yet
6 participants
@olivierthereaux
Copy link
Contributor

commented Sep 11, 2013

Originally reported on W3C Bugzilla ISSUE-17345 Tue, 05 Jun 2012 11:37:40 GMT
Reported by Philip Jägenstedt
Assigned to

Audio-ISSUE-54 (MediaElementAudioSourceNode): MediaElementAudioSourceNode [Web Audio API]

http://www.w3.org/2011/audio/track/issues/54

Raised by: Philip Jägenstedt
On product: Web Audio API

HTMLMediaElement is integrated into Web Audio API using the MediaElementAudioSourceNode interface and createMediaElementSource. This looks like an unnecessarily complicated way of making the connection.

Suggestion:

Extend the HTML AudioTrack interface [1] with an "AudioSourceNode node" member. This allows us to use multiple audio tracks from a single HTMLMediaElement.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#audiotrack

@olivierthereaux

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2013

Original comment by Chris Rogers on W3C Bugzilla. Tue, 16 Oct 2012 20:19:21 GMT

Ian Hickson and I had discussed the trade-off of these two approaches a while back. He suggested that with the current approach (with create() method) that we can keep the two APIs well-factored, and not need to change the HTMLMediaElement spec.

Also, I don't think that the create() approach is very complex at all. It's true that it adds one more line of JS, but this is a very small cost and it's consistent with other source nodes such as createBufferSource().

We've already had plenty of people using this API, and nobody has complained about this particular aspect.

@olivierthereaux

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2013

Original comment by Olivier Thereaux on W3C Bugzilla. Wed, 24 Oct 2012 09:27:32 GMT

Philip, any thought given the recent changes in http://dvcs.w3.org/hg/audio/rev/9224fb26e77d ?

@olivierthereaux

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2013

Original comment by Philip Jägenstedt on W3C Bugzilla. Wed, 24 Oct 2012 09:42:37 GMT

That change was in response to Bug 17346 and looks fine to me.

As for createMediaElementSource() vs a property on AudioTrack, I'm fine with keeping a create method for consistency and API separation.

What remains unresolved is the issue of multi-track resources. If instead of a createMediaElementSource we had a createAudioTrackSource, the issue of what to do with media elements without any audio goes away, and it's also possible to process the audio streams separately. Should I file a new bug for this?

@olivierthereaux

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2013

Original comment by Olivier Thereaux on W3C Bugzilla. Wed, 24 Oct 2012 09:47:41 GMT

(In reply to comment #3)

What remains unresolved is the issue of multi-track resources. If instead of
a createMediaElementSource we had a createAudioTrackSource, the issue of
what to do with media elements without any audio goes away, and it's also
possible to process the audio streams separately. Should I file a new bug
for this?

Makes sense. Let's keep it here - care to change/clarify the issue name? (If you can... not sure what the typical Bugzilla rights are these days)

@olivierthereaux

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2013

Original comment by Philip Jägenstedt on W3C Bugzilla. Wed, 24 Oct 2012 11:14:48 GMT

OK, reopened and changed name.

@cwilso

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2014

Why shouldn't we just have multiple outputs on the MediaElementSourceNode, one per track? Related: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26534.

@joeberkovitz

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2014

TPAC resolution: for both MediaElements and MediaStreams (see #264) we will keep the current nodes and [stream/element-based] factory methods, define "first" as a stable function of track ID (since the IDs are stable), and expose new track-based factory methods that produce the same nodes, but based on the single passed-in track.

@cwilso

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2014

Actually, for MediaElements, additional outputs to the node will represent other tracks as well. The track-based factory method would be for Streams.

@cwilso cwilso added this to the Web Audio Last Call 1 milestone Oct 29, 2014

@cwilso cwilso changed the title Access to individual AudioTracks MediaElementSource should contain all Tracks as outputs Oct 30, 2014

@adorn

This comment has been minimized.

Copy link

commented Nov 12, 2014

See also #352

@joeberkovitz

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2016

Closing since the TPAC 2014 resolution was implemented and adding more outputs to the node does not heklp the developer distinguish one audio track from another on a meaningful basis. Developers can already control the active track of an HTMLMediaElement and thus affect which track will be piped into the MediaElementSourceNode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.