Hey Mike,<br> Sorry its actually 4am in the morning, so my brain isnt working that much. Here goes the explanation:<br> 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.<br>
Step 2: The packet and pcm are sent to another program through sockets, wherein the received packet is decoded.<br> Step 3: The decoded pcm size is matched with the pcm size sent corresponding to the encoded packet.<br>
<br> Also to add to the details: I have changed the buffering mechanism of 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 in the beginning before using the granulepos structure element - is it so?<br>
<br>Thanks<br>Sumit<br> <br><br><div class="gmail_quote">2009/8/28 Michael Smith <span dir="ltr"><<a href="mailto:msmith@xiph.org">msmith@xiph.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;">
<div class="im">On Thu, Aug 27, 2009 at 3:09 PM, Sumit Chatterjee<<a href="mailto:getsumit@gmail.com">getsumit@gmail.com</a>> 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 out<br>
> that granulepos wasn't being used at the correct place for identifying the<br>
> pcm size of the data encoded.<br>
><br>
> BUT, currently I have a minor issue still left on the same lines. If 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 your<br>
> suggestion currently my mearsurement is on the same base(integer).<br>
<br>
</div>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>
</blockquote></div><br>