• State Answer Suggested
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 4706 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 P-frame corruption?

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

All-

First the particulars:

  • DM814x
  • TVP5158 video decoders
  • DVRRDK 03.00.01.03
  • REL.500.V.H264AVC.E.IVAHD.02.00.02.02
  • Custom multi-channel encode / single-channel decode application based directly on Links APIs.
  • Encode chain is as follows:   (CaptureLink --> DeiLink --> MergeLink --> IpcLink (m3vpss out) --> IpcLink (m3video in) --> EncodeLink --> IpcBitsOutLink (m3video out) --> IpcBitsInLink (A8 in).
  • Encode channels (H.264, SD) are muxed into MPEG-2 transport streams and transferred via PCIe to a host system for storage.

We're experiencing an issue where H.264 streams begin to contain corrupted P-frames after being captured for some time.  These P-frames exhibit numerous visible artifacts when decoded:

I-frames are still always OK (only tested at a GOP size of 15), and the artifacts are present regardless of decoder (we've tested on the DM814x as well as with VLC and MPlayer).

This does not typically occur on all streams (i.e. streams 1 & 2 may exhibit this problem, but all the rest are fine), nor does it typically occur with the same streams (i.e. may be streams 1 & 2 on this test, but 3 & 5 on the next).  This does not occur on every capture, nor does it always occur after just a few minutes or several hours.

I've tried integrating codec version REL.500.V.H264AVC.E.IVAHD.02.00.04.01, but this version still exhibits the issue at times.

Our design also allows for MPEG-2 encode/decode; we've never had any similar issues when using the MPEG-2 codec (i.e. doubtful it's related to TS muxing or PCIe transfer to the host).

To my eye, it seems to be a codec issue, given the "block" nature of the artifacts and the fact that it's only ever P-frames that exhibit the issue.

I've attached a short sample TS which shows the problem, and would appreciate any thoughts as to root cause for what's happening here.

Thanks!

-Cory

1727.p_frame.ts.gz

  • 0
    Intellectual 600 points
    Dear Cory,

    Since the issue is not observed all the time, we can hardly doubt the parameters you are setting to the encoder.

    Also I could observe huge values at times for P macroblocks, there is a chance that even the reference frame buffer might have got corrupted. Since I frames are independent of any reference frames, they would be fine even in such a scenario. Could you please make sure the reference frame buffers are not getting corrupted by any means ?

    Best Regards,
    Nandu.
  • 0 in reply to Nandu Krishnan Arul
    Intellectual 475 points
    Nandu-

    Thank you for the follow-up. I'd agree that the parameters to the codec are otherwise correct; we see valid H.264 streams across multiple channels for long periods of time before this issue occurs. As a side note, we've tested both BASE and MAIN profiles, and observed the same problem. Anecdotally, the issue seems to occur most often on the "lowest" two channels - i.e. channels 0 and 1 of the TVP5158 that's connected to VIP0A.

    We're making use of TI's DVRRDK middleware, so all frame buffer allocation and management is handled in the corresponding Link implementation(s). I'm not sure how easy it would be to dump reference frames back to the A8 for examination, especially given that we usually don't realize there's an issue until the stream has been captured to disk and played back at a later time.

    Any suggestions for how to validate the reference buffer(s)?

    Would an unchained P-frame configuration possibly help in this situation?

    What about using GDR?

    Thanks!

    -Cory
  • 0 in reply to Cory Tusar
    Intellectual 475 points

    Bump...

    Nandu-

    Any thoughts on my questions above?  Thanks!

    -Cory

  • 0 in reply to Cory Tusar
    Intellectual 475 points

    Bump...

    We've done a bit more testing on this item, and have updated the H.264 codecs to REL.500.V.H264AVC.E.IVAHD.02.00.06.00 (the version included with the latest DVRRDK release), but are still seeing this issue intermittently.  I've attached a number of screenshots below, which show the per-MB coding type for two successive frames - the first an I-frame, the second a P-frame.  The distortion that we're seeing is only ever present on macroblocks which have motion vector data associated with them.

    Any additional thoughts on this issue would be appreciated; this is the last remaining item we're working to resolve for final customer sign-off.

    Thanks!

    -Cory

  • 0 in reply to Cory Tusar
    Expert 2285 points

    Hi Cory,

                 Can you upload the stream where you had observed this behaviour. If I look at the old bitstream you had uploaded, looks some issue with the reference.

    But to know this issue need bitstream to analyse more on it.

    Regards

    Gajanan

  • 0 in reply to Gajanan Maske
    Intellectual 475 points

    Gajanan-

    Below is a link to the file used in my investigation above.  Any insight you can provide would be appreciated.

    https://www.dropbox.com/s/nat1v7eszj97cw1/capture00-03.264?dl=0

    I've reviewed the release notes for all of the newer versions of DVRRDK and don't see anything relating to a fix for reference frame corruption / overwriting / etc.  I assume that this functionality (i.e. reference frame buffer allocation, tracking and management) are part of the BIOS6 implementation running on the M3-Video core?  Is there a specific area I should be looking for relevant fixes between versions?  (Most of BIOS6 is a black-box to us...all of our driver and application implementation has been on the A8 under Linux.)

    Also, would it be worthwhile to try modifying the motion estimation mode used and/or the search range to see if that has any beneficial effect?

    Thanks!

    -Cory

  • 0 in reply to Cory Tusar
    Expert 2285 points

    Hi Cory,

    The behaviour is similar to previous bitstream which you shared before. Observation is more number of intra macroblocks are selected instead of inter macroblocks. So conclusion may be reference frame is going wrong(may be corruption happening to the reference frame or Encoder may be pointed to wrong data). For both scenario's, debuing issue is  hard (since it observed only in MultiChannel and random in nature). 

    I hope normally you may be observing less intra Macroblocks in the bitstream. Can you try with IDRFrameinterval to 15 & try to reproduce the same issue. 

    May be this resolve the issue.

    Regards

    Gajanan