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 >> > ------------------------------------------------------------------------------ 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
