VIP Deinterlacer in Motion Adaptive Mode Questions

Hello,

The algorithm you suggest is reasonable but this is not what Altera's deinterlacer is doing at the moment:

1) each incoming field is stored in memory

2) to produce one progressive output frame, the core has to read back 4 fields (including the current field)

For reference purpose here is how to compute the bandwidth requirements for the 9.0 motion adaptive deinterlacer for 1080i60 RGB (24-bits) -> 1080p RGB (24-bits) with double-buffering assuming that the data port with of the memory masters is 256 bits.

1) data sample packing efficiency:

the Avalon MM master interfaces pack 10 pixels per 256-bit words (10 x 24 = 240 bits) which means 1.6 bits are wasted for each 24 bit pixel

2) bandwidth required to write the 1080i60 input to memory:

1920 x 540 x (24+1.6 bits) x 60 fields/s = 1.593 Gbit/s

3a) bandwidth required to read 4 fields from memory to output 1080p30 (input frame rate = output frame rate)

1920 x 540 x 4 x (24+1.6 bits) x 30 frame/s = 3.185 Gbit/s

3b) bandwidth required to read 4 fields from memory to output 1080p60 (input field rate = output frame rate, smoother algorithm but may cause shimmering)

1920 x 540 x 4 x (24+1.6 bits) x 60 frame/s = 6.37 Gbit/s

Total for 1080p30: 1.593 + 3.185 = 4.778 Gbit/s

Total for 1080p60: 1.593 + 6.37 = 7.963 Gbit/s

Motion values are stored and read back from external memory if motion bleed is on. This will add:

4) motion sample packing efficiency

the Avalon MM master interfaces pack 32 motion values per 256-bit words (32 x 8 = 256 bits) which means there is no waste

5a) bandwidth required to write a motion field AND read a motion field assuming a 1080p30 output:

2 x 1920 x 540 x (8 bits) x 30 frame/s = 0.498 Gbit/s

5b) bandwidth required to write a motion field AND read a motion field assuming a 1080p60 output:

2 x 1920 x 540 x (8 bits) x 60 frame/s = 0.996 Gbit/s

Total for 1080p30 with motion bleed: 4.778 + 0.498 = 5.276 Gbit/s

Total for 1080p60 with motion bleed: 7.963 + 0. 996 = 8.959 Gbit/s

> This is about a 13% margin. Is this safe?

It is recommended to plan designs with a 25% margin and to use long bursts (32 or 64) but it seems your margin is much better than necessary.

> Does the de-interlacer work equally well for YUV (4:4:4) and RGB (4:4:4)

Yes, the algorithm would give slightly different results but this would be difficult to spot.

Kind regards,

vgs

---

edit: corrected bandwitch computation for the motion bleed

Hi Vgs,

Thanks for the thorough answer. Maybe I understand this incorrectly, but I think you have left out the accesses required to perform the double buffering. I basically agree with the accesses required for the 4 fields, but you still have to write the final calculated value to one of the two buffers, while the output section is busy reading out pixels form the other buffer. So you have two additional memory accesses to account. Not so?

Regards,

Niki

> I think you have left out the accesses required to perform the double buffering

No, the accesses you are mentioning do not exist. Once they are computed, the final calculated values are sent straight to the avalon streaming output and not to the memory. The architecture of Altera's deinterlacer is perhaps slightly different from what you are used to.

The double buffering functionality should be understood as "behaving like a double buffer" and it occurs before the deinterlacing is done. The deinterlacer behaves like a double buffer because input fields are sent to memory buffers owned by a "writer component". Meanwhile a "reader/deinterlacer component" is busy reading back four fields from a different set of buffers to produce a progressive output. In double-buffering mode, the writer and the reader swap buffers once both have completed their task. The reader component owns more buffers than the writer component (because it needs four fields) and it does not give all of them back at once, only the oldest.

I realize this is not crystal clear but I hope this will clear the misunderstanding.

vgs

Hi Vgs,

Thanks again! What you say makes sense and is surely a more optimal use of memory bandwidth.

Regards,

Niki

nikisteenkamp,

I've attached a spreadsheet that performs the calculations for you. The fields that you control are those highlighted in blue. Maybe it's useful for you. It is what it is. Let me know if you have any questions.

Jake

Hi Jake,

Thanks - it is definitely useful!

If your local memory width is 128 bits (if you are using 32-bit DDR2 memory), would it make any sense to increase the memory data width of the deinterlacer to a value above 128 (256 is the next value). I guess this would result in larger burst transfers which would increase efficiency (maybe slightly), but would also increase internal memory requirements?

Altera should consider putting some memory bandwidth requirements information in the user guide. Especially for this core where the internal working of the core is not so obvious to the user.

Regards,

Niki

No there is no reason to make the deinterlacer memory interface larger than the actual memory interface. This will simply waste resources and make it more difficult to meet timing. If your local memory interface is 128-bits wide, you should make your deinterlacer memory masters 128-bits wide. If you want to perform larger bursts, simply up the burst count.

Jake