[MPlayer-dev-eng] [PATCH] deinterlace property fix

Alexander Strasser eclipse7 at gmx.net
Thu Oct 25 20:34:10 CEST 2012


Alexander Strasser wrote:
> Vicente Sendra wrote:
[...]
> > If you look at properties for brightness, contrast, hue, saturation, if you can not set or get them (not handled by any filter in the filter chain), it returns either value from set_video_colors if > 0 (just 1: M_PROPERTY_OK) or M_PROPERTY_UNAVAILABLE if no filter handles it.
> > 
> > Maybe M_PROPERTY_ERROR is not the correct one, but, i think the right thing should be something like this:
> > 
> > at getting:
> > M_PROPERTY_OK if some vf handles it.
> > M_PROPERTY_UNAVAILABLE if no filter handles it or assume it is disabled and return M_PROPERTY_OK (just as it is right now)
> > 
> > at setting
> > M_PROPERTY_OK if some vf handles it.
> > M_PROPERTY_UNAVAILABLE if no filter handles it
> > maybe M_PROPERTY_DISABLED if no filter handles it and we want to set it to true
> > 
> > For me it's not logical to return M_PROPERTY_OK if the property was not set, it's more logical to return M_PROPERTY_UNAVAILABLE, so i can know if setting was successful, without having to request property one more time just to check if it was really set.
> 
>   I agree with you that M_PROPERTY_UNAVAILABLE might be more correct and
> better for handling on the client/caller side.
> 
>   I will look into it. I have the complement part of the patch in a local
> branch and can easily change and commit it. I just need to look if simply
> returning M_PROPERTY_UNAVAILABLE if the return value is not CONTROL_OK is
> enough or if there is another catch.

  I committed it as was in your patch, but used M_PROPERTY_UNAVAILABLE
instead of M_PROPERTY_ERROR. Though I really must admit that I am not
sure this is fully correct. It leaves the feeling that things are not
entirely consistent and that we maybe misunderstood what the initial
developer of the property system wanted us to do in that case.

>   Having said that, my current opinion is that it would be an improvement
> anyway.

  But as stated above, it seems to improve things *now* and that is the
reason I decided to change it as you suggested.

  Alexander


More information about the MPlayer-dev-eng mailing list