Hi! 2011/5/12 Martin Konečný <[email protected]>: > Hey! > This is great I cant wait to get this working :). So far I've checked out > the "seek" branch but I'm having trouble getting this to work. I have the > following simple script: > > set("server.telnet", true) > set("server.telnet.port", 1234) > set("log.file.path", "/home/martin/liquidsoap/ls.log") > set("log.stdout", true) > %include "library/pervasives.liq" > > s = mksafe(request.queue(id="queue", conservative=true)) > add_skip_command(s) > out(s) > > and i'm using >> >> queue.push annotate:liq_cue_in="10":/home/martin/ACDC.ogg > > via telnet. > Is there some function I need to put the source through? I ask this because > for liq_fade_in to work I know > I have to pass it through fade.in(). I looked through the docs but didnt > find anything so far.
Yes, you need to use the cue_cut operator just after the request source declaration: s = cue_cut(s) s = mksafe(s) A proper documentation will be written when time allows it :) Romain > Martin > > 2011/5/11 Romain Beauxis <[email protected]> >> >> Hey! >> >> 2011/5/2 Romain Beauxis <[email protected]>: >> > 2011/5/2 Martin Konečný <[email protected]>: >> >> Hey Romain, Thanks for clarifying that up, so maybe we will have the >> >> ability >> >> to jump to different positions in tracks for Liquidsoap 2.0 :). >> >> I'm going to do some tests this week to see which is faster: Cutting >> >> off the >> >> first 50 minutes of an mp3/ogg file, or having liquidsoap "process" all >> >> data >> >> up to the 50 minute mark. I'll post my results here. >> > >> > Well, don't spend too much time on that, I might have something to >> > announce pretty soon concerning this issue :-) >> >> Ok, so while waiting for a proper announce, I'll send a follow up >> concerning this issue: we have started a seek branch with a proper >> support for seeking in streams! >> >> The cue_cut operator has been merged there and is now using the new >> mechanism. >> You may want to test it from this branch, which should be merged into >> the main code soon :) >> >> > Romain >> >> >> Thanks! >> >> Martin >> >> 2011/4/29 Romain Beauxis <[email protected]> >> >>> >> >>> Hi! >> >>> >> >>> 2011/4/29 Martin Konečný <[email protected]>: >> >>> > Hi Samuel, >> >>> > Regarding Ticket # LS-469: http://dev.sourcefabric.org/browse/LS-469 >> >>> > Could you detail why Liquidsoap would have a very high CPU usage if >> >>> > I >> >>> > were >> >>> > to set a cue point more than a few seconds from the beginning of a >> >>> > track? >> >>> > One use-case we were hoping to address with this feature was >> >>> > restarting >> >>> > playback from a specific point in a track after a power failure. One >> >>> > of >> >>> > our >> >>> > users has a radio station in an area where the power goes out a few >> >>> > times a >> >>> > day, and some of their tracks are pre-recorded shows up to an hour >> >>> > long. >> >>> > We wanted to make it so that if the power goes out with 10 min left >> >>> > of a >> >>> > one >> >>> > hour show, they simply need to restart their system and we use >> >>> > liquidsoap to >> >>> > jump to the 50 min mark. >> >>> >> >>> That's a very interesting case! >> >>> >> >>> > I am curious why I can jump to any point in a track with media >> >>> > players >> >>> > such >> >>> > as Banshee and Rhythmbox instantaneously, but Liquidsoap cannot. >> >>> >> >>> The problem is that Liquidsoap has always been designed as a _stream_ >> >>> processing "engine". It works chunk by chunk to generate a stream. >> >>> This internal specification is very appropriate for many reasons but >> >>> also entails some limitations (one of which being the skip vs. >> >>> crossfade problem you mentioned and on which I still have to reply..) >> >>> >> >>> When decoding a file, liquidsoap processes data frame by frame until >> >>> it ends. It has some limited view concerning the future, namely an >> >>> estimation of the remaining time for files and, in the case of >> >>> crossfade in conservative mode, a small buffer of data (which should >> >>> be the solution for your skip and cross issue: pass conservative=true >> >>> to the crossfade operator). >> >>> >> >>> So, for now, we do not have any notion of skiping data in file >> >>> decoders. The cue point operator is implemented for now by decoding >> >>> all the data to skip at once at the beginning of the track and that is >> >>> what may cause high CPU usage. (the problem does not occur at the end >> >>> of the track). >> >>> >> >>> Ideally, we should have a notion of skipping for file decoders. >> >>> However, I am not so sure about how this could be implemented. I >> >>> believe that it could be a source's property, that is only available >> >>> when possible (i.e. the source is a playlist, single but not >> >>> input.http etc..) >> >>> However, this probably requires a fairly large amount of work and >> >>> would also require the implementation of a skipping method for each >> >>> format (and don't get me started on the mess concerning mp3 data..) >> >>> (or the ogg muxing format also..) :-) >> >>> >> >>> All in all, I would say the following: >> >>> * For now Sam's operator is nice for cue points that are close to the >> >>> beginning of the file, which is usually the case for instance with >> >>> crossfading. >> >>> * For you specific case, a cut_file protocol would probably be enough >> >>> (files are mp3 or ogg/vorbis?). >> >>> >> >>> In the long term, I would like to have a skiping data support in >> >>> liquidsoap. However, I believe that is too much of a core change for >> >>> now, because we are still working on the 1.0 stable release... >> >>> >> >>> >> >>> Romain >> >>> >> >>> > Regards, >> >>> > Martin >> >>> > P.S. Thanks for the quick implementation of this feature. Even in >> >>> > its >> >>> > current state we will have uses for it :) >> >>> > >> >>> > -- >> >>> > Martin Konecny >> >>> > Software Developer, Sourcefabric >> >>> > [email protected] >> >>> > >> >>> > >> >>> > >> >>> > ------------------------------------------------------------------------------ >> >>> > WhatsUp Gold - Download Free Network Management Software >> >>> > The most intuitive, comprehensive, and cost-effective network >> >>> > management toolset available today. Delivers lowest initial >> >>> > acquisition cost and overall TCO of any competing solution. >> >>> > http://p.sf.net/sfu/whatsupgold-sd >> >>> > _______________________________________________ >> >>> > Savonet-users mailing list >> >>> > [email protected] >> >>> > https://lists.sourceforge.net/lists/listinfo/savonet-users >> >>> > >> >>> > >> >> >> >> >> >> >> >> -- >> >> Martin Konecny >> >> Software Developer, Sourcefabric >> >> [email protected] >> >> >> >> 720 Bathurst St. Suite 203 >> >> M5S 2R4, Toronto, ON, Canada >> >> +1 (416) 892-8420 (Cell) >> >> Skype: martin.konecny15 >> >> >> >> http://www.sourcefabric.org >> >> http://www.twitter.com/Sourcefabric >> >> >> > > > > > -- > Martin Konecny > Software Developer, Sourcefabric > [email protected] > > 720 Bathurst St. Suite 203 > M5S 2R4, Toronto, ON, Canada > +1 (416) 892-8420 (Cell) > Skype: martin.konecny15 > > http://www.sourcefabric.org > http://www.twitter.com/Sourcefabric > ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
