Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#6391 closed enhancement (fixed)

New deinterlacer for perfect image quality when using an interlaced display mode that matches the source

Reported by: mythtv@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no

Description

This patch provides a deinterlacer for perfect image quality and motion smoothness when using an interlaced display mode that exactly matches the video source. The deinterlacer comes up in the menus as "Interlaced x2". It is also known as field order.

Preconditions of use

You need a graphics chip that can output interlaced display modes correctly.

The display mode must be interlaced exactly matching the video source.

No scaling can be used: don't use scaling to reduce overscan.

Video playback must be full speed, not sped up or slowed down.

The deinterlacer is a doublerate one, so you may need the patch from Ticket #2903 before MythTv? will allow you to use it.

For best quality, make sure TvDeflicker? is turned off if your card supports it.

Test result

I've tested this only with 576i content into a CRT PAL TV, but the same should apply for any interlaced content and matching interlaced display mode. It should be good for displaying 1080i, provided the graphics card can output a 1080i signal. The test that most obviously showed up the differences between deinterlacers were rolling credits at the end of a program:

No deinterlacer: results depend on synchronisation. Sometimes perfect sometimes jumping forward 3, back 1, forward 3, back 1.

Kernel: slight loss of sharpness. Motion jerky as though halved frame rate.

Linear blend: even more loss of sharpness.

Yadif x2: really very good. Depends on sync as with no deinterlacer, sometimes perfect, sometimes rolling text shows artifacts (e.g., slightly malformed letters, disappearing dots on occurences of the letter i).

New "Interlaced x2" deinterlacer: perfectly sharp, very smooth motion - as with no deinterlacer - but no loss of sync.

Explanation

Some TVs can do a better job of displaying an interlaced video than the currently available deinterlacers. Particularly, a CRT TV's purpose in life is to display interlaced video, and for most CRT TVs, there is no choice but to drive them with an interlaced video mode. Even with modern flat screen TVs, some have extremely good SD support, and the best quality for SD video is when driving them with an SD display mode.

When the display mode is chosen to match the source, it is important to avoid any processing of the image. Any use of scaling, normal deinterlacing, tvdeflicker will lose quality: the best results are achieved if the interlaced video frames are sent to the TV unaltered.

Getting the interlaced frames to the TV properly synchronised is difficult in MythTv? (and probably Linux in gereral) because graphics cards when outputting interlaced display modes tend to generate two vsyncs per frame. The new deinterlacer generates frames between every consecutive pair in such a way that synchronisation doesn't matter. A sequence of field pairs such as:

12 34 56 78

is processed to produce

12 32 34 54 56 76 78

The TV may take the top field from the first and the bottom from the second and so on to produce

1 2 3 4 5 6 7

or it may take the bottom field from the first and the top from the second and so on to produce

2 3 4 5 6 7 8

Either way the fields are spatially correct and temporally correctly ordered.

Attachments (9)

