ogg dev - Feb 2010 - ogg decoding without "synchronization"

Hi list,

I have an artistic project in which I manipulate streams.
At the moment I'm using ogg vorbis streams, Icecast servers and the 
multimedia puredata software.

In this project I would like to read an ogg stream from an icecast 
server and decode data in the order it is incoming.
I would like to skip the step that is reordering the data conforming to 
the order it was send.

Do you know if something like that is possible?
As far as I understand, the ogg layer is in charge of reordering this data.
But I'm not really understanding if and how it reorganizes the pages, 
the packets, or both.

I've seen this granulepos info that seems interesting for what i'm 
searching, but i don't understand if it's an absolute position since the
beginning of the stream and how i can manipulate it to eventually 
renumber the incoming data.

I'm working above this piece of code:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pdogg/oggamp~/oggamp~.c?revision=12846&view=markup
and under ubuntu 9.10 or osx 10.5.

Do i have a possibility to decode the sound in the order of the incoming 
data?
Any idea is welcome.
Let me know if i'm not clear enough or if you need more infos.

Thanks for your help,

Nicolas
-- 
http://nim.on.free.fr


Ce message a ?t? analys? contre les 'malwares' par Websense.
www.websense.com

On 24 February 2010 16:45, Nicolas Montgermont
<nicolas_montgermont at yahoo.fr> wrote:
> In this project I would like to read an ogg stream from an icecast
> server and decode data in the order it is incoming.
> I would like to skip the step that is reordering the data conforming to
> the order it was send.
The data reordering happens a couple of layers below the ogg
encapsulation, which itself assumes the data is in order. Icecast
sends the Ogg streams over HTTP, which is itself carried over the TCP
protocol, which does the reordering inside the kernel.

You could do what you want if you sent the vorbis data over RTP (in
UDP datagrams) instead of icecast's ogg-over-http approach. I believe
gstreamer can do this, with rtpvorbispay/depay, etc. There's also some
sample code at http://svn.xiph.org/trunk/xiph-rtp/ (possibly it's out
of date relative to the spec; I haven't looked at it in a few years).
UDP packets aren't reordered by the OS kernel's networking stack so
you can access the delivery order directly in your application.

Hope that helps,
 -r

thanks for the explanations.
i'm trying to work with udp now and it's seems a very interesting path.
all the best,

n

Le 25/02/10 02:42, Ralph Giles a ?crit :
> On 24 February 2010 16:45, Nicolas Montgermont
> <nicolas_montgermont at yahoo.fr> wrote:
>
>   
>> In this project I would like to read an ogg stream from an icecast
>> server and decode data in the order it is incoming.
>> I would like to skip the step that is reordering the data conforming to
>> the order it was send.
>>     
>
> The data reordering happens a couple of layers below the ogg
> encapsulation, which itself assumes the data is in order. Icecast
> sends the Ogg streams over HTTP, which is itself carried over the TCP
> protocol, which does the reordering inside the kernel.
>
> You could do what you want if you sent the vorbis data over RTP (in
> UDP datagrams) instead of icecast's ogg-over-http approach. I believe
> gstreamer can do this, with rtpvorbispay/depay, etc. There's also some
> sample code at http://svn.xiph.org/trunk/xiph-rtp/ (possibly it's out
> of date relative to the spec; I haven't looked at it in a few years).
> UDP packets aren't reordered by the OS kernel's networking stack so
> you can access the delivery order directly in your application.
>
> Hope that helps,
>  -r
>
>   
-- 
http://nim.on.free.fr


Ce message a ?t? analys? contre les 'malwares' par Websense.
www.websense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/ogg-dev/attachments/20100225/deaff99f/attachment.htm