[mythtv-commits] Ticket #3139: Resolution-based autodetection of transcoding profiles

[MythTV]

#3139: Resolution-based autodetection of transcoding profiles
---------------------------------------------------+------------------------
 Reporter:  Garrick James <mythtv at jamesplace.org>  |       Owner:  ijr    
     Type:  patch                                  |      Status:  new    
 Priority:  minor                                  |   Milestone:  unknown
Component:  mythtv                                 |     Version:  0.20   
 Severity:  medium                                 |  
---------------------------------------------------+------------------------
 MythTV currently (as of 0.20) has a very simple detection process for
 automatically selecting a transcoding profile.  The selection is based on
 the encoding type of the source content.  If the source content is MPEG2,
 then the "MPEG2" transcoding profile is used.  If the source content is
 RTjpeg or MPEG4, then the "RTjpeg/MPEG4" profile is used.

 This is very limiting for systems which have a digital tuner card such as
 the pcHDTV series of tuners.  Such cards often output content of a uniform
 encoding type (MPEG2 in the case of the pcHDTV), but with different
 resolutions specific to the recorded program (e.g. standard def. over QAM
 DTV channels, standard def. re-cast over ATSC/QAM HDTV channels, and
 various native HDTV formats).  Given that all output is (often) of a
 uniform encoding type, all recordings would be funneled through a single
 transcoding profile under the current logic.

 Attached is a patch that expands the detection logic.  It adds the ability
 to automatically select a transcoding profile based on the vertical
 resolution of the source content and whether the content is interlaced or
 progressive.  Horizontal resolution is not used in the detection logic, as
 it can vary quite a bit for a given vertical resolution in both the
 standard def. and high def. worlds.

 The interlaced/progressive detection logic is very strict to the PAL and
 NTSC standards.  If the frame/field rate of the source content rounds to
 either 25 or 30 Hz, the source is considered to be interlaced and an "i"
 is suffixed onto the vertical resolution.  If the rate rounds to either 50
 or 60 Hz, the source is considered to be progressive and a "p" is suffixed
 onto the vertical resolution.  If the rate is something else entirely, the
 interlaced/progressive quality is considered to be unknown and is not used
 in the selection of a transcoding profile (i.e. no suffix is added to the
 vertical resolution).

 The new logic looks for a transcoding profile using the following name
 format:

 Autodetect from %1

 where "%1" is replaced with the vertical resolution of the source content
 (including the interlaced/progressive qualifier, if any).  Note that a
 vertical resolution of 1088 is considered to actually be 1080 (why, oh
 why,  did "they" make 1080i and 1080p HDTV signals actually 1088 in
 vertical resolution? why didn't they call it 1088i and 1088p?).  Note that
 the string "Autodetect from %1" is actually looked up in the UI
 translation files.

 Some (possibly unrealistic) examples (assuming english translations):

 o    If the source content were 1280x720 (HxV) and the frame/field rate
 were 59.94 Hz, the logic would look for a transcoding profile named
 "Autodetect from 720p".

 o    If the source content were 960x720 (HxV) and the frame/field rate
 were 59.94 Hz, the logic would also look for a profile named "Autodetect
 from 720p".

 o    If the source content were 1280x720 (HxV) and the frame/field rate
 were 29.97 Hz, the logic would look for a profile named "Autodetect from
 720i".

 o    If the source content were 1280x720 (HxV) and the frame/field rate
 were 31.23 Hz, the logic would look for a profile named "Autodetect from
 720".

 o    If the source content were 1920x1088 (HxV) and the frame/field rate
 were 29.97 Hz, the logic would look for a profile named "Autodetect from
 1080i".

 If a transcoding profile is found that matches, it will be used for the
 transcoding.  If no matching profile is found, the code falls back to the
 old detection logic that uses encoding format detection (MPEG2 vs.
 RTjpeg/MPEG4).

 Currently, there is no way to add new transcoding profiles via the UI.
 Either existing profiles need to be renamed or a bit of SQL is needed to
 add new entries.

 Can someone fold this into the mainline?  It doesn't change or interfere
 with the existing auto-detection logic when the new, specially named
 transcoding profiles do not exist.

 Also, is there anyone that can give me some pointers on how to get the UI
 to allow adding transcoding profiles?  I've played around with
 uncommenting the line that adds "(Create new profile)" to the lists of
 recording profiles in the setup dialogs, but that doesn't work right.  It
 lets one add a profile, but it doesn't allow the profile to be given a
 name and it always sets the profilegroup id to 0.  :-(

 Thanks,
 Garrick James <mythtv at jamesplace.org>

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/3139>
MythTV <http://www.mythtv.org/>
MythTV