mythtv-0.21-field-order.patch (10.0 KB) - added by mythtv@… 11 years ago.
Patch that adds the new deinterlacer
mythtv-0.21-field-order.2.patch (9.9 KB) - added by mythtv@… 11 years ago.
Patch against vanilla 2.1 fixes (previous patch was against 2.1 fixes plus vdpau patch
mythtv-0.21-field-order.3.patch (10.2 KB) - added by mythtv@… 11 years ago.
Mark Kendall's improved patch backported to fixes branch plus vdpau and opengl
mythtv-0.21-field-order.4.patch (10.2 KB) - added by mythtv@… 11 years ago.
Mark Kendall's improved patch backported to vanilla 2.1 fixes branch
mythtv-0.21-field-order.5.patch (10.2 KB) - added by mythtv@… 11 years ago.
Correction: Mark Kendall's improved patch backported to fixes branch plus vdpau and opengl
mythtv-0.21-field-order.6.patch (10.2 KB) - added by mythtv@… 11 years ago.
Correction: Mark Kendall's improved patch backported to vanilla 2.1 fixes branch
mythtv-0.21-field-order-no-flicker.patch (9.9 KB) - added by mythtv@… 11 years ago.
Original patch corrected for OSD flicker and bottom field first (vanilla 2.1 fixes)
mythtv-0.21-field-order.7.patch (10.2 KB) - added by Tom Dexter <digitalaudiorock@…> 11 years ago.
Mark Kendall's improved patch backported to fixes branch plus vdpau and opengl, with non-interlaced fix
mythtv-0.21-field-order.8.patch (10.2 KB) - added by Tom Dexter <digitalaudiorock@…> 11 years ago.
Mark Kendall's improved patch backported to vanilla 2.1 fixes branch, with non-interlaced fix

Download all attachments as: .zip

Change History (20)

Changed 11 years ago by mythtv@…

Patch that adds the new deinterlacer

comment:1 Changed 11 years ago by mythtv@…

Changed 11 years ago by mythtv@…

Patch against vanilla 2.1 fixes (previous patch was against 2.1 fixes plus vdpau patch

comment:2 Changed 11 years ago by markk

Resolution: fixed
Status: newclosed

(In [20299]) Add a CPU based 'interlaced' filter that should synchronise interlaced material to an interlaced display. Original patch from Paul Gardiner with modifications for:-

  • fix for bottom field first streams.
  • fix flickering osd.
  • reduced cpu consumption by avoiding redundant copies.

While this is the software based version of the OpenGL interlaced 'deinterlacer', the algorithm is slightly different (the OpenGL version just displays one scaled field at a time) and I may align the 2 at a later date if I get the chance to do more testing on different displays. This version tested with 1080i50/60, 576i and 480i bottom field first all over DVI/HDMI (i.e. no VGA to scart). Further potential CPU reductions with the use of some MMX optimisations, although I don't see much point in making this multi-threaded.

Closes #6391

comment:3 Changed 11 years ago by mythtv@…

Thanks for getting this in. Just some quick questions:

1) You mention aligning the opengl and software versions. Which would change? I ask because the OpenGL one in its current form does a completely different job. It would be no good for my set up. Its purpose doesn't seem to be to sychronise interlaces, but to truly deinterlace.

2) You mention testing 576i and 480i via HDMI. Is that with 576i and 480i display modes? Matched source and display mode is the only case this deinterlacer works correctly. I ask because someone commented in myth-users that few TVs will accept SD modes via HDMI. It would be very interesting if that's not the case.

3) I thought I'd accounted for bottom field first. Any idea what I did wrong?

4) I made a similar change to avoid flickering OSD, but it didn't work (for the second occurence of the frame newframe == lastframe, I copied both field rather than just the second field). I also noticed that yadif suffers from flickering OSD. My changes were on fixes rather than trunk. Is that significant?

Changed 11 years ago by mythtv@…

Mark Kendall's improved patch backported to fixes branch plus vdpau and opengl

comment:4 Changed 11 years ago by jyavenard@…

The 20299 changeset will apply gracefully on 0.21-fixes ; however you need to replace in filters/fieldorder/filter_fieldorder.c, line 227: ConstFilterInfo? filter_table[] = with FilterInfo? filter_table[] =

Changed 11 years ago by mythtv@…

Mark Kendall's improved patch backported to vanilla 2.1 fixes branch

comment:5 Changed 11 years ago by jyavenard@…

Have you actually tried compiling your 0.21 patches ? They won't compile due to the use of: ConstFilterInfo?

Changed 11 years ago by mythtv@…

Correction: Mark Kendall's improved patch backported to fixes branch plus vdpau and opengl

Changed 11 years ago by mythtv@…

Correction: Mark Kendall's improved patch backported to vanilla 2.1 fixes branch

comment:6 in reply to:  4 Changed 11 years ago by mythtv@…

Replying to jyavenard@gmail.com:

The 20299 changeset will apply gracefully on 0.21-fixes ; however you need to replace in filters/fieldorder/filter_fieldorder.c, line 227: ConstFilterInfo? filter_table[] = with FilterInfo? filter_table[] =

