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