My bad on the size, I was using nSize instead of nFilledLen and hence
was always getting 80. With that change, I see that to being with i
get 32 bytes and then there is a huge chunk coming in which is indeed
the VOP data, but it is still not associated with the 1st I-frame!!

Next I took out my .cfg file and let the PV software based decoder
take over & printed the 1st few bytes of the input data. To my
surprise, I see the same data there as well. Is the MPEG-4 demux is
manipulating data here??

HV

On Jun 16, 4:37 pm, HV <[email protected]> wrote:
> Hi Folks,
>
>  I have completed the plugin part and calling my decoder library using
> the incoming buffers, but I have run into a strange issue. The 1st
> buffer starts off OK with the VOL start code and the associated start
> code. But after the VOL data ends, I was expecting the VOP start code/
> data to start, but I see some junk (I've compared against the actual
> bit-stream). Any idea why this is so?
>
>  However, my decoder is able to decipher the VOL data correctly and
> then I start reading the next buffer which indeed starts off with the
> VOP header but the data does NOT point to the 1st I-Frame at all. It's
> way off somewhere (again compared against the input file). I'm
> guessing this problem will go away if I can fix the 1st issue (no VOP
> start code following the VOL data).
>
>  Also, I see that all the buffers (I get 3 calls into EmptyThisBuffer)
> are of the same size (80 bytes). Would appreciate any feedback
>
> Best regards
> HV

-- 
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting

Reply via email to