After doing some testing. It seems that with Google Video calls, if one does not start sending video soon enough, enabling the video later may break things. But, with the new WLM calls, it is possible to disable/enable the camera during a call (it does proper SIP negotiation for that). So we have two different cases of ImmutableStreams, I propose adding a "AlwaysSend" to Gabble for Google Video calls. That also means the CM will start sending from the start if that property is set. Changing the recv part is still possible (ie drop incoming buffers to reduce processing).. although we can't do too much of that so as to not lose keyframes.. We could also call it "ImmutableDirection" or something.
arg, I may be wrong here, let me investigate further first...
Alright, I found the problem causing this, so I guess we dont need this workaround..
Even if we don't need this for Gabble, if I remember correctly Mikhail wanted ImmutableDirection (or to make ImmutableStreams imply immutable directions) to be settable via a CM parameter for telepathy-sofiasip, to cope with certain deficient SIP servers. (There is currently an immutable-streams CM parameter which sets ImmutableStreams on every StreamedMedia channel, and can be configured by the user or pre-set from a Maemo .profile file; ImmutableDirection would presumably be similar.) Mikhail: comments?
Yes, it seems useful to have a way to tell the client not to change the direction even if it would do normally, and resort to other means of reducing resource usage. For example, when the video call application was made invisible on the desktop, running the full video playback stack is wasteful (think of mobile devices here), and sending captured video may even be considered a privacy issue. If directionality can't be renegotiated, the client/stream engine should know to stop running the full pipelines, switching to sending trickle packets. I can't tell if there are many real-world cases for ImmutableStreams and ImmutableDirection to be separate flags, but it's possible.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.