Feature #2764

Add option for using advanced deinterlace (RPi)

Added by Dean Kasabow over 4 years ago. Updated over 4 years ago.

Status:FixedStart date:07/25/2015
Priority:NormalDue date:
Assignee:Andreas Smas% Done:

0%

Category:Video playback
Target version:5.0

Description

It will be nice to have an option to choose deinterlacer mode for Raspberry Pi2. The "fast" mode produces flickering and it is really annoying when watching.

Using "advanced" mode produces a stable picture (far from the best that can be achieved with blend/bob, but still better than the "fast" mode). For my test I changed the mode and parameters.

glw_video_rpi.c:

OMX_CONFIG_IMAGEFILTERPARAMSTYPE image_filter;
OMX_INIT_STRUCTURE(image_filter);
image_filter.nPortIndex = 191;
image_filter.nNumParams = 3;
image_filter.nParams[0] = 3;
image_filter.nParams[1] = 0;
image_filter.nParams[2] = 1; # 0:full framerate, 1:half framerate - not sure how it works (almost no difference) but probably depends on double-buffering
// if(1)
// image_filter.eImageFilter = OMX_ImageFilterDeInterlaceFast;
// else
image_filter.eImageFilter = OMX_ImageFilterDeInterlaceAdvanced;

half2.jpg - ONE FIELD ONLY modes (77.8 KB) Dean Kasabow, 07/26/2015 06:00 PM

full2.jpg - SOLID modes (112 KB) Dean Kasabow, 07/26/2015 06:00 PM

History

#1 Updated by Andreas Smas over 4 years ago

  • Status changed from New to Accepted

Ok. Make total sense. I didn't add support for the advanced deinterlacer initially because I didn't want to add more settings (I hate settings).

But if people find it useful I'll definitely consider it.

#2 Updated by Dean Kasabow over 4 years ago

I was playing with the deinterlace stuff for the last few days... tested different sources and filters.

It turns out that this combination provides THE BEST deinterlaced image:

OMX_CONFIG_IMAGEFILTERPARAMSTYPE image_filter;
OMX_INIT_STRUCTURE(image_filter);
image_filter.nPortIndex = 191;
image_filter.nNumParams = 0;
image_filter.eImageFilter = OMX_ImageFilterDeInterlaceAdvanced;

In OMX_IVCommon.h there is no mention of parameters for the deinterlace filters, so I used "0" as number of parameters and the image looks MUCH better than with the use of any parameters.

I believe there is no need for any options/settings, but just use the Advanced mode since it produces the best picture (imho).

#3 Updated by Dean Kasabow over 4 years ago

I meant to say in OMX_Broadcom.h.... of course it depends on the firmware that you used for STOS and if it supports the extended parameters for the advanced filter.

#4 Updated by Andreas Smas over 4 years ago

Dean Kasabow wrote:

I was playing with the deinterlace stuff for the last few days... tested different sources and filters.

It turns out that this combination provides THE BEST deinterlaced image:

OMX_CONFIG_IMAGEFILTERPARAMSTYPE image_filter;
OMX_INIT_STRUCTURE(image_filter);
image_filter.nPortIndex = 191;
image_filter.nNumParams = 0;
image_filter.eImageFilter = OMX_ImageFilterDeInterlaceAdvanced;

In OMX_IVCommon.h there is no mention of parameters for the deinterlace filters, so I used "0" as number of parameters and the image looks MUCH better than with the use of any parameters.

I believe there is no need for any options/settings, but just use the Advanced mode since it produces the best picture (imho).

Any clue if it performs OK even on RPI-1 ?

#5 Updated by Dean Kasabow over 4 years ago

I'll grab a Pi-1 tomorrow and will try to test (although without mpeg2 license for it I'll just test if the filter works on other formats and doesn't introduces slowdown).

I created a recording from live mpeg2 [email protected] (top-field first) video (from SkySportsF1) and I can see difference between different options - I observed a little red F1 logo (depending on the setting it: flickers, misses the odd/even lines, looks solid):

I continues my tests and it seems that changing parameters to:

image_filter.nNumParams = 3;

and setting three parameters produce different results {P1, P2, P3}:

0 0 0 - flicker
0 0 1 - one field only
0 1 1 - one field only
1 0 0 - flicker
1 1 1 - one field only

0 1 0 - solid
1 0 1 - solid
1 1 0 - solid

In the attached images you can see the difference. FLICKER is somewhat switching between SOLID/ONE FIELD.

So for me it seems that 1-0-1 produces best results. Sadly I can't find any documentation on how the parameters for the Advanced Deinterlace Filter work... It depends on the firmware... May be the settings are flags or microseconds or something else...

It looks to me that for top-field-first 576i this is best:

image_filter.nNumParams = 3;
image_filter.nParams[0] = 1;
image_filter.nParams[1] = 0;
image_filter.nParams[2] = 1;

#6 Updated by Dean Kasabow over 4 years ago

Andreas Öman wrote:

Any clue if it performs OK even on RPI-1 ?

Yes, it works on RPI-1. I just tested it with 720x400 interlaced MPEG-4 and the Advanced deinterlace filter produces much better picture - no flickering. With the "fastdeinterlace" there is flickering. More important, the image filter doesn't introduce any slowdowns and the playback is perfect.