There's a second change necessary to make it work. On fixes, FieldorderDeint? does not receive the third parameter "field", so you need to calculate the value. Luckily "dirty" has the required value, so you can pass that instead, thus having "dirty" appear twice amongst the arguments to filter_func.

Changed 11 years ago by mythtv@…

Original patch corrected for OSD flicker and bottom field first (vanilla 2.1 fixes)

comment:7 Changed 11 years ago by Tom Dexter <digitalaudiorock@…>

As discussed in this thread:

http://www.gossamer-threads.com/lists/mythtv/users/378711#378711

I've been testing the vanilla 0.21-fixes version of this patch with 1080i. I was having some very strange motion problems with that version on NBC shows where they mix progressive frames in the 1080i content. I didn't have these problems with the original patch that was inadvertently doing nothing with bottom field first frames. I believe my problems were being caused by progressive frames being treated as bottom field first due to the top_field_first defaulting to zero.

I'm not sure this fix is valid in all cases (a lot of this video stuff is a bit out of my league), but it's worked great in my case: In the call to filter_func within FieldorderDeint?, I changed the tff parameter to default to 1 in the case of non-interlaced frames. In the 0.21-fixes version it looks like this:

    filter_func(
        filter, frame->buf, frame->offsets, frame->pitches,
        frame->width, frame->height, dirty, frame->top_field_first | !frame->interlaced_frame,
        dirty);

Again, I'm not sure if there's anything wrong with that. When no progressive frames are mixed with the interlaced content however, it should have no affect.

I'm going to continue testing with that but for so far it's worked perfectly.

comment:8 Changed 11 years ago by mythtv@…

Brilliant Tom. The same idea occurred to me, that progressive frames may be being passed in with tff being 0, but I never thought to use the interlaced_frame member to put it right.

Which patch did you base your version on? If it's mythtv-0.21-field-order.6.patch then it's just a slight change from what is on trunk, and I can't see there'd be any problem committing it. Might be worth attaching your version to this ticket. Also might be worth opening a new ticket with just the "!frame->interlaced_frame" change, which Mark could maybe commit to trunk. Or perhaps that shoulf be rolled into the other change you made for handling the interlaced/progessive mixture.

In any case, I'm very pleased you've solved this.

comment:9 in reply to:  7 Changed 11 years ago by mythtv@…

One more thought. It just struck me that it might be better to combine !frame->interlaced_frame with the parity flag, rather than with tff, as below

    filter_func(
        filter, frame->buf, frame->offsets, frame->pitches,
        frame->width, frame->height, dirty | !frame->interlaced_frame, frame->top_field_first,
        dirty);

That, in a way, turns off the algorithm for progressive frames, making both the constructed frames exact copies of the original. For the mixture of tff interlaced frames and progressive frames that you are seeing, results should be the same, but this version should also work for a mixture of bff interlaced frames and progressive frames.

comment:10 Changed 11 years ago by Tom Dexter <digitalaudiorock@…>

As per Paul's suggestion I've tested the change to force the 'parity' parameter of the filter_func call within FieldorderDeint? to one for non-interlaced frames, thus leaving them unaltered. It appears to be working great. I'm uploading two new versions of the 0.21-fixes back ported patch (one for vdpau and opengl patch users and one for vanilla 0.21-fixes) with this change.

Note that this change in trunk would be:

    filter_func(
        filter, frame->buf, frame->offsets, frame->pitches,
        frame->width, frame->height, field | !frame->interlaced_frame, frame->top_field_first,
        dirty);

Changed 11 years ago by Tom Dexter <digitalaudiorock@…>

Mark Kendall's improved patch backported to fixes branch plus vdpau and opengl, with non-interlaced fix

Changed 11 years ago by Tom Dexter <digitalaudiorock@…>

Mark Kendall's improved patch backported to vanilla 2.1 fixes branch, with non-interlaced fix

comment:11 Changed 10 years ago by Janne Grunau

(In [24331]) filter: remove left code from a memcpy call from the initial fieldorder filter commit [20299]

found by clang, Refs #6391

Note: See TracTickets for help on using tickets.