Opened 13 years ago

Closed 13 years ago

#3139 closed patch (fixed)

Resolution-based autodetection of transcoding profiles

Reported by: Garrick James <mythtv@…> Owned by: cpinkham
Priority: minor Milestone: unknown
Component: mythtv Version: 0.20
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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@…>

Attachments (1)

mythtranscode-resolution-autodetect.patch (3.1 KB) - added by Garrick James <mythtv@…> 13 years ago.

Download all attachments as: .zip

Change History (3)

Changed 13 years ago by Garrick James <mythtv@…>

comment:1 Changed 13 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham

comment:2 Changed 13 years ago by cpinkham

Resolution: fixed
Status: newclosed

(In [12953]) Add the ability for the lossy transcoder's profile autodetection code to use autodetect profiles based on the height and fps of the input video. For example:

1920x1080@29.97fps video will try to use 'Autodetect from 1080i', 1280x720@59.94fps video will try to use 'Autodetect from 720p', etc..

If these special 'Autodetect from ...' profiles do not exist, the autodetect code will fall back and use the original 'Autodetect from MPEG2' and 'Autodetect from RTjpeg/MPEG4' profiles.

Autodetection mods by Garrick James. Mods by me to enable the ability to add new recording profiles via the recording profile list page. If you create new autodetect profiles, they must match the "Autodetect from ..." format above with the vertical resolution followed by 'i' for interlaced, 'p' for progressive or nothing for odd framerates that don't fall into the NTSC and PAL norms of 25/29.97/50/59.94.

Closes #3139.

Note: See TracTickets for help on using tickets.