When can USB 2.0 actually be better than USB 3.0? Video Capture!

This has come up a lot recently and it’s a little counter-intuitive. There are times when an older video capture device, using USB 2.0, is actually better than new new one that leverages faster USB 3.0 or 3.1. The reason is simple, but not obvious.

Just a few years ago, USB-attached video devices had to cope with the constraints of USB 2.0 (480 mbps) so they often incorporated on-board scaling and compression engines. Remember that using uncompressed video USB 2.0 maxes out at 720p30. This is why that was, and remains, the de facto standard for video chat applications.

Their newer kin, with a faster USB 3.0 (5 Gbps) connection to the host, can pass an uncompressed 1080p60 video stream…so they usually don’t have as much on-board processing capability.

Consider as an example the El Gato family of HD60, HD60S and Cam Link USB capture devices. The first two of these devices look very similar, but the differences are substantial and potentially important.

El Gato HD60

We used an HD60 at Cluecon 2017 when we needed a last minute way to ingest an HDMI source into a computer. It worked really well. It has a USB 2 connection to the host. It could deliver YUY2 uncompressed up to 720p30. It could deliver 1080p30 using MJPEG or H264 compression. MJPEG has zero latency, so this is the preferred way to accommodate 1080p over a USB2 link. The UVC 1.1 standard, circa 2005, indicates as much.

While conceptually it was a UVC compliant device, the HD60 has a device-specific installable driver. This driver was installed with the El Gato Game Capture utility, which we used to verify the correct operation of the device.

El Gato HD60S

The newer HD60S looks so very similar. The primary difference being the USB 3 Type-C connection to the host. USB-C ports still being less common, many people would likely use a type-C to type-A cable to connect it to a USB 3.0 port.

The HD60S is capable of 4K60 capture (!) but does not have an onboard compression engine. So the capture or streaming application must cope with uncompressed video. That also means that when connected to an older host via USB 2.0 it’s only capable of 720p30.

If the host computer is resource constrained (no USB 3) the ability to deliver compressed video over the USB link can be a very real benefit. Similarly, an onboard scaler allows a capture dongle to accept 1080p60, while delivering 720p to the client application. There are times when this is also valuable. Typically, when you must use a client application that insists upon a particular video format, but the source delivers something else entirely.

El Gato Cam Link

These various considerations are why El Gato’s USB 3.0 connected Cam Link (reviewed previously) can be so cheap. It does essentially no onboard video processing.

That’s great if it does what you need. I used one at ClueCon 2018 to capture the 1080p60 stream from a BlackMagic ATEM switcher into my vMix host.

My i7-powered Airtop-PC is quite powerful and vMix is massively flexible, so the limitation of the Cam Link were not a factor. However, Cam Link not especially flexible. The older, USB 2.0 connected HD60 is actually more useful.

Update: A couple of people have refuted my claim that there can be an advantage to USB 2 capture devices over USB 3. I accept that the headline is a little click-baity. My intention was to highlight the fact that the new generation of USB 3 capture device did not do something that their older, USB 2 predecessors made commonplace. As a result, if you have an older, slower and/or I/O constrained host you might find that the new and supposedly better capture devices put you at a disadvantage.

Pixel & Pie – WTF Google!

Google Pixel (Very Black)

After carrying Nexus phones for years I bought a Google Pixel in December 2016. That was just after the Pixel 2 was released, so the older Pixel was priced well and still offered great performance.

I was very pleased with the Pixel until quite recently. The OTA update to Android 9 (Pie) in August has been a huge step backward. Since that update the phone’s battery life has been dramatically reduced. Where it once lasted all day with my typical usage, it now lasts only about 7 hours with only light usage. Further, the phone is often noticeably warm to the touch.

Being the inquisitive sort, I’ve done some experiments to try and find out why this is happening. There are no rogue apps running. Or at least the OS reports no app using more that 2-3% of battery power.

I put the phone in Safe Mode for a day so only the factory installed apps would run. Battery life remained abysmal. That suggests that the problem is not caused by an app at all.

I’ve come to believe that I’ve identified the source of the problem. It’s related to the Wi-Fi. If I turn off the Wi-Fi the battery life is closer to what was experiencing running Oreo. Turn it back on and it plummets.

Continue reading “Pixel & Pie – WTF Google!”

How-To: Using an RTSP Stream as a Source for a WebRTC application

