Видео, текст и слайды моей презентации на Liquidshop 6
---
Video, text and slides of my showcase at Liquidshop 6

—————————————————————————————————————

Hello everyone!
My name is Seva Mikulski. I'm an improvising one-man band live looper and streamer. For the fifth year now, I 've been broadcasting my original content around the clock, using Liquidsoap as a tool for non-stop streaming.And today I will share with you how my project works in the hope that this experience will inspire someone to come up with new ideas.

Let me start with a little background and introductory context.On my regular streams, I jam with a looper: I play musical improvisations, sequentially recording parts layer by layer in real time.In other words, I create a song on the fly, stacking musical elements on top of each other like bricks, resulting in a rich musical collage. This technique is commonly known as live looping. 

The resulting performance is subsequently divided into logical components, and unnecessary elements, such as any hiccups that occurred during the jam, are removed.The content is then reassembled into a more compact and easier-to-perceive format.

Now this is more decent for viewing and listening. It's not a polished studio release of course, but it's like a demo track that can be showcased publicly.

This is a highlight from the stream, in the language of Twitch streaming.

For editing, I use the Reaper digital audio workstation, as it supports sufficient functionality for working with video files.

Since it has a tempo-based interface, it becomes very convenient to measure, cut, and paste fragments of the desired durations, as my jams are synchronized by bpm.

At first, I posted these videos on YouTube, but when I accumulated several hours worth of videos, I had the idea of creating a streaming radio station where these tracks would be played around the clock.

This idea went through several iterations before being implemented in Liquidsoap, which turned out to be the perfect solution. EvergreenDeer told me about Liquidsoap and helped me get started. We met on Twitch, and he also has a radio stream on YouTube called DeerRadio.
Having no experience in programming, the first attempts to create a stream failed miserably.

The entry threshold for a noob turned out to be very difficult.

However, thanks to perseverance, patience and guides from the excellent "The Liquidsoap book", as you can see, everything worked out and now I'm here speaking to you :D

And Liquidsoap became my motivation to start studying and doing coding.

The project consists of three main parts:

Liquidsoap, which is responsible for content rotation.

Nginx RTMP module that acts as a restream server to cover a large number of video streaming sites.

NodeJS, which is a set of auxiliary scripts for automation, parsing, triggering and so on.

My Liquidsoap script is very simple and for the most part uses the most basic mechanics, much of which is described in The Liquidsoap book.

The stream consists of only three scenes.

The main one is a playlist of mp4 files, which includes a request system with reading the path from the file, as the simplest and most effective method.

Graphic elements are overlaid on top of the playlist source:

playback queue, covers, countdown to live broadcast, playback progress, goal widgets, etc.

In other words, rectangles, texts, images.

To save resources, all overlays that are not tied to time like the playback queue are combined into separate groups of elements, to which an additional buffer is applied.

This helps to avoid problems with catch up situations in some cases.

For example, when switching from a scene where there are no superimposed graphic elements to a scene where there are many of them.

Every 20 tracks, the main scene switches to an mp4 Playlist with short jingles, which acts as an intermediate screen with a list of recent events.

All the same overlays are displayed here, but additionally there is a list of events that are collected via the API from the streaming platforms.

Follows, subscriptions, raids, tips.

Icons of streaming platforms and social networks are embedded in fonts.

They were converted to vector-svg format, and then added through the open-source fontforge program as a specific character.

I do not know how to do this more correctly, so I use workaround, where a certain symbol has its own icon.

This is not very convenient, but with a small number of fonts and platforms used, it is not very troublesome.

And the last scene is the input.rtmp source, which I direct the stream from OBS to when I go live.

No additional overlays made in Liquidsoap are applied to it anymore.

The playlist switches to input.rtmp via the fallback operator and back when I finish the live session.

This combined set of scenes is sent via the output.url to the Nginx RTMP Module, from where it is already being relayed to more than 20 sites.

Despite the fact that the rtmp module has not been maintained or updated for many years, it is still an usable tool.

This is largely because ffmpeg(«эф-эф-эм-пэг») instances with a copy of the stream can be launched from there via the exec_push directive.

This solves the problems with connecting to some sites when it is not possible to connect using the native method.

Additionally, without Nginx involvement, an  audio output is sent as a separate thread from Liquidsoap to the icecast server and from there via relay to shoutcast. 

Just To make it happen, as they say.

And the last element of the entire system is NodeJS.

With the help of the PM2-process manager utility, the auxiliary scripts run smoothly 24/7 along with the stream.

It Interacts with the APIs of streaming platforms and social media for handling requests from chats, cross-postings, collecting events, and solving code issues that I could not resolve in Liquidsoap due to a lack of skills and experience.

An illustrative example is changing the stream title and category (where required) on platforms when the playlist switches to input.rtmp and back.

JavaScript just happened to be the first language I came across when I was looking for examples of chatbots, so it just stuck around.

I decided to use HD quality as a logical compromise.

First of all, the main priority - it's the best possible broadcastability.

In many locations, the internet is still slow and Very few platforms provide additional encoding for choosing a resolution.

Many people watch content on their phones.

This resolution is still supported by all platforms.

In addition, it saves a significant amount of disk space and CPU resources.