On Sun, May 06, 2012 at 10:18:05AM -0500, Jeremy White wrote: > >> So I was thinking that first I'd modify the spice server to support > >> WebSocket directly (http://datatracker.ietf.org/doc/rfc6455/?include_text=1). > > > > > I actually started looking at adding this to the server, I think it's > > not a trivial amount of work but not too much either: > > - need to add the header negotiation (we already have two flows, > > regulat and SASL, this will be a third). > > - need to implement a third pair of read/write functions (already have > > passthrough and ssl). > > I would be thrilled to aid and/or abet you in that effort; let me know > if you want the relevant websockify bits (and javascript so you can test it) - > that would likely be a good place to start. Yes please. > > > > > How will this work with ssl btw? does websocket support a ssl version? > > It requires the support of TSL. OK. We can do that second anyway. > > > > >> > >> > >> 2. Is there an easy way to activate the audio or video streams, > >> ideally from an Xspice test bed? I'd like to see if those > >> streams can be supported by the modern html5 browsers. > > > > There is no video stream, all video data is passed through the display > > channel (maybe we'd want to change that in the future though). > > > > You should already be able to trigger video just by playing a video on > > Xspice (as long as it is larger then some minimal size after 20 frames > > it will be sent as a mjpeg stream) > > Yep, stumbled across that - very slick, btw <grin>. It is, still it has it's share of problems (see the recent patchset by Yonit for fixing a glitch with html5 video). > > Unfortunately, it looks like the browsers are aggressively moving away > from mjpeg, so we'll have to add a new encoders for webm or theora. > The mailing list archives suggest that won't be overly difficult. > May be a bit tricky to support that in the browser; I need to do more > research on that point (the <video> element is great, but requires > the stream source be a url - connecting that url to the spice connection > is what may be challenging). OK, I know Yonit is looking at adding webm support. We also have forever wanted someone to start working on video acceleration, but that requires two major items on both supported platforms - linux drm, windows wddm driver (not requires, more suggests). For Xspice btw I'm really not sure how to do this, other then using hacks like LD_PRELOAD. > > > > > Audio is harder, still TODO for Xspice, nothing there yet. You'll have > > to setup a vm with spice to check that out. > > Right. I have gotten this to work with very simple qemu images > (thanks to your recent 32 bit patches :-) ). OK, great, at least you have a way of testing. > > > > > Video comes to mind as needed, not impossible or hard - you'll need to > > decode jpeg (you said you only do quic so far). > > Yeah, it doesn't appear as though it would be especially hard to support > all the image formats properly, but it will be a fair bit of work. > > > > > copy paste (for this you'll need a vm with spice since Xspice doesn't > > have the agent part implemented) is again important (imo), not hard. > > Ah, another good point. I'll add that to the todo list. Same goes for any other agent message, specifically anything to do with resolution change (so it will resize the guest to the maximal div size in the browser, or even to actual full screen if the browser is fullscreen), and client side mouse (this one is really important in WAN environments, and it's totally cheap computationally). > > Cheers, > > Jeremy > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel