De-Interlacing Video Quality Loss in DM36x

Hi Anirudh,

Can you please prove the below details:

1. The Video Encoder you are using and its version
2. The complete set of parameters used by you.

Hello Prashanth,

The encode as well as de-interlace use the DM-365's / DM-368's media co-processors through:
• TI.SDO.CE.video1; 1, 0, 2,269 [Is this relevant?]
• XDAIS 6.26.01.03
• XDC Tools 3.16.03.36

In addition to these, I'm unable to find any tools with versions that affect the co-processor.

The de-interlacer's static configurations are:
• Width and Height of the video frames: 704x576
• Input Format: UYVY422 (YUV422ILE)
• Output Format: NV12 (YUV420SP)
• 8-bit Threshold: 0

• Y-UV Planar Gap for the output: 0 units

There are no relevant dynamic parameters, since these are simply buffer addresses.

I'd tinkered with both the motion threshold and the planar gap to empirically identify its impact on the quality. I found that the noise appeared different, although it was equally bad when quantified by gradients of intensity around certain noisy pixels.

Thanks,

Anirudh

Hi Anirudh,

Thanks for the details.

Can you please check weather the same instance captured Top-Field & Bottom Fields are present in de-interlaced video. The issue might be observed when Top & bottom fields are of different instance.

Also Please check are there any missing fields. There should be no missing fields.

Hi Prashanth,

I have verified that the same instance produces both the fields in the input buffer. Besides, by dumping the content of the buffer directly into the secondary memory, I'm able to reconstruct the video independently, using FFMPEG on my workstation, with these fields. This tells me that the input video is the way it should be.

Thanks,

Anirudh

Hi Prashanth,

If I understand correctly from the DEI release notes, v2.00.00 of the algorithm features an improvement that addresses the problem of "staircase effect" in particular. However, I am unable to obtain the source code / pre-built binaries of this.

Based on this discussion, I do not think the implementation I am using is independently causing any quality loss, which means that simply upgrading the DEI algorithm should resolve this issue.

That brings me to this situation - Would you know of a repository from where I can download the latest version of this algorithm?

Thanks,

Anirudh

Can you increase the bitrate of the encoder and confirm it is coming from DEI?
Or set the video encoder to encode using fixed QP value
or use JPEG encoder with quality factor as high as 95 to confirm that it is the issue with DEI.

Hello Karthick,

Thank you very much for the tip!

In our use case, if simplified, the video handling pipeline goes as follows:

Capture ----(UYVY422)---> De-Interlace ----(NV12)---> Resize ----(NV12)---> Encode / Compress (either H.264 or MJPEG)

The images I have attached earlier are frames from video sampled at the beginning and at the end of the de-interlace. Regardless of the usage of the encode / compress process or its configurations, such as the bit rate for H.264 or the quality factor for MJPEG, these images are going to be as such.

Naturally, encode / compress would cause subsequent quality loss, which would introduce noise that, theoretically, from the design of the encoding / compression algorithm, would not fit into this "staircase" pattern.

These are the reasons for this problem being restricted to the de-interlacer. The encoder would not have anything to do with the occurrence of the quality loss between these two images.

Based on Prashanth's inputs, it has been established that the portion of the application software that handles de-interlacing is robust - isolating the problem to the codec / middleware.

Thanks,

Anirudh