[NUUG video] [Savonet-users] Creating a web based TV station using liquidsoap and SOAP (Was: Bug#574628: liquidsoap: Drop video when processing Ogg Theora file)

[David Baelde]

Hi,

It's nice to start talking concretely about that interesting project!
As you're pointing out, the first question is to see whether
liquidsoap is the right tool, and I'll try to address this first. Then
I'll deal with how to schedule files, which is in fact unrelated to
video.

On Mon, Apr 12, 2010 at 3:40 PM, Petter Reinholdtsen <pere at hungry.com> wrote:
> Also, I am curious if it is possible to generate the program info
> screen shown between events using liquidsoap.  Can liquidsoap generate
> video from an image directly?  A video with animations (like a clock
> or some scrolling text) would be nice to have on the info screen. :)

Yes, this would be possible. In fact, I don't think there's any better
tool than liquidsoap for that sort of thing. With other solutions,
you'd have to prepare the info screen video using external tools
before inserting it. Liquidsoap can compose it on the fly using a
fixed image, text insertions, and even animated logos. It can also
perform nice transitions from the info screen to the programmed
videos, and the other way around.

But everything has a price...

>> The main limitation is efficiency. Many operators haven't been
>> optimized yet, so we don't know exactly what's possible. But I
>> wouldn't expect to decode and encode in real time larger than around
>> 500x500, and even that will require a good CPU.
>
> Would recoding be needed if the resolution do not change?  I hope not,
> to avoid costly operations.  The Ogg Theora files are pregenerated,
> and I hope we can get away with only coding the video once. :)

In order to allow such rich treatments, liquidsoap internally only
deals with raw streams. As a result, it must always decode and
re-encode everything. If you can't live with that, then liquidsoap
isn't for you, at least for now (I have been pressed several times to
support encoded streams, but I never found a convincing pratical
solution).

> The resolution and bandwith usage is not as expected (see
> <URL: http://bugs.debian.org/577076 >), but I expect that this is
> solvable by tweaking some configuration options if the defaults do not
> become more sensible. :)

The resolution and framerate settings that you've seen
(frame.video.width/height/rate) are global parameters determining
liquidsoap's internal (raw) video streaming format. They cannot be
realistically guessed from the input: the input might be a remote
stream, or an heterogeneous list of files -- worse, in some cases the
input's format has to be guessed from the global one, e.g. when
synthesizing video (silence, noise, fixed color) from nothing.

> Now the problem is to see how liquidsoap can use the information
> available via the SOAP api to schedule programs at the correct time
> instead of using a sequencial playlist.  I have not had time to look
> into how that can be implemented in liquidsoap yet, but am curious how
> we can make sure the SOAP api is only called once per day instead of
> very time a program is about to start.  Calling the SOAP api and
> parsing the XML files it points to is too expencive to do all the
> time.

There are a couple solutions to explore. One possibility is to process
your XML files once to feed a database than is then queried by
liquidsoap using a lighter perl script. This is essentially the same
as I proposed before, it's just harder to implement but might be more
efficient. A very different solution would be to create AT jobs from
the XML config that feed a liquidsoap queue (at 12:00, push that video
to that queue, at 12:30 push this other video, etc). It avoids active
polling from liquidsoap. The core of your liquidsoap script would then
be a fallback([request.queue(id="queue"),info_screen]).

This part might be more or less difficult depending on your precise
needs and the guarantees on that XML file: is it possible that one
files hasn't ended when another starts? what do you want to do in that
case?

HTH
-- 
David