This post arises from a question posed by someone via Quora. I’m not all that engaged with that Q&A platform, but this question seemed novel, so I offered an answer. I thought the answer worth sharing in a little more depth, so I offer it here as well.

The question was, “How can I use the RTSP stream from an IP camera as a source for a WebRTC application?”

There are two parts to solving this puzzle; (1) Connect to the RTSP stream and (2) Make it appear like a webcam to the client application.

Obvious Answer: vMix

At the outset, let me say that I would address this using vMix. vMix solves both parts of the puzzle handily. If this is all that you needed to achieve, the $60 Basic HD license would suffice.

Of course, you’d need to learn a little about the application, which is deep. To my mind it’s fun, but some might find it daunting. Further, vMix requires a considerable host platform. You’re not going to run it on trivial hardware.

Let’s just say that we’d like to solve the problem with less spending and requiring less knowledge overhead.

Less Obvious Answer: VLC & NDI Tools

VLC is the ubiquitous, open source media player. Available on all platforms it can play anything I’ve every wanted to open. Beyond files, it can open network streams. I’ve used it to listen to my local PBS radio station. I’ve also used it to watch video streams from our Grandstream surveillance cameras, as shown below.

VLS viewing RTSP stream

NDI stands for Network Device Interface. It’s a network protocol, developed by Newtek of TriCaster and Video Toaster fame, that allows low-latency, lightly compressed video to be passed over a gigabit Ethernet network. NDI is impressive, but I won’t wax poetic about that here.

Continue reading “How-To: Using an RTSP Stream as a Source for a WebRTC application”

A Novel Widget: fit-statUSB from Compulab

Here’s a cute new widget from Compulab, makers of my beloved Airtop-PC. A first glance, fit-statUSB looks like a very small USB memory key, but it’s actually a programmable color status LED.

Costing just $12 this wee LED looks like a serial port to the host computer. You can send simple commands to the com port to set its color, brightness, make it sequence, etc.

fit-statUSB

It’s easy to think of many possible use-cases. I can imagine a rack of gear where a servers process status is indicated by a front mounted fit-statUSB. When a critical process goes down the LED indicates this immediately, without requiring a sophisticated management or monitoring system. Just a few scripts.

Might be fun to play with one (some?) of these one day soon.

Asterisk on Raspberry Pi now has FXO, FXS and GSM Interfaces

The combination of Asterisk and Raspberry Pi harkens back to a time when I was seeking to run Asterisk on an small, embedded platform. I was a little ahead of the curve, seeking this before Digium released AsteriskNOW. I tried Michael Iedema’s Askozia PBX and settled upon Astlinux on a Soekris Net4801, which I used for a couple of years.

Of course, all this was before the now ubiquitous Raspberry Pi was released. It makes sense that someone would try that low-cost SBC as a host for Asterisk. However, there hasn’t been much hardware support for that effort until recently.

oak2_1

Today I read that SwitchPi is now offering modular and multi-port FXO/FXS interfaces, as well as a GSM interface.

  • OAK8X base module (4 onboard Asterisk FXO channels) $130
  • OAK8X base module with 8 channels (8 Asterisk channels, 4 FXO plus 4FXS) $180
  • OAK8X base module with 8 channels (8 Asterisk channels, 8 FXO) $180
  • PiGSM single channel GSM interface $99
  • PiTDM base module $89
  • PiTDM 2 channel FXO module $20
  • PiTDM 1 channel FXS module $10

This is exactly the sort of hardware I tinkered with when I was using Asterisk. I used a TDP400P card with FXS and FXO interfaces. I also used a SIP-to-GSM gateway, documenting the project in the early days of this site.

SwitchPi seems have started in January 2018. It’s good to see hardware support for running Asterisk on Raspberry Pi evolving and affordable.

Warning! Avoid Everquote.com

We’d all like a deal, right? Most especially a better deal on something that you have to buy anyway, like car insurance. So it was that a couple of weeks ago I succumb to an online ad for EverQuote, a company that purports itself as disrupting the insurance business. I regret the decision to try the service. It was a moment of weakness that haunts me still.

We’ve been with the same company for auto insurance for a long time. They are not the company that has our household insurance. I had thought that it would be worth the time, on a Saturday morning, to see if this disruptive young startup could provide me with a couple of quotes. My hope was that, with just a few minutes at the keyboard (actually my phone in this case) I’d have some insight as to whether we were paying too much.

It didn’t work out that way.

Continue reading “Warning! Avoid Everquote.com”