Vorbis dev - Sep 2009 - any optimizations possible in OGG or vorbis to reduce time?

Respected all,
    I have been able to make my whole setup ready with OGG VORBIS encoder
and decoder as provided by the open source libraries. I am very happy with
the result. I have one concern in the same. : Can the performance of the
encoder be enhanced? Currently for 44KHz stream it is taking upto 300ms to
encode 500-600ms of data. I wanted a figure well within 500 ms.
    Can I get a starting point that I can attack either in OGG library or in
VORBIS encoder library...??

Thanks
Sumit
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090903/f1a4f44d/attachment.htm

On Thu, Sep 3, 2009 at 2:26 PM, Sumit Chatterjee<getsumit at gmail.com>
wrote:
> Respected all,
> ??? I have been able to make my whole setup ready with OGG VORBIS encoder
> and decoder as provided by the open source libraries. I am very happy with
> the result. I have one concern in the same. : Can the performance of the
> encoder be enhanced? Currently for 44KHz stream it is taking upto 300ms to
> encode 500-600ms of data. I wanted a figure well within 500 ms.
> ??? Can I get a starting point that I can attack either in OGG library or
in
> VORBIS encoder library...??

Greetings. Is your concern algorithmic delay or computational
complexity?  If the latter? what platform are you testing on?  The
encoder is a decent multiple of realtime on typical desktop processors
today.

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.

Thanks
Sumit


2009/9/3 Gregory Maxwell <gmaxwell at gmail.com>
> On Thu, Sep 3, 2009 at 2:26 PM, Sumit Chatterjee<getsumit at
gmail.com>
> wrote:
> > Respected all,
> >     I have been able to make my whole setup ready with OGG VORBIS
encoder
> > and decoder as provided by the open source libraries. I am very happy
> with
> > the result. I have one concern in the same. : Can the performance of
the
> > encoder be enhanced? Currently for 44KHz stream it is taking upto
300ms
> to
> > encode 500-600ms of data. I wanted a figure well within 500 ms.
> >     Can I get a starting point that I can attack either in OGG library
or
> in
> > VORBIS encoder library...??
>
>
> Greetings. Is your concern algorithmic delay or computational
> complexity?  If the latter? what platform are you testing on?  The
> encoder is a decent multiple of realtime on typical desktop processors
> today.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090904/f17e0304/attachment.htm

On Fri, Sep 04, 2009 at 12:14:32AM +0530, Sumit Chatterjee
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.
> 
> Thanks
> Sumit
So You are talking about latency, right?

What about CELT instead of Vorbis? (http://www.celt-codec.org/)

P.T.

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>
Jabber: butrus at jabbim.cz
SIP: butrus at ekiga.net

Hi Petr,
    You are right. CELT looks like a good option, but I already am using lot
of components, each of them uses OGG/VORBIS encoder and decoder. It includes
a flash component. Hence re-programming all modules would be another month
effort.
    Any better ideas - which can help me start optimizing the OGG/VORBIS
library. Something like memcopies that are avoidable etc etc... - similar to
direct copy to output buffer skipping copy from og->header and og->body...
On these lines?

Thanks
Sumit

2009/9/4 Petr Tomasek <tomasek at etf.cuni.cz>
> On Fri, Sep 04, 2009 at 12:14:32AM +0530, Sumit Chatterjee 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.
> >
> > Thanks
> > Sumit
>
> So You are talking about latency, right?
>
> What about CELT instead of Vorbis? (http://www.celt-codec.org/)
>
> P.T.
>
> --
> Petr Tomasek
<http://www.etf.cuni.cz/~tomasek<http://www.etf.cuni.cz/%7Etomasek>
> >
> Jabber: butrus at jabbim.cz
> SIP: butrus at ekiga.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090904/e22a355b/attachment.htm

For alternative, optimized Vorbis encoders you could take a look at:
http://wiki.xiph.org/VorbisEncoders
especially to the Lancer encoders.