[MPlayer-dev-eng] [PATCH] introducing -vf pretend (was: removing libmpcodecs/vf_rbg2bgr.c)

[Reimar Döffinger]

On Wed, May 26, 2010 at 09:07:28AM +0200, Attila Kinali wrote:
> On Tue, 25 May 2010 00:28:08 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > Hmm... Surprised this actually works... I was working on extending
> > -vf format to do something like this but expected it to not work...
> > The "problem" I have with it is that
> 
> > > +The user is responsible that input and output formats are structurally
> > > +similar. Otherwise all odd effects can occur.
> 
> > means you actually can only use it with a format filter in front, otherwise
> > you can't know what will happen.
> 
> Yes. I thought this too, but didn't see any simple way to
> check whether input and output formats are compatible.
> 
> Is there a way to figure out how many planes a colour format
> uses (independent of what mp_image says) and what subsampling
> it uses, if any?

mp_image_setfmt and mp_get_chroma_shift respectively.

> > Another minor annoyance is that it won't automatically select the "best" RGB/BGR
> > format, however I think it's reasonable to ignore that.
> 
> This could be actually solved by using classes of formats.
> Ie, specify that the output is of type BGR and then select the
> right one based on the given input type.

Yes, on the other hand extending vf_format is a more flexible solution in principle,
though it has a higher "shooting yourself in the foot" potential.

> > Maybe you could have a look at what I did for -vf format and see if you think
> > this might be a better solution (assuming we can get it to work)?
> 
> This might be a good idea, but doesnt solve the above problems completely.

No, it only avoids that "all hell breaks lose" in case the input colour format changes
(e.g. when playing multiple files).