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.

the time stamps of decoded frames

I use DVR RDK 3.50.00.06 to decode h.264 and get yuv raw data.  If I set the "displayDelay" flag to be "2" for correcting "display order", it did work but got wrong time stamps.  It looks like to correct the order of decoded frames but not correct the time stamps of decoded frames.

I don't know how to get right time stamps.  Can anyone help me?  Thanks!!

  • How are you setting the timestamp when you feed the bitstream buffer in Vdec_putBitstreamBuffer. Application should set the correct timestamp based on display order not decode order for the output timestamp to be correct

  • I set the timestamp with the following code:

    pEmptyBuf->lowerTimeStamp = (UInt32) (buffer->timeStamp & 0xFFFFFFFF);

    pEmptyBuf->upperTimeStamp = (UInt32) ((buffer->timeStamp >> 32)& 0xFFFFFFFF);

     

    I use gstreamer tools to read-in and demux a h264 file, and set the timestamp with those of gst_buffer:

    curTimeStamp = GST_BUFFER_TIMESTAMP(buffer) / 1000000;  // nanosecond -> millisecond

     

    I don't know those are display order or decode order.  (I'll check this).  Furthermore, it seems hard to chage the timestamp from decode order to display order without partially decoding.

  • I printed out the messages about the timestamp of decoded frames.

     

    displaydelay    = 2: frames are arrived with display order, but strange timestamp

    [136]: timestamp=15.014

    [136]: timestamp=15.098

    [148]: timestamp=15.056 *

    [136]: timestamp=15.181

    [148]: timestamp=15.140 *

    [136]: timestamp=15.306

    [148]: timestamp=15.265 *

    [148]: timestamp=15.223 *

    [136]: timestamp=15.432

    [148]: timestamp=15.390 *

    [148]: timestamp=15.348 *

    [136]: timestamp=15.557

    [148]: timestamp=15.515 *

    [136]: timestamp=15.598

    [148]: timestamp=15.473 *

    [136]: timestamp=15.724

    [148]: timestamp=15.682 *

    [148]: timestamp=15.640 *

    [136]: timestamp=15.849

    [148]: timestamp=15.807 *

    [136]: timestamp=15.890

    [148]: timestamp=15.765 *

    [136]: timestamp=16.015

    [148]: timestamp=15.974 *

    [148]: timestamp=15.932 *

     

    displaydelay    = 0 : frames are NOT arrived with display order

    [136]: timestamp=15.014

    [136]: timestamp=15.056

    [136]: timestamp=15.098

    [136]: timestamp=15.140

    [136]: timestamp=15.181

    [136]: timestamp=15.223

    [136]: timestamp=15.265

    [136]: timestamp=15.306

    [136]: timestamp=15.348

    [136]: timestamp=15.390

    [136]: timestamp=15.432

    [136]: timestamp=15.473

    [136]: timestamp=15.515

    [136]: timestamp=15.557

    [136]: timestamp=15.598

    [136]: timestamp=15.640

    [136]: timestamp=15.682

    [136]: timestamp=15.724

    [136]: timestamp=15.765

    [136]: timestamp=15.807

    [136]: timestamp=15.849

    [136]: timestamp=15.890

    [136]: timestamp=15.932

    [136]: timestamp=15.974

     

  • Does the stream have B-frames ? Decode will output correctly in display order as long as correct display delay is set. If you are seeing correct display on screen (i.e video is moving smoothly) but seeing incorrect timestamp it means issue is with setting the timestamp by the application. Gstreamer should demux and get the correct timestamp. Check with a stream analyzer and confirm the frame timestamp is same as what you are feeding decoder.

  • > Does the stream have B-frames ?

    Yes.

    > If you are seeing correct display on screen (i.e video is moving smoothly) but seeing incorrect timestamp

    Yes.

    > it means issue is with setting the timestamp by the application.

     

    > Check with a stream analyzer and confirm the frame timestamp is same as what you are feeding decoder.

    Ok. I'll check it.

    Thanks!