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 <[email protected]> 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
