Alex,
Thanks again for your response. I got this fixed late last night, it
seems the darn problem was that I had too many Debug Prints (DP) in my
driver some of them were in the interrupt context. All of these DPs
were being thrown out for every frame and in retrospect I'm guessing
it was
With the given info is hard to tell. Have you checked that the port
reconfiguration and the flushes execute correctly ? Those are 2 things
that the application always does at the beginning of every playback.
If everything looks good in that, probably you should look in lower
layers.
- Alex.
On
RockNCode,
Initially I had this wrong as I was updating in ms. Later, I checked
out the s/w decoder for its implementation (which just slaps the input
PTS onto the output buffer) and did the same. But this hasn't helped
either, here is the dump:
FetchOutput is complete, nFilledLen = 195840 PTS
I added some more debug prints and noticed that the engine state is in
PREPARING state (while it should ideally be in STARTED state). From
the below log, it looks like the Start( ) command didn't complete (coz
I don't see a command complete message for this):
**
Thanks Deva for your response. Yep, there are no issues in the
underlying decoder/driver. If I hold the display from going into
standby, I see prints all the way thru end-of-stream. If there were a
problem with the overlay, then how is it able to display the 1st
frame? Is there a call stack that I
Hi.
Have you printed you buffer timestamp values ? I've seen similar
issues when there is a problem with AV sync, probably your timestamp
resolution does not match PV's (it should be in microseconds).
- Regards.
On Jul 13, 8:02 am, HV harishv.athr...@gmail.com wrote:
Thanks Deva for your
