[vlc-devel] [PATCH] Phosphor deinterlacer, reworked += 5

[Juha Jeronen]

On 03/30/2011 12:13 AM, Jean-Baptiste Kempf wrote:
> On Wed, Mar 30, 2011 at 12:07:16AM +0300, Juha Jeronen wrote :
>> Actually, either way is fine with me. The file is getting a bit long,
>> and it sorely needs the cleanup.
>>
>> Which one would you prefer?
> I, for one, believe that it would be cleaner to split before, so the
> ivtc patch is more easy to follow/review.
>
> However, if that make ANY increase in your worktime, this is not the
> good the solution.
>
> So, you should choose what takes the less of your time first, and see
> other parameters afterward.

Ok. Thanks for the input :)

I think it'll be slightly faster for me to update IVTC first, although
that too needs a major refactoring before the code is in any shape
suitable for proposing a merge.

But as a bonus, this way I can be sure when I split the file that I'm
doing it in a way that's compatible with IVTC ;)

So, IVTC first.


Note to self about refactoring IVTC (updated TODO list concerning this
item only):

- Base version of IVTC: "patch #7" i.e.
http://mailman.videolan.org/pipermail/vlc-devel/2011-February/078833.html
[See note at bottom of this message]

- The experimental hack (cartoon outline detection) in
CalculateInterlaceScore() is not needed. A recent clean base version of
CalculateInterlaceScore() is in Phosphate/IVTC2x,
http://mailman.videolan.org/pipermail/vlc-devel/2011-February/079048.html
[See note at bottom of this message]

- Update CalculateInterlaceScore() to use separate top/bottom field
input frames so that a single copy or compose per output frame is enough.

- Use the already merged, improved ComposeFrame() (whee, at least
something to leave out from the huge patch ;) )

- Use the existing, general input frame history mechanism.

- Use CUSTOM_PTS.

- Clean clean clean. After roughly two months of experimental hacks,
RenderIVTC() works much more accurately than the original, but the code
is not very pleasant to look at. There's a lot of stuff that should be
in separate functions in any sane implementation. This will also make
the filter's workflow easier to read.

- Cadence detection algorithms should each one be in a separate
function. They should produce a raw cadence position, and a reliability
flag. They should have a precedence, in case more than one detector
thinks it has a reliable result. To keep this general, pre- and
post-detectors should both be allowed. (Pre: the original interlace
scores ranking and Vektor, post: duplicate output detector.)

- Keep the three working cadence detectors, and remove the one that
sometimes locks on incorrectly (interlace scores based vektorlike
experiment). Or keep just the two working pre-detectors for now, and
leave the duplicate output detector for later.

That should be all. Doing this should produce a version of IVTC that is
1) compatible with the current codebase, 2) reasonably clean, and 3)
functionally satisfactory for "production use" (renders most anime
correctly and glitches only rarely).

Most of the MMX code was already tuned by Laurent during the early IVTC
reviews, so I'll use those parts as-is (or with minimal changes where
absolutely needed).

I'll get to work on this and post the new version when it's complete.


(About the duplicate output detector - it's not strictly necessary. It
was mainly intended to catch input which was originally telecined, but
which has been then broken by hard-deinterlacing. This would trigger a
special IVTC mode designed for such input (drop duplicates, adjust PTS,
but never compose - looking at it now, it seems my posted version has a
silly bug in that it sometimes composes when it is supposed to be doing
this...). This bonus feature can wait for a future version, since it
needs some more work to make it handle the MoonPhase OP - my prime
testing target for this case - correctly.

This also needs some more R&D to work reliably when there is no motion
in every frame. It's rather easy to make a filter that targets
incorrectly deinterlaced telecined streams only. The challenge is in
making it autodetect correctly alongside normal IVTC. (In practice, this
is needed. With the exception of the OP, the telecine in MoonPhase is
correct...) Maybe detecting long runs of suspiciously low interlace
scores to figure out whether it's running in a stream which has been
hard-deinterlaced with a cheap algorithm... but I'm not sure if that can
work reliably. Probably not.)


Finally, here's the "note at bottom": how to generate complete copies of
deinterlace.c containing the "patch #7" IVTC, and Phosphate/IVTC2x. This
is here just so that it gets stored into the list archive, in case
anyone wants to look at these versions at some point in the future.

"Patch #7" IVTC filter:

Patches #1-#7 are needed. Get #6 and #7 from
http://mailman.videolan.org/pipermail/vlc-devel/2011-February/078833.html
Get #5 from
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078774.html
Get #1-#4 from (note the order of the posts)
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078588.html
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078589.html
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078591.html
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078590.html

Download all 7 patches, and apply them (#1-#4 first, then #5, #6, #7) on
top of VLC commit [3f50c72acbf4fe8ca4f9631a3bff596cba2d3a05]. The code
will be in modules/video_filter/deinterlace.c.

Phosphate/IVTC2x:

Get the old Phosphor patch from
http://mailman.videolan.org/pipermail/vlc-devel/2011-February/079047.html
and Phosphate/IVTC2x from
http://mailman.videolan.org/pipermail/vlc-devel/2011-February/079048.html

Apply them, in the above order, on top of VLC commit
[8f4d34b49c719581622dbca708f92ea81221156d]. The code will be in
modules/video_filter/deinterlace.c.


 -J