• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 837 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.

H.264 SD decode video display offset

Cory Tusar
Intellectual 475 points
Other Parts Discussed in Thread: TVP5158

All-

We're currently using DVRRDK-03.00.01.03 on a custom board with 2x TVP5158 front-end decoders.  We can successfully capture multiple streams of H.264 (and MPEG-2) SD video, mux / de-mux them into transport streams, and play them back externally.  When we attempt to play back captured streams using the DM814x, however, the output image is offset down and to the right rather than being properly aligned.  I've included a number of photos and explanations below which illustrate this issue.

The reference signal we're testing with, taken directly from a signal generator into a monitor looks like this (note the 2.5% green overscan marks, as well as my sticky notes showing image extents due to scaling & cropping on the monitor):

When we pass video through our board without any encode / decode (CaptureLink --> DisplayLink), we see a similar result (chroma-slop aside):

When we capture and encode the video (CaptureLink --> DeiLink --> MergeLink --> IpcLink (m3vpss out) --> IpcLink (m3video in) --> EncLink --> IpcBitsOutLink --> IpcBitsInLink), the resultant stream shows the full extent of the test pattern when played back in VLC or mplayer as expected (note the white 0% overscan line around the outside):

However, when we decode this exact same file on the DM814x (IpcBitsOutLink --> IpcBitsInLink --> DecLink --> IpcLink (m3video out) --> IpcLink (m3vpss in) --> DisplayLink) and output via SDDAC(SEC1), the resultant image is shifted down and to the right - note the grey cruft at the top and left-hand side:

I've also verified that the SDDAC alignment looks otherwise OK when the internal colorbars are enabled:

More importantly, I've verified that the decode chain otherwise works with TI's IVAHD MPEG-2 video decode codec.  We've integrated both that codec as well as a third-party MPEG-2 video encode codec into our stack.  The setup for H.264 vs. MPEG-2 is almost identical except for the codec instantiated, and we see no such offset when decoding MPEG-2:

I'd appreciate any ideas on where to look for a solution to this...

  • I've tried pulling in newer versions of the H.264 decode codec with no success (current version is REL.500.V.H264AVC.D.HP.IVAHD.02.00.05.00, and I've also tested with REL.500.V.H264AVC.D.HP.IVAHD.02.00.08.00).
  • I've tested with both NTSC and PAL inputs.  Results were similar (offset on H.264 decode on DM814x, no offset and proper 0% overscan with VLC or mplayer, no offset with MPEG-2 codec set).
  • I've tested with just raw H.264 and MPEG-2 video ES (i.e. no transport stream mux / demux).  Results were similar...

Thanks!
-Cory

  • 0
    TI__Guru 59700 points

    - H264 decoder uses the decoder output buffer as also the reference buffer for decoding future frames and the output buffer and reference buffer are reference counted versions of the same physical buffer

    - H264 standard mandates padding the image by extending the last pixel of the image and this is required for the reference buffer for correct decoding

    - The issue you are seeing is because you are displaying this decoded frame starting from (0,0). The actual image removing padding starts at (32,24) in the image. This info is exported in the frameInfo that is sent out of the decoder.

    - DisplayLink doesnt handle startX,startY offset other than 0,0 so it is an issue when you connect decode output directly to display

    To fix the issue you can either add a SwMs link or Scaler link before displayLink which will correctly handle the offset or modify dispalyLink to handle offset management. Modifying displayLink is not recommended.

  • 0 in reply to Badri Narayanan
    Intellectual 475 points

    Badri-

    Thanks for the detailed explanation - we didn't realize that the display buffer was also being used as a reference for subsequent decode operations (although it makes perfect sense in hindsight).

    Modifying the chain to include a 1:1 scaler element (IpcBitsOutLink --> IpcBitsInLink --> DecLink --> IpcLink (m3video out) --> IpcLink (m3vpss in) --> SclrLink --> DisplayLink) results in properly positioned video output.

    -Cory