[mythtv-users] Viktor's Bob deint patch for interlaced modelines

Steve Smith st3v3.sm1th at gmail.com
Mon Jan 28 14:19:50 UTC 2008


On 28/01/2008, Mark Kendall <mark.kendall at gmail.com> wrote:
>
> On 28/01/2008, Steve Smith <st3v3.sm1th at gmail.com> wrote:
>
> > I suspect when the FIELDS are shown out of order. But on my system it
> just
> > works, so presumeably the BOB code is able to sync to FRAME (with my
> > driver/card/myth/X combination) but the normal (non filtered) code
> isn't!
>
> I'm starting to wonder whether it has something to do with the XV/XvMC
> code and the nvidia driver(don't know about ati etc) somehow knowing
> which is the first field of a frame. Alternatively it could just be
> that presenting one field at a time allows the tv to figure it out -
> though looking at the pal specs, there is some specific signalling
> that tells the tv which is the first field of the frame.
>
> > >So the question is, why can't you use bobdeint with your modeline? I'm
> > >guessing (because I've seen the same problem) that X is reporting a
> > >slightly erroneous refresh rate (i.e. slightly too low) and hence bob
> >  >gets rejected
> > Well in 0.20  bobdeint rejects any mode where the FRAME rate is less
> than 2x
> > the signal framerate i.e. 50hz in PAL land.
> > I suppose it's a question of semantics! The FRAME rate is still 25 but
> you
> > can change the picture at 50hz. The 0.20 doesn't
> > take this into account (that it can display the diff fields at 50hz on
> an
> > interlaced display). Viktor's patc just fools the code into thinking the
> > FRAME rate of the display is twice what it is, the correct method is
> simply
> > to fix bobdeint itself so it realises the difference.
>
> The code will/should only reject display modes where it believes the
> display refresh rate (50Hz ideally) cannot support doubling the source
> frame rate ie. from 25Hz to 50Hz.
>
> What I see on at least one frontend (using both 720p and 1080i
> modelines) is that xorg is actually returning a refresh rate of
> something like 49.95Hz and hence bob (or any other framerate doubling
> deinterlacer) is rejected.
>
> This doesn't appear to be a mythtv issue (admittedly, it would be
> better if the code gave a small amount of leeway) and the way I have
> worked around it is to fire up xvidtune and tweak the modeline
> slightly to increase the refresh rate.
>
> You might just find this works for you without hacking mythtv.
>
> > >A slightly cleaner way to do this would be to adapt a 2x onefield
> > >filter - which would eliminate any osd flicker etc and might just
> > >improve picture quality as there would be no bob adjustment or
> >  >scaling.
> >
> > Actually yes 2x onefield (NOT the SAME field!) is exactly what's needed
> with
> > an interlaced display.
> > Basically it goes:
> >
> > <FRAME SYNC> 1st FIELD --->  Scale as appropriate ----> Display
> > <field sync>       2nd FIELD --> Scale as appropriate ---> Display.
> > <FRAME SYNC> 1st FIELD --->  Scale as appropriate ----> Display
> > <field sync>       2nd FIELD --> Scale as appropriate ---> Display.
> > etc. etc.
> >
> > Where "Scale as appropriate" means doing the necessary to display 16:9
> on an
> > 4:3 etc.
> >
> > So I am talking about 2xOnefield(with different fields) or BOBdeint
> here? I
> > don't know. But that's the effect I'm after.
> > (Maybe it should be called 2xBOTHfields!?!? But isn't that the same as
> bob?)
>
> Well, either my code is broken (not unlikely) or there is more to it
> than that because bob seems to be working very well (apart from the
> osd flicker) whereas 2x Onefield works intermittently.
>
> Need to clear head!
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

>I'm starting to wonder whether it has something to do with the XV/XvMC
>code and the nvidia driver(don't know about ati etc) somehow knowing
>which is the first field of a frame. Alternatively it could just be
>that presenting one field at a time allows the tv to figure it out -
>though looking at the pal specs, there is some specific signalling
>that tells the tv which is the first field of the frame.

Actually the first field 2nd field thing is all done using timing (both for
NTSC and PAL).
The first thing to realise is that the scanlines on a CRT TV are slightly
sloped downwards so that the left end of the line is 2 pixels higher than
the right.
The first field is sent with its 312 lines, and then a HALF line is sent.
Then Vsync is trigged to
get the electron beam up to the top of the screen and the next FIELD is sent
starting at the begginning of the
next line.
It's the HALF line at the end of the first field which together with the
slight slope of the lines themselves which
causes the electron beam to end up halfway between the scan lines of the
previous frame, so that the 2nd field lines are interlaced between the first
field's lines.
Clever eh?
What this means is that the video card decides which is the first field and
which is the 2nd. The TV doesn't really have any concept of it (for a normal
CRT TV, LCD's have to figure it out from that half line I expect!)


So for every FRAME with an interlaced signal you can potentially have two
Vertical Syncs what I refer to as a FRAME Sync and a FIELD sync (which is
the vertical sync after the half line).
It's very difficult from the literature available to see if the Nvidia
drivers send:
    i) Only a FRAME sync.
   ii) FIELD syncs (with no indication of Frames)
   iii) FIELD and FRAME syncs with indication of which is a frame.

To get interlaced output to work properly we need either  iii) or i)  (I
assume we can time the field sync in between frames realiably in software).

So what's wierd is that in mine (and other) setups, bob deint can figure out
the frames. Whilst when no deinterlacer is selected it can't.
Where's the bug? Who knows? Myth, X, nvidia or somewhere else?
In either case you do actually need some form of bob like action in order to
do scaling correctly.



>The code will/should only reject display modes where it believes the
>display refresh rate (50Hz ideally) cannot support doubling the source
>frame rate ie. from 25Hz to 50Hz.

This is where I think the misunderstanding comes in, because (X reporting
the refresh rate wrong aside) I believe that
for an ***INTERLACED*** display mode (not progressive display mode)  ****you
only need the refresh rate to be 25hz.****
WHY?

Refresh = FRAME rate = 25hz.
Interlaced  THEReFORE  = 2x Fields per frame =  50hz.    Note as I say above
there are now 2x potential vertical syncs per frame.
So on the first VSYNC (I call the frame sync) you paint the top fields.
On the 2nd VSYNC you paint the bottom fields.


i.e. when the display mode is INTERLACED you can repaint the picture 2x per
frame. This allows you to treat each frame
as two consecutive (in time) pictures, scale them appropriately and display
one at a time always ensuring the TOP field aligns with the FRAME sync. i.e.
Interlaced display mode is a special case!

X reports the Refresh/Frame rate NOT the field rate.

I seem to be discussing myself into circles.... ;-)

RE: OSD flicker, would that mean that the OSD is inserted into the final
picture in only one field. BTW I have no OSD flicker with my bob deint ;-)!

Cheers

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080128/aa9f2109/attachment.htm 


More information about the mythtv-users mailing list