Re: any optimizations possible in OGG or vorbis to reduce time?

Sumit Chatterjee <[email protected]>
Newsgroups gmane.comp.multimedia.ogg.vorbis.devel
Message-ID <[email protected]>
Hi Gregory,
    Very informative explanation. According to your figures, my processor
stands nowhere close :(
     I have 2Ghz core2, but the time to encode 600-700ms data takes around
100ms and mostly more.
     Ofcourse the compilation has been improved to time based optimization.
i.e. O2

    Anyother updates that might help?

Thanks
Sumit


2009/9/4 Gregory Maxwell <[email protected]>

> On Thu, Sep 3, 2009 at 2:44 PM, Sumit Chatterjee<[email protected]>
> wrote:
> > I dont understand exactly the terms that you have asked. Basically if I
> have
> > a continuous stream to be sent out - a computational delay of 50-100ms is
> > still manageable.
> >
> > Regarding my platform:
> >    - its on Windows and my encode is running under realtime priority.
> >    - my audio capture is every 500ms.
> >    - And my OGG container is reduced to 2KB. So a min of 6KB data is
> flushed
> > out after every ~600ms from the encoder
> >
> > I basically want to reduce the encoding time to generate a packet of 6KB
> > from 200-300 ms to <100ms always, so that I can support least setup
> latency
> > in my radio application.
>
> Algorithmic delay is the amount of intrinsic delay in the algorithm
> which comes from things like the blocksize and the data look-ahead.
> It can't be fixed by applying a faster processor, it can sometimes be
> reduced with a carefully written software but some amount of
> irreducible delay will exist in the format.
>
> Computational complexity is just the delay that comes from the
> computer executing your instructions. A faster processor or more
> efficient software addresses this.
>
> The vorbis format is not particularly designed for low algorithmic
> delay, nor is the reference encoder designed to minimize delay to the
> minimum possible in the format but it sounds like you expecting to use
> large blocks of audio and can tolerate the fairly high algorithmic
> delay of the normal vorbis modes, so your problem is complexity.
>
> I should have been more specific:  What processor is in use?   Is your
> problem a problem with the average encoder execution time or the worst
> case encoder execution time?   On average my 1.6ghz core2 laptop
> encodes at >17.5x realtime, or 500ms of audio encoded in ~29ms.  But
> this is the average, I expect the worse case is much worse.
>
> If you're seeing average performance worse than this on comparable
> hardware perhaps there is an issue with how you are calling libvorbis
> or with how it was compiled.
>

_______________________________________________
Vorbis-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/vorbis-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.