Improve video constraints (width|height|aspectRatio|frameRate).(ideal|exact) and add (aspectRatio|frameRate).(ideal|exact) support

[hthetiot]

• implement getUserMedia constraints video.(width|height|aspectRatio|frameRate).(ideal|exact) and add video.(aspectRatio|frameRate).(ideal|exact) support
• update PluginRTCVideoCaptureController aspectRatio and improve default constraints handling
• Handle aspectRatio: 16/9, that was failing before due NSNumber to Float32 issue (e.g 1.7777777777777777 to 1.777778)
• Add more debug for fail exact requirement

Testing

To test task/fix-video-constraints branch

cordova plugin remove cordova-plugin-iosrtc --verbose
cordova plugin add https://github.com/cordova-rtc/cordova-plugin-iosrtc#task/fix-video-constraints --verbose
cordova platform remove ios --no-save
cordova platform add ios --no-save

[hthetiot]

@menelike this should do it.
You cannot set default aspect ratio only like you did, otherwise this would fail.

width: {
    max: 1280,
    min: 640
},
height: {
    max: 720,
    min: 720
}

Feel free to fork this branch and tests.

[hthetiot]

This will fail:

constraints: {
        video: {
          height: {
            ideal: 240,
            min: 180,
            max: 480
          }
        }
      }

[hthetiot]

constraints: {
        video: {
          height: {
            ideal: 240,
            min: 180,
            max: 480
          }
        }
      }

This will works now, but ideal is not really implemented.

• https://github.com/cordova-rtc/cordova-plugin-iosrtc/blob/task/fix-video-constraints/src/PluginRTCVideoCaptureController.swift#L387

[hthetiot]

@menelike Can you try this last changes, this would help a lot.

[hthetiot]

behavior of aspectRatio: 16/9 vs aspectRatio: {exact: 16/9} should be the same.
See Spec.

@menelike the spec say it, read it again.
I never said ideal I said exact

If the constraint is required (constraintValue either contains one or more members named 'min', 'max', or 'exact', or is itself a bare value and bare values are to be treated as 'exact'), and the settings dictionary's value for the constraint does not satisfy the constraint, the fitness distance is positive infinity.

https://www.w3.org/TR/mediacapture-streams/#media-track-constraints

[hthetiot]

We dont support resizeMode out of topic.

[hthetiot]

@menelike Please try the basic. (height|width|framerate|aspectRatio).(min|max|exact|ideal).
You keep changing the scope every issues, now you talking about resizeMode that not what we want do achive here, we want simple support for (height|width|framerate|aspectRatio).(min|max|exact|ideal) nothing else.

I'm starting to losing patience.

[hthetiot]

Every time you are in a issue you add stuff that complexify the feature request, add to the request.
Please test the basic so we can iterate, nothing else than the basics.

[hthetiot]

don't know why it switches between 715 and 716, to my understanding >= 640 && <= 720 should result in 640 and > 720 && <= 800 should result in 800. Though the spec is not clear if 720 should result in 640 or 800 - or I have missed that part.

Chrome do not follow spec, they still have 2014 spec for getUserMedia DO NOT compare with chrome. We not going to implement based on Chrome specially since it's not even clear why they do what they do.

[hthetiot]

Ideal is simple, if you have a min/max and it match multiple sizes, it should pick the one that is ideal if available, that this PR will not support yet. This PR will only support min/max or exact and if ideal will be equivalent to min=max=ideal for now.

[hthetiot]

I pushing this to 6.0.1 if it was tested properly could have been released on 6.0.0 but like usual it get out of topics....

[hthetiot]

Closed in favor of #451 451