if codec has list of supported framerates, select highest one
unless user has provided one. If we end up using CLOCK_FREQ in
time_base, it should be quite ok in most cases. Tested with ts/mp4/webm
and mp2v/mp4v/VP80. For some cases it can select higher fps in
mpeg-codecs (60fps) in case of input fps isn't yet known in that point
or is fubared.

Also add special case for MP4V as it doesn't like CLOCK_FREQ in
time_base/frame_rates.

Otherwise bitrate control is quite fobar.

Fixes #11538

Pointed out by Sesse

This should not adversely affect LibVLC: more errors cases will lead to
error code returns instead of abnormal termination. It is not strictly
semantically correct though (update to Win7 or above if you care).

MMDevice is not available on older Windows versions anyway. Failing to
load the plugin there is fine. It is even arguably better: it prevents
impossible choices showing in the preferences.

video/mpeg is underspecified, could be ES, PS or TS.
video/MP1S, video/MP2P and video/MP2T are more specific/better
specified (but should only be used internally or in SDPs).

Where the search paths list is not changed, using AC_PATH_PROG(S) has
no useful effects and makes manual override more difficult.

(Compare to Qt code using different search paths.)

Otherwise, it demuxes at max speed without allowing
user to change program

Some streams send clear padded data (probably
due to insufficient remaining data for encryption)

We'll only test on payload start then.

Since we can swap formats, some doesn't provide any or same values

Red over blue was against usability rules

Closed captions are in the same SEI user sections
as H264 according to the spec.

No functional changes.