De-Interlaced with RDK

Hi Badri,

In order to work with regular process API instead of ProcessN, can we just process the frames one after the other in a loop, without a need for any buffering?

Also about the translation of the form of frames to HDVPSS, is it something simple to be done ?

I want to evaluate this changes to see if we can do this ourselves so that it is ready on time.

Thank you,

Ran

Sorry I did understand your comment about

In order to work with regular process API instead of ProcessN, can we just process the frames one after the other in a loop, without a need for any buffering?

Also about the translation of the form of frames to HDVPSS, is it something simple to be done ?

 - We are looing into the changes. We dotn have an estimate of the effort yet but the changes involve the following in decLink:

   1. H264 decoder outputs both top and bottom fields in a single buffer.

   2. The decLink should take this output buffer, dup it to create two FVID2_Frames and then adjust the buffer pointer such that one FVID2_Frame points to top field and another points to bottom fields.The FID of the frame should then be set correctly and released to the next component.

  3. When the next link frees the buffers the refCnt is decremented and once it reaches 0 buffer is freed. This behavious is similar to the exsting dup feature in decLink.

Regarding ProcessN, if I understand correct, this is API for processing N frames in codec. What I said before is that the relevant change in RDK should probably be to use API for processing 1 frame instead of this API, right ? I ask if this mean that we should do a kind of loop for processing N frames with the API for processing single frame, doing this one after the other for the N frames.

Thanks, Ran

processN means one frames from multiple channels are submitted to the IVA_HD in a single process call. This is done to maximise IVA utilization and improve channel density.

To disable processN enable define

//#define SYSTEM_DEBUG_DISABLE_PROCESS_MULTI

in /dvr_rdk/mcfw/interfaces/link_api/system_debug.h

>This behavior is similar to the existing dup feature in decLink.

Is there already a dup feature in decLink ? Is it the same dup as in 2. ?

Thanks,

Ran

Is there already a dup feature in decLink ?

 - Yes

Is it the same dup as in 2. ?

 - (2) has to be implemented using the exercise the dup feature.It is not implemented yet.

One last thing on this issue please, concerning what you said

>RDK framework fully supports interlaced encoding but until the codec issue is resolved we will not support interlaced encoding

If the propused solution will involves disabling N Process in framework, There will be no codec issue to resolve in codec itself  (I'm just trying to figure out what component should be fixed in the propused solution). Please correct me if I'm wrong....

Many Thanks !

Ran

Yes this is correct but since we cant disable processN in RDK we have not check this. Interlaced encoding worked before we integrated codecs supporting processN APIs.

Badri,

Thanks a lot,

have a good weekend,

Ran

I use the release summary and release notes for understanding the features and limitations in RDK versions. In RDK summary.pdf it is says in "DM816x Specific Features: Interlaced Encode/Decode dataflow supported for higher performance display usecases • 16 Channel D1 capture and encode in field mode". As I understand now this text in summary is not valid. I ask just to be sure I understand this text context and terminology correct, or if they mean something else than what I thought...

Thanks!

Ran

You are right.This feature is not supported and the release notes iw wrong. Sorry for the inconvenience. We will correct it in the next release.

DVR RDK 3.5 appears to have the same interlaced encoding issues -

the VLC decode shows occasional macroblock errors.

Reducing the encoder batch size to 1 (field at a time) did not help.

In EZSDK 5.05 (H.264 encoder v02.00.02.02),

interlaced encoding in field-at-a-time mode works OK.

Is there any plan to support interlaced encode in RDK?

We are working on interlaced encode/decode support and the feature will be available as part of the upcoming DVR RDK 4.0 release which will be available 3rd week of April 2013

Badri,

Thanks for the timely reply.

If a simple patch for interlaced encode on DVR RDK 3.5 exists,
I would appreciate it, otherwise I will await the release.

Regards,

John Whittington

Will let you know by middle of next week if fixes can be shared as patch. If the changes are extensive it would be difficult to share as patch.

Any update on when DVR-RDK 4 will be released?

RDK 4.0 will be available end of this month.