player: more option/property consistency fixes

Some properties had a different type from their equivalent options (such
as mute, volume, deinterlace, edition). This wasn't really sane, as raw
option values should be always within their bounds. On the other hand,
these properties use a different type to reflect runtime limits (such as
range of available editions), or simply to improve the "UI" (you don't
want to cycle throuhg the completely useless "auto" value when cycling
the "mute" property).

Handle this by making them always return the option type, but also
allowing them to provide a "constricted" type, which is used for UI
purposes. All M_PROPERTY_GET_CONSTRICTED_TYPE changes are related to
this.

One consequence is that you can set the volume property to arbitrary
high values just like with the --volume option, but using the "add"
command it still restricts it to the --volume-max range.

Also deprecate --chapter, as it is grossly incompatible to the chapter
property. We pondered renaming it to --chapters, or introducing a more
powerful --range option, but concluded that --start --end is actually
enough.

These changes appear to take care of the last gross property/option
incompatibilities, although there might still be a few lurking.

1 files changed, 6 insertions, 0 deletions

diff --git a/options/m_property.h b/options/m_property.h
index 0f8230608b..d6c8c5aab3 100644
--- a/options/m_property.h
+++ b/options/m_property.h
@@ -48,6 +48,12 @@ enum mp_property_action {
     //  arg: char**
     M_PROPERTY_PRINT,
 
+    // Like M_PROPERTY_GET_TYPE, but get a type that is compatible to the real
+    // type, but reflect practical limits, such as runtime-available values.
+    // This is mostly used for "UI" related things.
+    // (Example: volume property.)
+    M_PROPERTY_GET_CONSTRICTED_TYPE,
+
     // Switch the property up/down by a given value.
     // If unimplemented, the property wrapper uses the property type as
     // fallback.