Some time ago I noted the availability of installable audio metering for Windows. Today I stumbled upon a similar free application called “VUMeter” that provides old school stereo VU meters.
The meters can be resized from 50%, 100% or 200% of normal size, where normal size is 1500 x 300 pixels.
They can be set to stay on top of all windows. They can also be set to display the signal from any available sound recording or playback device.
The prior two installments in this series dealt with interconnecting an audio conference bridge and a Google+ Hangout-On-Air. The Hangout-On-Air allows a limited number of interactive participants with no connectivity to the PSTN. The audio conference allows audio-only participants, including both access via the PSTN and direct SIP connections. The combination allows more people to participate, which is ideal. The fact that it supports HDVoice is also great.
Nice as that solution is, it hasn’t addressed another facet of how we’ve been doing VUC calls. I’ve been struggling with an arrangement for adding production audio to the call along with my own participation. By “production audio” I mean things like a pre-recorded opening or closing, or anything else that might enhance the presentation.
It’s worth noting that a Google “Hangout” is not the same as a “Hangout-On-Air.” A Hangout-On-Air is streamed and recorded via YouTube in real-time. This gives it the potential for much greater reach. A normal Hangout is not streamed in this manner, although it does allow for PSTN connectivity.
This difference is arbitrary, although I’m told it stems from legal concerns about copyright issues that could easily occur if Hangouts-On-Air were allowed to have broad interop capability.
The fact that the VUC uses a Hangout-On-Air has compelled my search for a reliable, high-quality means of interconnecting the Hangout-On-Air and ZipDX conference bridge. Given my long-standing and vociferous support of HDVoice even the PSTN access provided by a plain vanilla Hangout is troubling. Connecting via a pure IP means, like SIP URI, would allow interconnection with much better audio quality.
The VoIP Users Conference is closing upon 500 weekly sessions, each one more-or-less a conference call. Along the way the manner in which the calls happen has evolved. A bit of background about this will serve to frame why I’ve been seeking a way to interconnect a Google+ Hangout and the ZipDX conference bridge.
When is a webcam not a webcam? When it’s actually a DSLR!
Around here we are strong believers in DSLRs. Our first DSLR was an Olympus E-10, but these days we have a couple of Canon Rebel XSi’s. Released in Q1-2009 these are not the latest and greatest by any stretch, but they’re nice cameras. We also have a small selection of lenses.
As DSLRs have come to shoot video it would make some sense that they could also be used the more sedate role of webcam. Our Rebel XSi’s don’t shoot video, but they do make nice 12 mega-pixel pictures.
It happens that many Canon cameras, including the XSi, have a feature called “Live View” that’s intended to stream the image to the LCD viewfinder or even across a USB connection.
For quite some time I’ve been looking for a way to leverage things like Skype video calling, Google Hangouts or Citrix GotoMeeting with HD Faces. However, I don’t want to use a webcam as the video source. I want to use a real, high-quality video source….preferably an HD-SDI video source.
Clearly I’ve got my own reasons for this sort of requirement. I work with equipment that outputs production grade video. By “production grade” I mean entirely uncompressed video. That’s 270 Mbps for SD and 1.459 Gbps for HD. It’s very clean video.
There are times when I need to be able to stream this kind of video to a remote site. Of course it’s not practical to send the uncompressed stream wholly unaltered. Well, it could be done, but for a hefty price.
Since the far end is typically an ad hoc location what I really need is a way to use an uncompressed HD-SDI source, but deliver a decent quality, sensibly compressed stream to something handy at the far end. It would be most ideal if it didn’t require an installed app to receive the stream. Finally, it should handle firewalls and NAT without flinching.