Playing well with others
We are back from vacations, and reviewing plans for the next few months. Up to this point we've been working on our core technology, and that is coming along pretty well. So for the next few months we will be focusing more on how we integrate with other systems. We'll sprinkle some comments about that throughout this post as we update you on some recent travel and other activities.
We just returned from New York, where we attended some events we'll describe below. On our last day we decided to become tourists: It was a beautiful day so we took the NYC ferry to Brooklyn, walked around DUMBO, had coal-oven pizza and egg cream for lunch, and then walked back across the Brooklyn Bridge. Feeling like that area would be great for Port 9's East Coast office someday.
But we're getting ahead of ourselves. Let's start with something Mike attended during his vacation.
Norsk at the PDX Video Tech Meetup
Mike attended the PDX Video Tech Meetup on October 5th. Where "I" is used here it means Mike, because Jialu was still on vacation.
Portland is very lucky to have a really great video tech community Meetup hosted by AWS Elemental. The speakers were Dr Adrian Roe and Steve Strong from id3as who talked about their Norsk project. Norsk is an SDK for building video applications in a "low code" manner. You write programs that communicate with their runtime in a container, and the runtime handles all the video processing.
I had a great conversation with Adrian before he spoke. I had earlier noticed that they used the Erlang runtime, and thought that was extremely cool because it is really easy to run very reliable, self-healing systems on the Erlang machine. But most people don't like to program in Erlang. Adrian said they code in PureScript which is a Haskell-inspired functional language that typically compiles to JavaScript, but it can also target the Erlang machine. So they get the reliability of Erlang with the ease of programming in PureScript. Very cool. SDK customers will typically use JavaScript or TypeScript to write their Norsk applications.
Norsk is composed of several building blocks that perform media processing in a graph -- sort-of like gstreamer, except they are using their own code rather than open source. You can make a fairly complex workflow easily in a few lines of code.
These guys check off all the nerd boxes and it was fun watching their demo (given from a nix shell running on a laptop).
I also spoke to Syd Lovely, who I worked with at Omneon a long time ago. He is now at AWS Elemental and running the MediaConnect and CDI projects. MediaConnect began its life on my laptop. Jialu and I were on the MediaConnect team for its launch. It was great to catch up with progress of MediaConnect after I left AWS. I hope I convinced Syd to add a bars and tone generator to MediaConnect -- something I was not allowed to do while I was there 
.
SVG TranSPORT
Mike and a very jetlagged Jialu attended this year's SVG TranSPORT show at the Cutting Room in NYC. We think our service will find a lot of usage among sports broadcasters, so we are trying to learn more about their workflows and how we can fit in. And it is clear that when video leaves a stadium, it is often traveling over a link that was probably leased from a company such as Lumen, the switch or BitFire. Connectivity from those systems to our cloud service seems like a natural fit.
At TranSPORT there is much talk about remote production in sports broadcasting, often controlling trucks at the stadium from a central studio (usually called REMI). There is a lot of use of fiber and satellite for distribution and backhaul. Cloud production is still rare, and will probably be staged - with tier 3 sports testing the waters.
But this lower tier usage coming first brings up another point: Mike considers himself to be a "dinosaur" in the video industry. He has been working in video for over 40 years. So of course our switcher app has a traditional program / preview arrangement. But we are seeing that some of the lower tier sports are being controlled by a single operator using a specialized control application that is easier for them to use, even if it is less functional. So we will probably be adding an additional GUI that can be customized for this type of application.1
AWS Media Day
On Wednesday we attended the AWS Media Day which was held at at the AWS JFK 24 office near the convention center, conveniently located for attendees of the NAB and AES shows just a few blocks away.
Presentations
There were two main tracks. We attended the one on live cloud production. The invite said "Workshops are technically focused requiring hands on keyboard. Please bring a laptop and power adapter to participate fully." So we did, but it ended up being just several sales talks.2
Mike, as a former principal engineer at AWS, continues to be surprised at how AWS is embracing the NDI ecosystem, which mostly consists of lift-and-shift Windows applications running on cloud instances being controlled and viewed over remote display technology. Most of the live production talks were about various parts of the NDI workflow. The AWS application architects who presented sounded just like they were selling Vizrt stuff. There was not much discussion of other cloud solutions such as Grass Valley AMPP and nothing about SaaS offerings like Grabyo.
The material was mostly just an elaboration on what AWS has been showing at IBC and NAB recently showing multi-vendor interop using NDI applications running on cloud instances.
For the same production as was demonstrated here our system will require about 2 Mbits of bandwidth from the cloud (for our proxy transport) and will have no button latency at all.
The photo above was from a Vizrt Vectar cloud demo. They are demonstrating the latency and bitrate of their cloud to ground link using AWS NICE DCV, which was traveling from the cloud over the AWS backbone to the Wi-Fi in the AWS office (basically never using the public internet -- your results may vary). Their control surface was in the room and they connected through an Intel NUC which was also receiving the GUI video from the cloud. It was very interesting to see that the TD (technical director) who gave the demo was very satisfied with the latency and video quality. He is a great believer in using "button latency" as a quality measure, and figured that they were getting around 50 milliseconds of button latency here. He said that was good enough for him.
The session on replay was made interesting by including an employee from Riedel who demonstrated their SimplyLive cloud replay product. We didn't catch his name, but his demo was probably the most technical one of the day, therefore most interesting to us. He also was the only one who talked about the possibility that a cloud instance may fail, and how to work around that.
The "hallway track"
We did have great conversations with some of the other attendees in the hallway and at lunch. This made the day worthwhile for us.
- Our current audio interchange is using AES 67, which is only a data plane specification. Unlike the video people who jointly developed NMOS for this, there is no standard control plane for digital audio. Instead the audio industry uses several proprietary protocols. So we basically have the data path but need to talk to these companies to get SDKs or specifications for their control plane protocols so we can connect with users. One of these protocols is Dante, from Audinate. We were fortunate to meet some of their people at the event and they were very helpful. Note that Dante / AES 67 is also used for intercom systems, which we also needed to start looking at.
- We got a good lead from M2A about a standards conversion library from InSync Technology which we may want to evaluate for our video gateways.
- We had many other conversations with broadcasters, systems integrators, and other vendors. We are starting to get a good idea of how we can fit in to the cloud production ecosystem.
Summary
We are now back in Portland and ready to get back to work. Some of our action items are:
- We need to get our audio working with Dante and other protocols. Not just for audio interconnect, but also for intercom systems.
- We need to find a vendor for standards conversion. We code most of our technology ourselves, but would be very pleased to leave this bit to someone else.
- We will begin to design an alternate switcher GUI for single operator control.
- We have a basic tally system working, but need to add support for protocols in use by our customers.
If you want to talk to us about any of these things, or anything else, please get in touch.