• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 357 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Omap 4460:Bad output data of decoder.

chang wenliang
Prodigy 180 points
Other Parts Discussed in Thread: 4460

Hi all,

In my case, function "void OmxCodecObserver::onMessage(const omx_message &message) " will get two messages of same timestamp(The first frame).

And after this, a message (the third or the forth one) who has the timestamp of one input frame , message.u.extended_buffer_data.range_length will be 0.

And all the frame after this frame will be decoded badly.

Here is the log.

sendInputData(478): in 0x404206d1   //Input bitstream 
sendInputData(478): in 0x40421757
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0 //output yuv
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
callOutputCallbackFunction(441): bufferSize=0
DataOutputThread(1063): Dequeue info:timestamp 0x0,mFrameSize:0
callOutputCallbackFunction(441): bufferSize=0
DataOutputThread(1063): Dequeue info:timestamp 0x0,mFrameSize:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
callOutputCallbackFunction(441): bufferSize=0
DataOutputThread(1063): Dequeue info:timestamp 0x0,mFrameSize:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
callOutputCallbackFunction(441): bufferSize=0
DataOutputThread(1063): Dequeue info:timestamp 0x0,mFrameSize:0
callOutputCallbackFunction(441): bufferSize=0
DataOutputThread(1063): Dequeue info:timestamp 0x0,mFrameSize:0
sendInputData(478): in 0x40422459
sendInputData(478): in 0x40422f99
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x404206d1,size:170432,Islast:0
callOutputCallbackFunction(441): bufferSize=170432
DataOutputThread(1063): Dequeue info:timestamp 0x404206d1,mFrameSize:170432
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x404206d1,size:170432,Islast:0  //two frames have the same timestamp
callOutputCallbackFunction(441): bufferSize=170432
DataOutputThread(1063): Dequeue info:timestamp 0x404206d1,mFrameSize:170432
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x40421757,size:170432,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x40422459,size:0,Islast:0   //The size of this frame is 0.
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x0,size:0,Islast:0
sendInputData(478): in 0x40426941
onOmxObserverFillBufferDone(1019): Add info:timestamp 0x40422f99,size:170432,Islast:0
callOutputCallbackFunction(441): bufferSize=170432
DataOutputThread(1063): Dequeue info:timestamp 0x40422f99,mFrameSize:170432


All the above is based android 4.0 and omap 4460.

  • 0
    TI__Genius 10545 points

    Chang;

    Could you provide some little more of information?

    1. is this with 4AI1.4P1? 4AI1..5? or other release?

    2. is it using Blaze, Tablet or Panda?

    3. is it an isolated test case? or file? or VTC test case?

    4. can you describe about test case?

    5. for what format is it happening?

    6. is it using Android Gallery? or custom application?

    In general answer, for Codec Data timestamps provided by Video encoder are not getting a valid timstamps since they are not part of the video stream frames, they are codec data, the repetition of frames could be because of port reconfiguration sending 2 times the first frame.

    7.

  • 0 in reply to Manuel Contreras
    Prodigy 180 points

    thank you for your reply.

    I already found out why there are two same timestamp frames for decoder will reconfigure the parameters.When I init the right width and height, it will output only one first timestamp frame.

    However the  frame whose size is 0 already  exists.And it always is the second frame.

     

    1.I don't know the version of it, and how can I get the version?

    2.samsung nexus or Huawei P1.

    3.VTC test case

    4.The frame following the  lost   may refer a frame  that is all gray.

    5.OMX_TI_COLOR_FormatYUV420PackedSemiPlanar

    6.It is using Android Gallery.

     

     

  • 0 in reply to Manuel Contreras
    Prodigy 180 points

    I can't upload the file in the company.

    If Y U V of  the second frame are  all 0x80(actually not output a frame), the third frame will be equal to the actual output  frame.

  • 0 in reply to chang wenliang
    TI__Genius 10545 points

    Can you specify a little more the test case?

    I can see 3 possibilities: ( base in that you are using a Samsung Nexus):

    1. You are writing your own application or VTC code, by the other post it could be because incompatible baselines, missing patches, etc,

    http://e2e.ti.com/support/omap/f/849/p/197672/706831.aspx#706831

    In this case I should only recommend to use OpenMax AL from Android NDK that it is meant to run independent of device. And that in this case is not possible to provide support to your application.

    2. If you are using Gallery application then input file needs to be check to see how it was encoded and if it contains errors, or if it plays ok in other devices.

    3. If you are doing port reconfiguration ok and all goes fine, then check that first buffer send for decoding contains SPS+PPS, second Iframe, then third a Pframe. In some cases if this order is missed it results in gray output when SPS+PPS are not correct or correctly configured.