Allow changing of aspect ratio when transcoding

[wagspat@…]

This is a patch against 0.20 that accomplishes a couple of things. First, I've included my original fixes from #2198 on this, so 1080i streams are resized properly. Secondly, I've added a new setting for MPEG4 transcoders that sets the aspect ratio. This is exposed as a new option called "Aspect Ratio" with a drop-down menu that provides the options of "Leave", "4:3", and "16:9".

When selecting a different aspect ratio, the transcoded file will be cropped to the proper aspect ratio. So if the source is a 16:9 file recorded from an HDTV channel and the mpeg4aspectratio is set to 4:3, the sides will be cropped off when transcoding. This is very helpful for when you've recorded an SDTV program on an HDTV tuner (like the Simpsons).

Likewise, when set to 16:9, this will crop the tops off the file, which is useful if you've recorded a letterboxed program on an SDTV feed.

This helps to make the files more portable, makes watching recorded programs in MythTV behave properly when using a zoom mode, and may even promote world peace. If the powers that be conclude that this makes sense, I'll work on porting it to SVN. Unfortunately, right now I'm not running SVN because my wife likes a working myth box.

[wagspat@…]

example patch that implements aspect ratio setting on mpeg4 transcoders

[wagspat@…]

updated version of the patch for 0.20.2

[patrick@…]

I've gone through and updated this patch for the 0.20.2 release of MythTV. This patch also includes the fixes from #2198, which were put in the trunk by cpinkham in [11462], but haven't been backported to the 0.20 series.

[patrick@…]

updated version of the patch that adequately deals with non-square pixel videos

[patrick@…]

I realized when I was updating my library last night that videos without square pixels, such as 720x480 NTSC captures weren't being resized to the right sizes. The newest patch fixes this issue and adds a warning if a video is not currently in 4:3 or 16:9, in which case it has no idea which dimension should become the dominant dimension.

I suppose I could probably do some sort of heuristic with this, but I don't think it's really worth it. Are there common video sources for MythTV that you may want to crop to an aspect ratio that aren't already in these formats?

[patrick@…]

patch against 0.21-fixes, revision #18812

[patrick@…]

The latest version of the patch addresses only the issues with letterbox/pillarbox recordings. I removed all the old cruft that isn't needed because of changes to mythtv that resolved other tickets.

[anonymous]

As an aside on DVB in UK films have different aspect rations to adverts - when archiving to DVD the aspects all look odd. Could we make is split the files on aspect ratio changes - then this could be used by the python to correctly create DVD's ?

[cpinkham]

Aspect Ratio patch modified to work with trunk & with deinterlacing ability

[cpinkham]

I attached an updated version of the patch updated to work with trunk. It has been reworked a little to eliminate some code duplication and also has an added option to support deinterlacing the video before cropping and scaling.

[cpinkham]

Moving some things to 0.24 since we're almost at the 0.23 feature freeze.

[anonymous]

I would prefer a different heuristic here. Rather than just blindly cropping, we should pad with letterboxing/pillarboxing if needed, and crop if possible.

ideally: we should strip off all letterboxing/pillarboxing, resize, transcode... then repad to the desired aspect ratio (per frame would be wonderful!), regardless of source aspect ratio. This way we don't waste valuable bits on encoding black bars, AND we don't lose the contents as we would in some cases with a blind cropping.

To do this would require intelligent cropping, and this would likely be slower than desirable though.

[beirdo]

stupid chrome logged me off. That was me.

[Peter Bennett]

Closing this as abandoned.

In case somebody want to reopen it - I would prefer to see automatic cropping as is done by HandBrake?, for example. Using a manual method as described here could result in incorrect transcodes if the option is not correctly applied.