About video and voice for BBB-HTML5

684 views
Skip to first unread message

tran tuan duong

unread,
Jan 11, 2013, 10:53:22 PM1/11/13
to bigblueb...@googlegroups.com

I have been closely following the development of BBB-HTML5. I learn that BBB-HTML5 hasn’t got voice and video modules yet. I would like to know which voice and video modules BBB-HTML5 will use, and when you plan to integrate these two modules in BBB-HTML5. Besides, at present, can Firefox, Opera, IE browsers use HTML5 to share voice and video?


Fred Dixon

unread,
Jan 11, 2013, 11:13:41 PM1/11/13
to BigBlueButton-dev
Hi Tran,

We give an overview of how we will integrate voice and video in HTML5 in the following document


You can see the three phases of development of the HTML5 client:

1. Support viewing a live session using an HTML5 browser
2. Support broadcasting audio/video from an HTML5 browser using WebRTC
3. Support all presentation features of BigBlueButton in HTML5

We're working on Phase 1 now, in parallel to development of 0.81, with the intent of merging the support for an HTML5 client into BigBlueButton's core subsequent to the release of 0.81.  

Phase 1 covers the viewing of a live session and will provide the user with two-way chat, viewing of slides, and one-way streaming audio and video.  More specifically, we'll stream audio from FreeSWITCH and video from red5 into a format (probably VP8) that can be viewed on an HTML5 browser.  There is no one audio and video format that will cover all browser.  It's a bit of a mess, see


We'll stick with open source audio and video codecs in BigBlueButton.   

Sharing (publishing from a browser) audio and video is equally tricky.  Removing Flash from the equation, we must rely on what the browser provides to broadcast an audio and video stream to the server.  We're looking at doing this with WebRTC in Phase 2, but will only give us support -- at the moment -- for Google Chrome and Mozilla FireFox (and I should add Opera as well).  Also, WebRTC is currently designed for peer-to-peer applications, but we really need a server-centric application to enable recording of the session.

There will be support for WebRTC from IE, but it's not clear yet.  And Apple has not indicated any support for WebRTC in iOS.  Apple really wants you to write a native iOS application, which we have on our roadmap, but doing so is outside the scope of HTML5.

From some perspectives, when you look at the challenges above, Flash still looks pretty good.  It's providing all of the audio/video support and framework for Mac, Unix, and PCs.  However, there is a very large market out there for non-Flash devices.  We're not abandoning Flash in any way with our efforts to support HTML5; rather, it's adding another entry point to BigBlueButton.


Regards,... Fred
-- 
BigBlueButton Developer
BigBlueButton on twitter: @bigbluebutton


On Fri, Jan 11, 2013 at 10:53 PM, tran tuan duong <trandu...@gmail.com> wrote:

I have been closely following the development of BBB-HTML5. I learn that BBB-HTML5 hasn’t got voice and video modules yet. I would like to know which voice and video modules BBB-HTML5 will use, and when you plan to integrate these two modules in BBB-HTML5. Besides, at present, can Firefox, Opera, IE browsers use HTML5 to share voice and video?


--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/-18ykwO8gd8J.
To post to this group, send email to bigblueb...@googlegroups.com.
To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.




tran tuan duong

unread,
Jan 11, 2013, 11:58:42 PM1/11/13
to bigblueb...@googlegroups.com
Thanks Fred answer my question,

