getSupportedProperties is registry-dependent and not surface-accurate (client sinks miss supported properties, e.g. 'sync')

[Ulrond]

Summary

IMediaPipelineCapabilities::getSupportedProperties() does not return a stable, surface-accurate answer. GstCapabilities::getSupportedProperties() scans all registered GST_ELEMENT_FACTORY_TYPE_MEDIA_{AUDIO,VIDEO,SUBTITLE} sink/decoder/parser factories and returns a property name if any of them installs it. So the result:

1. Depends on registry state at call time — it grows as plugins/elements register over a process's lifetime, so two callers at different moments get different answers.
2. Reflects arbitrary platform elements, not the surface the caller uses — it can report a property that the Rialto client sink does not expose.

Observed

• getSupportedProperties(AUDIO, {"sync", ...}) returns sync.
• rialtomseaudiosink (rialto-gstreamer) exposes no sync GObject property — it derives from GST_TYPE_ELEMENT; sync is carried by other platform audio sinks the scan also sees.
• The backend nonetheless honours sync (SetupElement sets sync on the sink), so this is not 'sync is unsupported' — the capabilities API disagrees with the actual client surface about whether sync is part of the contract.

Reproduced deterministically (rialto v0.22.3 + rialto-gstreamer v0.20.1).

Impact

rialtomse*sink calls getSupportedProperties once at class-init and installs the returned subset permanently. A property not reported at that early moment (because a bearing element is not yet registered) is never installed on the sink — even though a later native query reports it supported. An application relying on the capabilities API and one inspecting the actual sink therefore see different property sets, and the answer is not portable/deterministic across targets.

Questions

1. Is getSupportedProperties intended as a stable per-source property contract, or as a 'does any element on the platform currently support this' probe? Its name and use (gating client-sink property installation) imply the former.
2. If a contract, should the scan be pinned to a defined element set (or the supported set specified directly) so it is deterministic and reflects the properties the Rialto surface actually exposes — independent of registry population order?

Refs

• media/server/gstplayer/source/GstCapabilities.cpp — getSupportedProperties factory scan.
• media/server/gstplayer/source/tasks/generic/SetupElement.cpp — backend sets sync.
• rialto-gstreamer source/RialtoGStreamerMSEAudioSink.cpp — class-init getSupportedProperties → conditional g_object_class_install_property.

Found via an external interface-conformance suite (a stable, platform-independent property contract is required for portable client migration).