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