[mythtv] automatic 14:9 or 4:3 zoom based on black bars detection?

[Daniel Kristjansson]

On Sun, 2006-06-25 at 19:47 +0200, Petr Stehlik wrote:
> Daniel Kristjansson píše v Ne 25. 06. 2006 v 11:41 -0400:
> > > Now I'd like to automate the switching between the zoom modes. First, if
> > > the source is in 4:3 format then I'd like to enable the 14:9 Zoom by
> > > default. Could someone please suggest a place in the source code to
> > > check for the input format and to enable/disable the zoom?
> > There isn't a place for this. There are three distinct reasons
> > why people use the aspect ratio overrides.
> >  1/ For coping with material that misreports the aspect ratio;
> >     or does not report it at all and uses non-square pixels.
> >     This would never be a 14:9 aspect ratio BTW, as we are 
> >     refering to the aspect ration of the transmission including
> >     the black bars.
> >  2/ For zooming into material simply as you do ( and I do ).
> >     "Proper Zoom"
> >  3/ For filling the screen with video when the aspect ratio
> >     of the source material does not fit the display aspect ratio.
> >     This results in either lost portions of the image, or the
> >     improper aspect ratio; but this is the desired result.
> >     "Improper Zoom"

> > So before you do any auto-zoom work or add 14:9 zoom you would
> > want to separate out the proper zoom portion (#2) of the "aspect
> > ratio overrides" into a new setting.

> So 1/ would be 
> - keep original aspect ratio
> - set aspect ratio to 4:3
> - set aspect ratio to 16:9
Sounds right

> 2/ would be
> - no zoom
> - partial zoom (currently named 14:9)
> - max zoom (currently named "4:3 Zoom" or "16:9 Zoom")
Yep, you wouldn't need separate "4:3 Zoom" and "16:9 Zoom" anymore.
There is also "Fill" which keeps the proper aspect ratio but cuts
off some of the vertical or horizontal part of the image, would
probably put that here as well.

> 3/ would be
> - keep original
> - fill the screen ignoring the original aspect ratio
> - I could think of "fill the screen vertically while keeping the aspect
> ratio" and "fill the screen horizontally" but that's basically what the
> "4:3 zoom is trying to achieve", I think, so it could be part of the
> proper zooming.
I guess I should have read this first. There are really two fill modes,
one which cuts off a portion of the image and one which screws with the
aspect ratio but keeps the whole image, I would put the first in the
proper zoom list, and the latter in the aspect ratio list.

> Anyway, what I'd like to do now is to hack Myth to detect that if I
> switch to a new channel that is 4:3 then I want the 14:9 Zoom to get
> preset. So if you could suggest a place in the replay routine that is
> run after source change (or better yet after source aspect ratio change)
> I'd try to put the preset there.
SetVideoAspectRatio() in videooutbase.cpp is what you want, this gets
called whenever the aspect ratio changes.

> BTW: a note to current 'change aspect ratio' setting in MythTV: Myth
> detects all changes in aspect ratio both when changing channels and
> in-channel changes perfectly but as soon as I select say "4:3 Zoom" then
> this zoom is preset even when I switch to another channel that is 16:9,
> for example. I think it shouldn't be this way - when I go to channel
> with different AR the zoom should go back to default, I think.
Yes, this is because "4:3 Zoom" is both forcing the aspect ratio
to 4:3 and performing the full zoom function. If you separate
these out then you can apply just the zoom, but not the forced
aspect ratio. Or you could have the zoom only apply when the
video is using a particular aspect ratio.

> BTW2: related to previous: there is no option in the MythTV menu
> (play.cpp I think) to go back to "automatic aspect ratio changes" or
> basically to "no aspect ratio override".
Hmm, you can get to this via the keybinding. I don't actually use
the menu much for this, but if it is missing this is a bug.

> > > Is it possible (and cheap) to detect the black bars?
> > Depends on where you are. In the image preview or the commercial
> > detector it is easy. You have an image to work with of a frame,
> > unlike in the frontend when you wouldn't always have access to
> > this.
> so it would have to be preprocessed like the commercial detection. Hmm.
> Maybe in the almost-real-time mode it would be fine. But since I don't
> use the commflagging yet I am not going to work on this.
Well it could be done on playback, but you would need to sample the
frames every once in a while (i.e. starting a separate decoding
thread when using something like X11 XvMC of Macintosh CoreAVC)
and you would need to keep running averages, throw out outliers,
etc. It would be much more complicated. With real-time commercial
flagging working almost perfectly it doesn't make much sense to
go that route. Especially since it could be made to work in LiveTV
mode with just a few minor changes.

-- Daniel