[mythtv-users] What Resolution Are You Using?

[Bruce Markey]

Dan Hopper wrote:
> Bruce Markey <bjm at lvcm.com> remarked:
> 
>>jasonmiller wrote:
>>
>>>Technically NTSC is 320x240, PAL is 320x288.
>>
>>Well, technically NTSC is analog. There are two interlaced
>>fields of about 240 scan lines for a total of about 480
>>sacn lines that carry picture information. There are 525
>>total line including sync and such. Each scan line has analog
> 
> 
> So, I note from the discussion that we're de-interlacing the video
> on the way in,

Kind of but it depends on what you mean by de-interlacing.
Both fields are written into a framebuffer with no
deinterlace algorithms applied. There is code to fix
interlace problems on playback (there was a patch for
record deinterlace recently but like some other recent
check-ins, this is a virtual easter egg. You can hit "x"
during LiveTV but I don't see the difference, it doesn't
seem to be stored anywhere and I don't see how it could
be applied to recordings. The author may have fun playing
with this but I don't see how users will find it useful).

 > ...storing it progressive on disk, and then of course
> interlacing it for going out to the TV.  Would it not be better to
> store it on disk as interlaced frames?  I would think that without
> the filters required it the video quality would be improved for more
> than one reason.

I've thought the same thing that maybe 59.97 fps of 240
scan lines (compressing by comparing against two frames
earlier for the last frame of the same field) might be a
truer reproduction of the original TV signal.

Two problems. First, MythTV can be shown on a progressive
scan monitor with refresh rates other than 60 and even if
it is a TV, you might use 800x600 (or 1024x768) or have an
overscan offset or record with a height other than 480, etc.
All of these will cause the interlace fields to not line up.
Commercial DVRs have the advantage of knowing that they will
only be drawing a true NTSC raster.

Second, AFAIK, there is no access to the vertical refresh
timing of the graphics card so you can't know when to update
the framebuffer to be sure it will be drawn on the next pass.
If there is access to this information, I'd really like to
fix the playback jitter due to framebuffer updates not
accurately spaced with vertical refresh. This is what 'jitter
reduction' tries to mitigate but it can't truly be fixed
without knowing when the card is going to draw the next frame.


--  bjm