Deinterlacing

[BatterseaSteve]

Hi
I have a simple question I hope someone may be able to answer:

What pixel format do the Deinterlacing methods (CAVT et al) work in.
Looking at other forum posts I can see that this question has been asked but I cannot see a definative answer.
I have seen mention that each plane must be deinterlaced separately for RGBA. But (and I may show my ignorance here!)
will this work for YUV. i.e. what should I do with YUV420/YUV422/YUV411 for both planar and packed.

Cheers

[Ying_H_Intel]

Hello,

For your question, there aretwo factors we need consider ,
1) see the ippiman.pdf,
ipp provide several deinterlacingfunction as
ippiDeinterlaceFilterCAVT_8u_C1R,
ippiDeinterlaceFilterTriangle_8u_C1R
ippiDeinterlaceMotionAdaptive_8u_C1

They are all with the postfix _8u_C1 function, which mean they will accept processes 1 channel or a single plane image.

2) see the IPPumc sample,umc_deinterlacing.cpp
for (k = 0; k < in->GetNumPlanes(); k++) {
VideoData::PlaneInfo srcPlane;
const Ipp8u *pSrc0; //, *pSrc1;
Ipp8u *pDst0, *pDst1;
int srcPitch, dstPitch;
IppiSize size;

in->GetPlaneInfo(&srcPlane, k);
pSrc0 = (const Ipp8u*)in->GetPlanePointer(k);

So you may see that the Deinterlacing methods mainly support planar format, YUV420,YUV422/YUV411 planarformat should be work. If with RGBA or packed formart, then needuseeach plane.

One more tiny thing Ihave to mention is that may be that some special algorithms like the Motion Adaptive algorithm, it allows use for some packed format, for example, YUY2 packet format (YUYVYUYV..., you may take plane width as 2*plane_width_in_pixels). But forother algorithms, involving horizontally adjacent pixels in the calculations,will be not applicable for packed format.

Regards,
Ying H

[BatterseaSteve]

Hi Ying
Thanks for your reply - v useful.
Yes - I gdb'd the simple_player and deduced that it was deinterlacing YUV planar.
I did actually try putting YUY2 thru the CAVT deinterlacer and it surprisingly gave back a
dinterlaced frame - but it was not especially great. Howver, since I was also upscaling I could not work out whether it was
the deinterlacer that made it look bad or the upscaling from SD to HD.

Your comment regarding Motion Adaptive is interesting - our prob is that it requires 4 frames (understandably) -
which would - in some circumstances - be unacceptable thru our system.
Once I get the CAVT working I will look at this.

Another couple of questions if you have time....

a) Would the MotionAdaptive be quicker than the CAVT or slower?

b) We need to convert all clips to UYVY. To do this for 420p I call
ippiYCbCr420To422_Interlace_8u_P3R
for each 422 plane
ippiDeinterlaceFilterCAVT_8u_C1R
ippiYCbCr422_8u_P3C2R
ippiYCbCr422ToCbYCr422_8u_C2R
Would it be better (quality/speed) to deinterlace the 420p/411p before conversion?

c) Am I correct in assuming that if I need to resize an interlaced frame I should deiterlace first?
Or is there another way?


Cheers

[Ying_H_Intel]

Hi BatterseaSteve,

a) No, i guess the Motion Adaptive is not quicker as the speed mainly depends on algorithm complex. I hadtried to measure the speed with the tools, tools\perfsys\readme.htm, unlucky, it haven't tested the functions. So you may do the test quicky if you have data ready.

b) Would it be better (quality/speed) to deinterlace the 420p/411p before conversion? and try putting YUY2 thru the CAVT deinterlacer and it surprisingly gave back a dinterlaced frame.
I thought the answer may depend on the experimental result, especiallyfrom the view of "quality/speed", as "quality" is beyond our control (while the speed's 420p is obviously faster than 422 as less data processing). On thing i maymentionedthat IPP functionsare optimized based oncpu instruction (likeSIMD (SSE) Instructions) on the purpose of speed. It willwork with generalc code anddon'tmodify thedeinterlace algorithm itself, sodon't change the quality itself.

Just commentsthecall sequence, it looks like there aretoo muchformat convertion,whichseems redundant, in order to implement the deinterlaceFilterCAVT.Do you have chancewrite the CAVT algorithm?May be a direct C codeis faster than many formart convertion + the IPPfunction callas your clip is UYVY format.

c) Yes, in general, we suppose deinterlace first, then resize in sample code.

Regards,
Ying

[BatterseaSteve]

Hi Ying
Thanks for that.
I went down the route of deinterlacing and then resizing, however I realised when everything was working that what I had is not what I need. The problem with deinterlace on ity's own is that it converts 50i into 25p. So although I can resize an interlaced frame I get a progressive frame from an interlaced frame Doh!.......
What I really need is field interpolated de-interlacing, which I an guessing is not achievable even with the Motion Adaptive de-interlacer. i.e 50i to 50p

So my next question is, how can I resize 420p/422p/411p without de-interlacing?
Do I strip out fields - resize and then re-interlace?
Is ippiResizeYUV422_8u_C2R field aware?
Any other ideas?
Cheers
Steve

[BatterseaSteve]

I Guess to answer at least part on my own question - Motion Adaptive will do field interpolation - at least according to thread
So one possible route would be to do field interpolated de-interlacing (50i -> 50p), resizing and then restitching
http://software.intel.com/en-us/forums/showthread.php?t=78614&o=a&s=lr

Looking over at doom9 I spotted

http://forum.doom9.org/showthread.php?t=139102

Which seems to indicate resizing can be done by separating fields - resizing and then reweaving.
I'll give it a go and se what it looks like - if anyone has any other suggestions I would be keen to hear...
(It would seem to me that an interlace aware resize function would be hugely useful)

[BatterseaSteve]

OK
So first problem

I thought I had a great idea that wRould allow me to deinterlace, resize and re-interlace in one go
Use ippiResizeSqrPixel_8u_C1 with src/ds size/rect/step set to resize first top then bottom field lines.
Hah - I should be so lucky.

I have an interlaced src buffer that is 1472x1080
(this is a padded Y plane from YUV422p 1440 DV video)
I want to resize this to an interlaced Y plane of 720x576

so, given a pSrc = src and pDst = dst

I call ippiResizeSqrPixel_8u_C1 for the top(even) lines using
pSrc = src
srcSize = {1472,1080}
srcStep = 2*1472
srcRoi = {0,0,1440,1079}
pDst = dst
dstStep = 2*720
dstRoi = {0,0,720,575}

I call ippiResizeSqrPixel_8u_C1 for the bottom(odd) lines using
pSrc = src+1472
srcSize = {1472,1080}
srcStep = 2*1472
srcRoi = {0,1,1440,1080}
pDst=dst+720
dstStep = 2*720
dstRoi = {0,1,720,576}

pDst is the same in both cases - the top lines are written into pDst as expected but so are the bottom lines.
The bottom lines just overwrite the top lines when the second call to Resize is called.

Am I missing something - is this possible - have I goofed - will this even work?
Anyone - or am I just talking to the ether?
Steve