[mythtv-commits] Ticket #1087: Deinterlace doesn't work (latest svn)

MythTV mythtv at cvs.mythtv.org
Wed Jul 18 16:37:03 UTC 2007

#1087: Deinterlace doesn't work (latest svn)
 Reporter:  james.muscat at sjc.ox.ac.uk  |        Owner:  ijr     
     Type:  defect                     |       Status:  reopened
 Priority:  minor                      |    Milestone:          
Component:  mythtv                     |      Version:          
 Severity:  medium                     |   Resolution:          
  Mlocked:  0                          |  
Changes (by iva2k at yahoo.com):

  * status:  closed => reopened
  * resolution:  worksforme =>


 First, one clarification - deinterlacing is missing on most of standard
 definition DVB channels that I can receive from Comcast. HD channels show

 Second, to follow up, I've done some digging of the logs, and here is an
 interesting snippet (which goes on and on when watching DVB) from
 mythfrontend -v playback:

 2007-07-18 00:55:38.226 Enabled deinterlacing
 2007-07-18 00:55:38.254 Avg read interval was 198 msec. 256K block size
 2007-07-18 00:55:38.507 NVP: progressive frame seen after 10 interlaced
 2007-07-18 00:55:38.551 NVP: interlaced frame seen after 1 progressive
 2007-07-18 00:55:39.040 NVP: progressive frame seen after 14 interlaced
 2007-07-18 00:55:39.072 NVP: interlaced frame seen after 1 progressive
 2007-07-18 00:55:39.588 NVP: progressive frame seen after 15 interlaced
 2007-07-18 00:55:39.688 Set video sync frame interval to 33366
 2007-07-18 00:55:39.688 Disabled deinterlacing
 2007-07-18 00:55:39.765 NVP: interlaced frame seen after 7 progressive
 2007-07-18 00:55:39.788 Set video sync frame interval to 33366
 2007-07-18 00:55:39.788 Enabled deinterlacing
 2007-07-18 00:55:40.121 NVP: progressive frame seen after 12 interlaced
 'video_output' mean = '34089.33', std. dev. = '14141.37', fps = '29.33'
 2007-07-18 00:55:40.187 Set video sync frame interval to 33366
 2007-07-18 00:55:40.187 Disabled deinterlacing

 It means that deinterlacing algorithm is there, its just being toggled
 back and forth all the time, which is observed as lack of deinterlacing. I
 can post recording file if you want to look into it.

 Here's some code digging:
 void NuppelVideoPlayer::AutoDeint(VideoFrame *frame)
     if (frame->interlaced_frame)
         if (m_scan_tracker < 0)
             VERBOSE(VB_PLAYBACK, LOC + "interlaced frame seen after "
                     << abs(m_scan_tracker) << " progressive frames");
             m_scan_tracker = 0;
         if (m_scan_tracker > 0)
             VERBOSE(VB_PLAYBACK, LOC + "progressive frame seen after "
                     << m_scan_tracker << " interlaced  frames");
             m_scan_tracker = 0;

     if ((m_scan_tracker % 400) == 0)
         QString type = (m_scan_tracker < 0) ? "progressive" :
         VERBOSE(VB_PLAYBACK, LOC + QString("%1 %2 frames seen.")

     int min_count = (ringBuffer->isDVD()) ? 0 : 2;
     if (abs(m_scan_tracker) <= min_count)

     SetScanType((m_scan_tracker > min_count) ? kScan_Interlaced :
     m_scan_locked  = false;

 ... according to the log, SetScanType() is getting toggled every 40-50

 So here's more quick code digging. frame->interlaced_frame can be set to 0
 only in avformatdecoder.cpp, mpegvideo.cpp or png.c (without yet knowing
 which one is actually called). Apparently, they always decode the flag
 from the content frame-by-frame. It appears that Comcast sends
 "progressive" frames once in a while. I believe that there are no true
 progressive frames if the channel is reported as interlaced, since
 industry has decided to always broadcast interlaced streams in order to
 support all the millions of analog TVs out there (which do not have
 capability to interlace the picture) and make settop boxes as simple (and
 cheap) as possible. For some reason this decision carries into HD
 broadcasts as well. In light of this, periodic progressive flag can be a
 bug in Comcast (or their supplier's) codecs or intentional encoding
 misrepresentation, if it is not result of some bug in the decoders.

 I looked at the picture with compiled "return;" before SetScanType() in
 the above code, and it looks deinterlaced OK all the time and appears
 without any of artifacts attributable to deinterlacing progressive frames.
 I will keep it this way in my sandbox, untill someone from developers come
 up with a better solution that will hopefully work for everone.

 In the presented case it seems reasonable to have something like "ignore
 periodic DVB progressive flag" next to "deinterlace" option in playback
 settings or better one for each DVB channel, which will turn off this
 insane toggling. I'm not trying to open a discussion here, but realities
 of life prompt for fixes of somebody else's screwups pretty often. This
 will be one such fix.

 I still have gripes with other deinterlacing issues - (1) pause picture is
 interlaced / jagged, while it should not be, (2) deinterlacing option
 should be available for recording - it will allow much lighter hardware
 for MythTV clients to show HD content. But these are for other tickets.

Ticket URL: <http://svn.mythtv.org/trac/ticket/1087#comment:5>
MythTV <http://svn.mythtv.org/trac>

More information about the mythtv-commits mailing list