My idea is that we will tie these various pieces together like a filter chain, i.e.
<device> -> [encoder] -> [transport] -> [decoder] -> <video>
where the connections between pieces are made by passing URLs around. (i.e. opening a device yields a URL for a stream, which is supplied to the encoder; at the other end, streams coming from the decoder are identified by a URL, which can then be passed directly to a <video> tag or WebGL texture.)
Other combinations are of course possible, such as direct access to [transport], in the case of a web real-time game, or combining <device> -> encoder -> websocket, for doing live (non-realtime) broadcasts.
We're still figuring out the right interfaces for encoder/decoder; for transport, hopefully the
draft I proposed can serve as a reasonable starting point.
--justinOn Sun, Oct 10, 2010 at 4:26 PM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
That's right, a lot of things remain regarding protocols
and other stuff. But IMHO <device>, StreamAPIs and <audio> and
<video> should be part of the puzzle!
--Stefan
Hi Stefan,
I have seen those, thanks. That's actually the
reason why I asked: because I have already seen it work with the <device>
element and I wondered what the remaining challenges were. It seems there is
lots of discussion about protocols and
codecs.
Cheers,
Silvia.
On Mon, Oct 11, 2010 at 9:49 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com>
wrote:
Silvia,
BR,
Stefan
On 10/09/10 03:17, Silvia Pfeiffer wrote:
Thanks for the general invite!
I wonder: has
the HTML5 device element been looked at (http://dev.w3.org/html5/html-device/) and what are the
problems with that solution?
We're the ones who have to look -
and some on the list have been closely involved with writing the
<device> spec. It would be surprising to me if they are not part of the
solution - but just part.
As far as I know, it's still not clear how to
tie a <device> to a media stream - given that media streams aren't
defined yet, this is not very surprising :-)
Cheers,
Silvia.
On Sat, Oct 9, 2010 at 5:28 PM, David Singer
<singer@apple.com> wrote:
Cool,
thanks Harald
as I said during the day, I'd like to separate (as
much as possible) "why is real-time communications on the internet hard?"
(which is true, but a subject the IETF, the ITU, and others are also
grappling with) from "what is interesting/challenging about real-time
communications *in the web*?" -- which I take to mean in pages shown by a
browser.
On Oct 8, 2010, at 4:24 , Harald Alvestrand
wrote:
> Cullen (I think) has changed the permissions on the
list, so that now everyone can subscribe, and the archives are
open.
>
> If you know of people you think should be on the
list, please ask them to subscribe!
>
> The two ways to
subscribe:
>
> - Send "subscribe" to rtc-web-request@alvestrand.no, and do what the response
says
> - Go to http://www.alvestrand.no/mailman/listinfo/rtc-web and
follow instructions
>
> Let the discussions
begin!
>
>
Harald
>
>
_______________________________________________
> RTC-Web mailing
list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
David
Singer
Multimedia and Software Standards, Apple
Inc.
_______________________________________________
RTC-Web
mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web