Sinks get appended the `sync=true` flag, even if they don't support it

[rgon]

Uxplay is adding sync=true (or false) to all sinks. See:

$ uxplay -async no -vs "identity" -d
GStreamer video pipeline will be:
"appsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! identity name=video_sink sync=true"

Due to the lines here (and audio equivalent):

UxPlay/renderers/video_renderer.c

Line 359 in 090c5ba

g_string_append(launch, " sync=true");

However, some sinks do not accept the sync property, and thus error out.

Use case:

I am trying to spawn uxplay as a process within my application, in a use case related to #459. To avoid re-encoding video, I am using ipcpipelinesink/src to pass the pipeline between processes, which itself works great (see this gist I published for more info https://gist.github.com/rgon/4e9291e2325c78fad066858e826f2f47)

This makes special sense when embedding uxplay as a source in other multimedia applications (think streaming, car head unit, presentation, video calling, meeting centers), but it may be causing issues with other use cases.

Potential solutions:

• Do not add sync property by default. Do we really need this?
• Ternary sync value: true/false/default (probably required above)
• Allow defining a fully custom pipeline

[fduncanh]

@rgon Did you explore the new option:

NEW on github: option -vrtp bypasses rendering by UxPlay, and instead transmits rtp packets of decrypted h264 or h265 video to an external renderer (e.g. OBS Studio) at an address specified in rest-of-pipeline. (Note: this is video only, an option "-rtp" which muxes audio and video into a mpeg4 container still needs to be created: Pull Requests welcomed).

[rgon]

Yes, my intention was to avoid the 3-way encode/decode (Airplay -> pixel buffer -> vrtp h264 -> client decode -> pixel buffer), since I'm on a resource constrained environment and still need to minimize latency.

Ideally, I'd just setup the ipcsink based one. How could we design a flag to avoid setting the sync parameter?

[fduncanh]

UxPlay v1.73 was just released without fixing this. but if you want to propose something, please do.