Ok, I managed to get the operator need through the commit history (and now I
realize I should have read your email more carefully :D )
It works! Well I had to remove the mksafe operator first because I was
getting
2011/05/12 19:31:13 [mksafe:3] Seek not implemented!
Startup time is instantaneous right now, can't wait until it gets merged
into the main branch :)
Martin
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.
>
> 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
>
>
--
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
