On November 21 I was pleased to participate in a meetup entitled Real-Time Streaming Data. The organizer of this meetup assembles a wide variety of presenters and topics under the umbrella topic of “Large-Scale Production Engineering.” Chris (the organizer) does a remarkable job of keeping a pipeline of interesting talks coming. I’m particularly interested in the January talk humorously entitled “Whatever happened to IPV6?”
Audio/Video broadcasting on the internet is widely supported by a number of “free” apps. These apps shield the end-user from the ultimate cost of audio/video processing and transport. But in some sense, they are not actually free. Most of these apps ask you to trade personal information of value for the right to use the service. Types of valuable information include your identity, perhaps your friends’ identity, and most often they require your “attention” … in the form of advertising. These items of “value” can be converted into real money, and the real money keeps the free service going, and the
virtuous cycle continues.
Broadcasting can require transcoding for each receiver
Broadcasting has many uses. Some are commercial, but there are other types of one-to-many communications that are possible. Exemplars for this type of service are the broadcast of a piano recital to members of the family, or the broadcast of an unusual impromptu street performer to a few friends.
This article examines the costs of broadcasting and asks if lowering the costs can result in a new service model: one that is lean, anonymous and speedy.
I’ve recently become interested-in and fascincated-with the idea of “microbroadcasting.” In the radio world, the term microbroadcast referred to a small radio station, often a pirate radio station. These stations broadcast infrequently, and often you needed to discover its frequency and program schedule through a means other than the radio station.
On the internet, anyone can be a broadcaster using only a smartphone with an app, or a webcam and some software. There are plenty of “broadcast-it-yourself” applications. So what is it that makes one a microbroadcaster and not a broadcaster?
A microbroadcast in the internet world is a potentially short-lived broadcast. It may not gain much traction and it may have little permanance. A microbroadcast is quickly started up, runs for a little while and then dissappears. It is ephemeral.
For the audience, a microbroadcast should require little effort to tune-in to. Ideally you should not need to install special software. As a listener, you should be able to preview the program quickly, determine if you want to continue listening, and move off quickly if you don’t. You should not have to register with the broadcaster to preview the broadcast. It should be freely available, but perhaps not listed: just like a pirate radio station.
A microbroadcast is different from a phone call or a video call: it is a one-to-many transmission. It is different from a conference call, and it is not a hangout: since these require registration. A microbroadcast need not be planned in advance and the audience is not necessarily “logged in” to an app.
It should be possible to start an impromptu microbroadcast because something interesting is happening around you. And you should be able to share your microbroadcast as easily as sharing a link – just the way you might share a link to a relevant article that was just posted. In the case of a microbroadcast, the link should be a live broadcast program.
It has been a few years since there has been a new project embedding the Python interpreter into Verilog. There is a new one on the block, called “Cocotb” built with a definite focus on writing testbenches and running regressions. It is written in a modern dialect of Python and hosted on Git. It is well-documented. I’m impressed with what I’ve seen.
This article gives a little bit of a history of Python and Verilog and describes how Cocotb fits in.
A Brief History
ScriptEDA (2001) [http://embedded.eecs.berkeley.edu/Alumni/pinhong/scriptEDA/,
http://www.scribd.com/doc/3492141/scriptEDA-pinhong] was primarily an example of using SWIG to link a Python interpreter into a Verilog simulator using PLI/VPI. ScriptEDA handled TCK, Perl and Python in roughly the same way.