After all of our dead ends we decided to try cut our losses and throw a “Hail Mary” post to the xuggler-users google group and by some stroke of luck we got an answer within an hour. We probably should have posted to the group sooner, but there was a severe lack of answers being given out so we didn’t really count it as an option before.

Now that we can receive packets my task now is to try and get the important data out of the packet and manipulate and re-encode it. My over all goal is to open a connection to all of the webcams being streamed for a room and then combine them into one stream and send it out again. I don’t really know yet if this will be practical, but I think it’ll be an interesting learning experience.

The other part of the streaming is to re-stream the packets to an HTML5 client. We’ve temporarily decided on re-streaming the video as h.264 over RTP. We don’t yet know if this is viable, but I think it’s our best option. Justin’s tackling the job of trying to find a re-streamer. We can’t use red5 because it only streams as RTMP so we need to find a new avenue. No luck so far, but it’s still early.

Things are finally looking up for our HTML5 client.

The incredibly frustrating part is that there is clearly an entity in the stream as we can see it in flowplayer. We have some potential theories about why Xuggler can’t open the stream:

1. There might not be any metadata contained in the stream and as such Xuggler doesn’t know how to interpret the information
2. The stream only contains video and maybe is hanging waiting for the audio stream

Potential issue #1 is probably the easiest to fix if that’s the cause. We could either send more data when we publish the stream, or tell the container on the client side what kind of information is coming in. Unfortunately our attempts at figuring out how to accomplish either potential solution has failed miserably. If issue #2 is the cause of our woes I don’t really have any idea where we’d go from there. Maybe we could give some empty audio to be passed and solve it that way, I’m not really sure.

This whole week has been filled with set back after set back. Every time we seem to get close to a solution we hit another wall. We have so many great ideas about what to do with the incoming rtmp streams once we can open them, but we can’t even get started.

Hopefully next week some moment of brilliance hits one of us and the solution will be ours.

We’ve been tasked with developing an HTML5 based client on top of BigBlueButton’s existing framework. The first step is to build some sort of mock-up client that can stream the data from an existing server. It’s going to be quite the learning experience as I have a very limited knowledge of the technologies we’re going to be working with. We got this task on Thursday, basically at the end of the day, so I didn’t get to work on it till Friday. I was the only one here as both Fardad and Justin were off for the day, so I decided to task myself with trying to figure out how the webcam streaming currently functions in the existing flash client. I figured that the webcams would likely be the hardest part of the whole endeavour so I figured tackling that first would be best.

I eventually figured out that the webcams stream through our red5 media server. It’s all seems pretty simple to understand. A webcam stream is passed in and then any other client can request the streams being sent to the server. The problem.. red5 is a flash media streaming server. Yay Flash. I did some more digging and it turns out some time recently (the documentation is pretty abysmal) red5 was updated to allow for an h.264 outstream as well. How this can be actually implemented on our server I have absolutely no idea.

As mentioned before, the documentation is pretty bad. All the forum posts and stackexchange threads on red5 and h.264 seem to start and die April, 2011. I have yet to find a thread from later then that date and it is very frustrating. And that’s where I stopped for the week.

I’m hoping I can come upon some magical source that will tell me it’s even possible to receive a stream as h.264 this week.

Because the technology is so new and still in an unreleased state you have to jump through some hoops to get it enabled and working. First, you can only use it with Google Chrome. It also must be a Dev-Channel or Canary version of Chrome. Second, you have to enable a special flag here at the very bottom called “Enable MediaStream.” This enables the WebRTC api to get your audio and video feeds. One of the more flashy demos is here, it combines WebGL with WebRTC for a moveable real time video feed.

I have a problem with my machine here at CDOT though. Our machines are set up with Ubuntu 10.04, because of this we’ve had a hell of a time trying to find webcams that are actually compatible with our os. So I can’t actually run the demos or play around with the api from my machine. I have to develop on my desktop and actually test it on the Macbook Pro *blech* that I have signed out. It’s a real pain in the ass, but it’s all I have to work with.

On the WebRTC site it also said to install a development version of Chromium, but after following all of the install steps and getting all of the dependencies I can’t build it… because I have less then 2 gigs of RAM. WOW. So I’m not sure what I’m going to do about that. I’ll have to find another solution I guess.

After talking with Fred the cause of our issue was finally nailed down.

If you’re having issues with the audio on your BBB server run the commands; sudo bbb-conf –clean; sudo bbb-conf –clean. If you see the following line in the output of the clean command following the steps below could very well resolve your issue.

# Error: File not found: /usr/share/red5/webapps/sip/WEB-INF/bigbluebutton-sip.properties

*Steps for fixing the above error*

sudo service red5 stop
sudo apt-get install bbb-apps-sip
sudo chmod -R o+w /usr/share/red5/webapps
cd ~/dev/bigbluebutton/bigbluebutton-apps
gradle clean war deploy
sudo service red5 start

Hopefully that fixes your issue and doesn’t cause others.

We want the landing page to instead be our authenticating module so as to restrict and control access to our server on our own terms. The current solution that we came up with is to just put in a simple javascript redirect that, as soon as the demo landing page is loaded, redirects the user to our /auth webapp. We achieve this by editing the file located at “/var/www/bigbluebutton-default/index.html” and adding the following lines inside the body of the page.

<script type="text/javascript">
  window.location = "/auth";
</script>

The solution above is kind of a hacked together one, and it’s not really all that elegant of a solution, but it works. I’ve been meaning to look into other ways of achieving our goals, but right now there isn’t enough time to delve deep.

Finally I figured it out the solution. My colleague Justin suggested to search the dev forum for BBB for similar issues (I probably should have done that days ago) and it turns out that BBB has a program nginx set up as a sort of proxy for the tomcat server. I still don’t fully understand why they have it set up this way. Anybody connecting to our server goes through port 80, but only the bigbluebutton app can actually be accessed through this port so you have to create a file that redirects the call to your new app to port 8080. Luckily they already have a file for this for a demo app that comes with the development environment for BBB, so I could just copy the file and change the name inside the file from demo to new_app and now it works.

I don’t fully understand how it works, nor why it’s setup this way, but it works now and finally I can move to something more meaningful.

It seems to me that there’s some sort of back end issue with associations. (I don’t have any clue about how it’s set up).

I figured I should be able to reskin the RadioButtons to something more conventional. I looked online and found a few examples of the properties I need to alter in order to change the skin, “upIcon”, “downIcon”, “overIcon”, “selectedUpIcon”, “selectedDownIcon”, “selectedOverIcon”. I tried changing the value of these values for RadioButtons, but it just resulted in breaking my function.

I then tried to alter the same properties, but for CheckBoxes. They have the exact same properties and my attempts to change them worked perfectly. Figures.

My next thought was, “Well if they look like Buttons maybe they have the same properties”. I found out that for Buttons instead of “upIcon” they have “upSkin.” Tried that, same result.

At this point I’m quite stumped. I don’t really know what else to try other then trying to go through the code that covers how Flex is connected with BBB because there must be some sort of issue there.

I’m looking forward to working with Justin, Anatoly and Fardad this semester.