When I find out about audio / video streamming I found simp5 (detail http://www.sipml5.org/ ) .Will we be able to use them to the BBB?

Vào 11:13:41 UTC+7 Thứ bảy, ngày 12 tháng một năm 2013, Fred Dixon đã viết:

ronghester

unread,
Jan 15, 2013, 1:49:43 AM1/15/13
to bigblueb...@googlegroups.com
Hi Fred,

peer-to-peer applications, vs server-centric application (just for sake of discussion)

When I first heard about BigBlueButton HTML 5 client I was thinking that it will be a self contained HTML 5 application. I though so; because  It is easier to develop such thing with given technologies nodejs/HTML5/webrtc. When I saw it is tightly coupled with current BBB server architecture (which was necessary for flash) I was worried about the feasibility  and performance of this client. 

WebRTC is best known for its peer-to-peer communication. Involving the server fly in webrtc based client might hamper the performance of the application. I might be wrong please correct. Looking at the HTML 5 architecture one can tell it is a lot of work going on the server. Current HTML 5 Client Architecture is difficult to implement (by difficult I mean More time consuming) and HTML 5-Web technologies are still evolving. So coupling so tightly with flash or back end server does not sounds a good idea. There might be better ways to couple these two in future. 

A self contained HTML 5 client would be easier for people to install, test and develop. It could stay as BBB- HTML 5 Branch until it gets mature and then we could merge it. Those who wants HTML 5 Client flash is not necessary for them they can access it from Browser (on their computer) and Any other HTML 5 supported platform.

If we are fearing that having HTML 5 port of BBB will attract more attention (because it is so exciting and bleeding age and everybody wants to jump into it) and as a result BBB-Flash will get sideline then I don't agree. It Is the most stable open source meeting platform and everyone knows what it is capable of so there is no question of dumping it. I don't know of any successful (or popular) meeting or classroom environment implemented in HTML 5 (there are whiteboards all over the place but I am saying a complete). 

To summarize, I think that a self contained (peer-to-peer) architecture would be better choice for HTML 5 client until it gets matured. 
If any of this make sense Is it possible to have two implementation of HTML 5 client ?

Thanks
ronghester

Fred Dixon

unread,
Jan 15, 2013, 9:09:21 AM1/15/13
to BigBlueButton-dev
Hi Tran,

Thanks for your feedback.  We plan to use WebRTC for accessing the user's webcam and microphone, but not for a peer-to-peer architecture.  For BigBlueButton to record a session, the audio and video streams must pass through the server.  

Fundamentally, a user of BigBlueButton doesn't care how it's implemented, only that it's stable, usable, and supports the core set of features they need to do their job.  WebRTC has started as peer-to-peer, but it will also support, in time, server-centric communications.  It's the latter that we need for BigBlueButton.

A self contained HTML 5 client would be easier for people to install, test and develop.

That would be a very different BigBlueButton.  No API.  No conversion of slides.  Limited to a few users (you are not going to scale P2P to 25 simultaneous users, not for a while).  In fact, if we tried to go down that road of a self-contained HTML5 product, it would really be a separate product, which wouldn't be (any where near) as valuable to our community as enhancing BigBlueButton itself.

ronghester

unread,
Jan 15, 2013, 12:35:07 PM1/15/13
to bigblueb...@googlegroups.com

Hi,

I didn't mean to hijack this thread, I saw the peer-to-peer and centralize server discussion so I jumped in. I know the decision must have been well thought through, I just wanted to understand the reasons behind it. Also the bold title was misleading sorry about that. 

From BBB as a product stand point It make sense to hook HTML 5 client from beginning into existing server architecture. That makes it a complete product. My Point was is that tight coupling going to be a bottle neck for performance of HTML 5 client. 

Agree Peer to Peer connection works best with limited participant and less data transfer. It is going to be low latency and high throughput as compared to flash and all that without touching your server bandwidth. This I think is main advantage of WebRTC (Not sure what RTCDataChannel API will bring to the table) which can also be leveraged in high usage situation with use of centralized server. By centralized server I mean a simple node.js server the same which will be used for chat and whiteboard event, which can be further extended to store audio stream for later use in recording. As you pointed out; in that case it will be a different solution all together. 

Thanks

ofer kruzel

unread,
Jan 15, 2013, 2:23:13 PM1/15/13
to bigblueb...@googlegroups.com
Hi Fred,
I am following on HTML5 client for some time and specifically interested in video + audio support for multiple participant web based video conf app.
Looking at the architecture diagram I see you plan to have the video and audio go thru codec conversion then thru webM server.
I understand the need for native browser support.

my question is what is the target additional latency you expect to have? 

Thanks and keep up the good work,
Ofer

Fred Dixon

unread,
Jan 15, 2013, 2:55:14 PM1/15/13
to BigBlueButton-dev
Hi Ofer,

my question is what is the target additional latency you expect to have?

We're still prototyping the application and don't have any metrics to share yet on latency.  We obviously want to make it as low as possible.  There will likely be different sets of latency, depending on how one connects.

If a user connects through an HTML5 client this is receiving a stream of data (such as what we're building in Phase 1), then there will be buffering on the streaming server.  We're currently prototyping using the GStreamer Streaming Server (http://gstreamer.freedesktop.org/) for streaming to remote HTML5 clients.  See


If a user connects using a desktop browser that supports WebRTC (as we plan for Phase 2), we expect their latency to be much less than receiving an audio/video broadcast through a streaming server.

Lots of work ahead of us on prototyping/implementing an HTML5 client.  As with BigBlueButton, our priorities for implementing the HTML5 cliednt are stability, usability, and implementation of core features (in that order). 


Regards,... Fred
-- 
BigBlueButton Developer
BigBlueButton on twitter: @bigbluebutton
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/DJXHAWb3EZMJ.
Reply all
Reply to author
Forward
0 new messages