I have been into live video streaming on the web long before YouTube Live opened this feature for the wide audience. By simply working directly with my own video players and media streaming servers.
In present day, my specialisation encompasses live streaming to Facebook Live and YouTube Live, involving the use of API of these two large platforms, de facto world standards of the modern video content delivery.
While watching admirably at the success of these giants, I cannot understand why do there still so many technical issues exist, when one attempts to stream their event via one of these social networks.
You could use any of the ways, either an API method for professionals and television channels, or a simple and sought-to-be convenient way – a graphical user interface, or directly your web-browser.
Let us take a closer look at the streaming at YouTube via a GUI-control:
The streaming normally starts at your channel’s Creator’s studio, where you can create a new video event and grab a broadcast key to perform your worldwide show.
YouTube Live will suggest that you switch to a new interface, which is already for a long time in beta.
This is something you do not want to do under any circumstances. Once in it, you are going to be completely lost, and the functionality to broadcast via an encoder (like Open Broadcaster) will be unavailable there.
That said, every time you select the encoder way, the system will kick you back to the old interface.
Broadcasting with a built-in or a USB webcam has been made easier, but YouTube is a professional platform, where users prefer to have a choice to deliver a high-quality content via external encoders.
Let us imagine we wish to use an external encoder, the most ancient and reliable way to provide a stream to YouTube. Having gone through the event creation and configuration, especially on serious YouTube Live channels, you expect to see a preview of your stream.
Well, no. You have a preview player, which does not work, until you transition your stream into the preview (test) mode. Quite a design flaw of a UI, where something, that is already displayed and seemingly available, is not working.
Okay, but this has been so since years, let us call it a tradition.
My next click goes to a button “Stream preview” and the system informs, that it prepares a preview stream for me. The button changes its text to “Stream live” now, but wait. We are on the preview page in the respective mode, but a preview player still throws an error, the identical one to that before switching to this specially-designed mode.
I must admit, for all these years since the start of YouTube Live platform, I have got so much used to the situation, that I have forgotten that YouTube can have a stream preview mode, despite it is documented everywhere and even present like a fake feature of the interface.
Why such a flaw of otherwise popular platform – I do not know. A few years ago there appeared a new option, called “Camera” (though I’d rather prefer them to fix the old method). This one works the way I use the other one – no preview, immediately whatever you stream to YouTube is pushed to live. I have no idea, why YouTube has such a bad relationship with preview streams.
If you are as advanced with YouTube as I am, you might suppose that using an API will help you out, but no luck. Would it be so, I wouldn’t have written this article.
In terms of the preview, you will not be able to fetch the preview player via an API as well, so until you start a live broadcast, there is no way for you to reliably know if your stream is fine. Just hope for good.
Other than that, the API works reliably and allows to effectively omit the YouTube interface in most cases.
Facebook Live is much younger, than YouTube’s. However, it is already widespread.
A normal user of a modern social video broadcasting platform is used to create a video broadcast, go in there, copy a streaming key, paste it to their video encoder and enjoy.
What if you are tired to reconfigure the encoder every time, because you broadcast a little bit more often? There is a solution – it is called a persistent streaming key. Once selected, the key is immutable per Facebook page or per user account, and one can set it in their video encoder for a lifetime.
At least this scenario is realistic for YouTube.
For Facebook, this feature, despite being present for already almost a year, does not work properly. The persistent key often de-selects itself even when you edit a video, change a description, or just so.
If you create multiple streams with the pre-assigned persistent key, this will drive Facebook crazy, and it will not know where to broadcast to. Despite it is just as easy as broadcasting to the player, that comes first according to the planned event’s time. With due diligence it is possible to always check if the key was not gone yet and re-tick it back, but having about three live events per day renders this method useless due to mentioned self-determination bugs.
In my situation, I use variable streaming keys by automating their feeding via an API, because setting a persistent key over an API is… impossible. Right, a functionality, meant for professional
broadcasters, is completely flawed and useless.
Other limitations of the API are – you cannot edit the description or title of the video, just a visit to Facebook UI can get it done for you. You are unable to upload a slate (preview image of your video) over an API – again a visit to FB is a must.
At least where API takes over – is creating “invisible” videos, that become published automatically with the first bits of an incoming stream. This magic can’t be achieved over the interface.
Normally, you do not expect these things from such over-financed and glorified companies.
For my needs I have created a lot of workarounds, that allow to automate the broadcasting as much as possible anyway, even where it seems to be not designed for the job.
I really wonder how large studios overcome these challenges and why it cannot be solved by the big players for years.