Add vertical strech fill mode

[mythdev@…]

In the Netherlands, the analog broadcasters have a lot of shows that are in the letterbox format.

That means there are 2 black bars in the signal, so my PVR-150 records the video with the 2 bars in it, which is the expected behavior. Playing back these videos on a MythFrontend results in the black bars being displayed as well, as is expected, since the bars are in the video.

This patch adds a new fill method "Vertical Stretch" which removes the black bars from the visible area.

Also this patch fixes a bug with the VideoOutput::ToggleAdjustFill?, as kAspect_END was used and it should be kAdjustFill_END.

In the past there has been a lot of discussion on whether or not to add this fill mode, but I see no other way to accomplish this. Please see the attached screenshots for the differences between the fill modes.

My FE is set to 16:9 aspect ratio. Also the MPEG2 file has the 16:9 aspect ratio, but the black bars are recorded into the MPEG2 file, because that is the way a lot of shows are broadcasted here (analog).

[mythdev@…]

The patch that adds a vertical stretch fill mode and fixes the kAspect_END bug

[mythdev@…]

This is how the content looks with the "full" fill mode (notice the logo is out of the displayable area)

[mythdev@…]

Original content, without a fill mode

[mythdev@…]

Content when the fill mode is Vertical Stretched (Notice all content is in the viewable area now)

[Dibblah]

Please look at #4872 for an alternative solution

[mythdev@…]

This fill mode can be used together with the patch from #4872, but still, the "half" and "full" fill modes are not really suitable to be used in the case I described.

[Robin Gilks <g8ecj@…>]

Works great for the use case of capture from an STB where the provider can't make up their minds just which way (letter or pillar box) they are going to broadcast where the PVR150 is capturing in 16:9. Having the one extra (symmetric) choice allows for all instances.

Applied cleanly with fuzz to 0.21-fixes r18091.

[mythdev@…]

Is there any change this patch will make it into mythtv? And if not, why not.

I do not want to sound impatient or ungrateful, because I really love mythtv, but I am just interested in why this ticket does not get any reaction from one of the "core" developers. Is it the way I made the patch or the ticket? Or is this feature not wanted?

Thank you for understanding and please do not feel offended.

[anonymous]

Replying to mythdev@telfort.nl:

Is there any change this patch will make it into mythtv? And if not, why not.

I do not want to sound impatient or ungrateful, because I really love mythtv, but I am just interested in why this ticket does not get any reaction from one of the "core" developers. Is it the way I made the patch or the ticket? Or is this feature not wanted?

Thank you for understanding and please do not feel offended.

The same reason #4872 isn't in yet, or the same reason why it took #1104 almost 2 years to get included, because the developers have other priorities and huge backlog of tickets. Unfortunately, sometimes good (and bad) patches sit a LONG time in trac. Wish it wasn't the case, but complaining probably won't help... if it's still not in within the next 8 months, then ask again.

[danielk]

All additional stretch modes should be user defined by saving and naming a manual zoom.

[danielk]

(In [20406]) Fixes #5622. Adds a vertical stretch mode.

Note: This breaks the 'no new general zoom modes' rule, but Robin Gilks made a valid argument that stretch modes can not be implemented as saved manual zooms.