[MPlayer-dev-eng] [PATCH] introducing -vf pretend (was: removing libmpcodecs/vf_rbg2bgr.c)
Reimar.Doeffinger at gmx.de
Wed May 26 18:59:14 CEST 2010
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).
More information about the MPlayer-dev-eng