[Vorbis-dev] Urgent Doubt in VORBIS

Conrad Parker conrad at metadecks.org
Sat Aug 29 13:49:15 PDT 2009


2009/8/29 Sumit Chatterjee <getsumit at gmail.com>:
> Hi Conrad..
>     Actually no, I am not using the wrote(0) function. Its a live stream, so
> basically the data feed never stops. I basically need to maintain synch
> between the raw sample and decoded stream.

Then what you are doing is the best you can do. It'll probably help if
you read the "Decode Procedure" and "overlap add" parts of the codec
spec:

http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html

If you want to correlate which packes are required to decode a given
amount of input PCM, simply wait for a large enough granulepos.

If you have realtime latency constraints then you should consider
using a different codec, such as CELT: http://www.celt-codec.org/

>    By the way I can try using vorbis_analysis_wrote(&vd, 0) retreive the
> correct granulepos value and then continue with my encoding. Will I get
> continuous encoded stream by doing this?

You would need to start a new stream afterwards. You should call
vorbis_analysis_wrote(&vd, 0) at the end of the stream, ie. before
closing the socket (if you make a separate encode for each client) or
after the data feed stops.

Conrad.

> 2009/8/29 Conrad Parker <conrad at metadecks.org>
>>
>> 2009/8/28 Sumit Chatterjee <getsumit at gmail.com>:
>> > Hey Mike,
>> >        Sorry its actually 4am in the morning, so my brain isnt working
>> > that
>> > much. Here goes the explanation:
>> >       Step 1: raw sample --> encode. Here while encoding , as I get
>> > packets,
>> > I record the granulepos used up for that packet, which gives me the pcm
>> > consumed.
>> >       Step 2: The packet and pcm are sent to another program through
>> > sockets, wherein the received packet is decoded.
>> >       Step 3: The decoded pcm size is matched with the  pcm size sent
>> > corresponding to the encoded packet.
>> >
>> >       Also to add to the details: I have changed the buffering mechanism
>> > of
>> > OGG container to 2KB from 4KB
>> >
>> >
>> > The basic problem is in Step 1, where I feel, I may have to deduct an
>> > offset
>> > in the beginning before using the granulepos structure element - is it
>> > so?
>>
>> no, the granulepos returned in the ogg_packet structure is correct.
>>
>> During the stream, the granulepos represents the number of decodable
>> frames, which will lag behind the number of frames consumed (due to
>> overlap-add). That is normal.
>>
>> At the end of the encode this will be fixed. Are you calling
>> vorbis_analysis_wrote(&vd, 0) at the end of the input data?
>>
>> Conrad.
>>
>> >
>> > 2009/8/28 Michael Smith <msmith at xiph.org>
>> >>
>> >> On Thu, Aug 27, 2009 at 3:09 PM, Sumit Chatterjee<getsumit at gmail.com>
>> >> wrote:
>> >> > Hi Mike,
>> >> >     I was having a big problem earlier as there was a mismatch of
>> >> > over
>> >> > 16-20KB sometimes.
>> >> >     I have solved that problem now. After lot of debugging I could
>> >> > find
>> >> > out
>> >> > that granulepos wasn't being used at the correct place for
>> >> > identifying
>> >> > the
>> >> > pcm size of the data encoded.
>> >> >
>> >> >     BUT, currently I have a minor issue still left on the same lines.
>> >> > If
>> >> > I
>> >> > send the pcm size of the encoded data to another machine, and decode
>> >> > the
>> >> > encoded stream, there is "always" a mismatch of 4096 bytes :(
>> >> > Regarding
>> >> > your
>> >> > suggestion currently my mearsurement is on the same base(integer).
>> >>
>> >> I can only assume you have a bug in your code then. I can't help much
>> >> more specifically than that - you haven't provided any information
>> >> about what you're doing.
>> >>
>> >> Mike
>> >
>> >
>> > _______________________________________________
>> > Vorbis-dev mailing list
>> > Vorbis-dev at xiph.org
>> > http://lists.xiph.org/mailman/listinfo/vorbis-dev
>> >
>> >
>
>


More information about the Vorbis-dev mailing list