I even permanently enabled the filter (so it was applied all the time to all content) and played 1920x1080 - again everything is fine on the RPi-1.

#7 Updated by Andreas Smas over 4 years ago

  • Target version set to 5.0

#8 Updated by Leonid Protasov over 4 years ago

  • Subject changed from RPi2 / Option for using advanced deinterlace OMX feature to Add option for using advanced deinterlace (RPi)

Just add that into videoplayback page menu.

#9 Updated by Dean Kasabow over 4 years ago

Well, it seems that the Advanced deinterlace requires some extra buffers (at least 3 frames needed to construct a proper deinterlaced frame).

My latest test was with [email protected] and finally it plays really smooth. Other players seem to use the same approach. These are the changes in glw_video_rpi.c:

@
if(fi->fi_interlaced) {

if(rvd->rvd_imgfx == NULL) {
rvd->rvd_imgfx = omx_component_create("OMX.broadcom.image_fx",
&rvd->rvd_mutex, NULL);
rvd->rvd_imgfx->oc_opaque = rvd;
// add extra buffers for Advanced Deinterlace
OMX_PARAM_U32TYPE extra_buffers;
OMX_INIT_STRUCTURE(extra_buffers);
extra_buffers.nU32 = 3;
omxchk(OMX_SetParameter(rvd->rvd_imgfx->oc_handle, OMX_IndexParamBrcmExtraBuffers, &extra_buffers));
OMX_CONFIG_IMAGEFILTERPARAMSTYPE image_filter;
OMX_INIT_STRUCTURE(image_filter);
image_filter.nPortIndex = 191;
image_filter.nNumParams = 1;
image_filter.nParams[0] = 3;
image_filter.eImageFilter = OMX_ImageFilterDeInterlaceAdvanced;
omxchk(OMX_SetConfig(rvd->rvd_imgfx->oc_handle, OMX_IndexConfigCommonImageFilterParameters, &image_filter));
}
@

#10 Updated by Andreas Smas over 4 years ago

Leonid Protasov wrote:

Just add that into videoplayback page menu.

Settings should be avoided unless it's very much needed IMHO.

#11 Updated by Andreas Smas over 4 years ago

  • Status changed from Accepted to Fixed

Committed in 4.9.75

#12 Updated by Leonid Protasov over 4 years ago

Andreas Öman wrote:

Committed in 4.9.75

No fix for 4.10?

#13 Updated by Andreas Smas over 4 years ago

Andreas Öman wrote:

Committed in 4.9.75

For the record i mean 4.99.75 :-)

And we'll back port it to 4.10 if it's good now. Perhaps Dean can verify as well?

#14 Updated by Dean Kasabow over 4 years ago

Andreas Öman wrote:

Andreas Öman wrote:

Committed in 4.9.75

For the record i mean 4.99.75 :-)

And we'll back port it to 4.10 if it's good now. Perhaps Dean can verify as well?

Yes, everything is good. Yesterday I git-cloned and compiled 4.99.78 from scratch and the deinterlace works as expected.

My only concern is the meaning of the parameter to the filter. I read somewhere that the value could be 0, 3 or 4 (for frame/TFF/BFF), but I can't be sure.

#15 Updated by Andreas Smas over 4 years ago

I'll try to see if i can find some BFF content somewhere in my collection.

#16 Updated by Dean Kasabow over 4 years ago

Andreas Öman wrote:

I'll try to see if i can find some BFF content somewhere in my collection.

I suspect that the value corresponds to the eMode value, returned by the check:

OMX_CONFIG_INTERLACETYPE interlace;
OMX_INIT_STRUCTURE(interlace);
interlace.nPortIndex = 131;
if(OMX_GetConfig(oc->oc_handle, OMX_IndexConfigCommonInterlace,
&interlace) == OMX_ErrorNone) {
switch(interlace.eMode)

It will make sense, because the returned value is 0..5 for the following scenarios:

// OMX_InterlaceProgressive, /**< The data is not interlaced, it is progressive scan /
// OMX_InterlaceFieldSingleUpperFirst, /
*< The data is interlaced, fields sent
// separately in temporal order, with upper field first /
// OMX_InterlaceFieldSingleLowerFirst, /
*< The data is interlaced, fields sent
// separately in temporal order, with lower field first /
// OMX_InterlaceFieldsInterleavedUpperFirst, /
*< The data is interlaced, two fields sent together line
// interleaved, with the upper field temporally earlier /
// OMX_InterlaceFieldsInterleavedLowerFirst, /
*< The data is interlaced, two fields sent together line
// interleaved, with the lower field temporally earlier /
// OMX_InterlaceMixed, /
*< The stream may contain a mixture of progressive

#17 Updated by Dean Kasabow over 4 years ago

This is an old post from 2013 where the feature is introduced to the firmware:
https://github.com/raspberrypi/firmware/issues/213

@popcornmix commented on 18 Oct 2013

Firmware pushed. Please test.
You should be able to:
OMX_SetConfig(sys->omx_handle, OMX_IndexConfigCommonImageFilterParameters, &config);
with 0/3/4 to set the frame/tff/bff flags for the next source frame submitted.
@

Also available in: Atom PDF