sub_enable_stream() waits for a segment boundary

[jackjansen]

I think I have found why we experience slow startup in VR2Gather and not in our Python test code.

In VR2Gather we call sub_enable_stream() very early (right after sub_play()), and it appears as though this call blocks until it has been successful. I.e. until the next segment boundary has happened.

One point of discussion is whether this blocking is a good idea.

Another point of discussion is, assuming it is a good idea, whether it should also block if I am calling sub_enable_stream() for the exact streams I have already enabled.

@rbouqueau let's discuss.

[rbouqueau]

I checked and it indeed acquires a lock to avoid race conditions.

I think this was thought for changin while running, not at startup time.

What's the point of calling sub_play() before rather than after sub_enable_stream() ?

[jackjansen]

Good point!

[jackjansen]

... except it doesn't fly:-)

I can't do get_stream_count() and get_stream_info() before play(), I think....

And I need that information to be able to determine which streams I want to enable/disable.

[jackjansen]

Thinking about it a bit more: blocking in sub_enable_stream() probably isn't a good idea (if we can do without it). Because often during runtime I will want to do sub_enable_stream() for multiple tiles (because I want to enable high quality for viewer-facing tiles and lower quality for the others).

With the current implementation I would be blocked on every call.

I can work around this by using a thread per tile, but only if that is needed.

[rbouqueau]

The lock is just there for safety. I checked on my end and most calls (aside from beginning/end) return immediately.

[jackjansen]

@rbouqueau please explain

I checked on my end and most calls (aside from beginning/end) return immediately.

Do you mean that if I do a sub_enable_stream() directly after a sub_play() I will encounter a wait until the second segment has been received, but if I do it later (for example after I have received the first fragment of the stream) I will not have this problem?

Also, what happens if I do two sub_enable_stream() calls with different qualities requested in quick succession?

(Because this can happen quite often, unless I put a whole lot of code in my implementation: If the viewer "walks around" the tiled point cloud streams I get different tile priorities all the time, and therefore I will make different decisions on the relative importance of the tiles, and it would be good if I could just call all the sub_enable_stream() calls knowing that they will be implemented at the next segment boundary, unless overridden by a subsequent sub_enable_stream() call).

[rbouqueau]

Here is how to works. The requirements are:

• When you make a change request, it can only occur at the next segment.
• All changes need to be serialized. Since a segment is multiple seconds, we forbid queuing more than one simultaneous change request.

The solution was to create an executor that would be one thread able to queue only one task. If you submit more than one task, it blocks ! There is one per "Stream" (e.g. one per tile).

The queue is extremely easy to relax, just change this line.

Does that help?

[rbouqueau]

Today's call:

• Executor is too strict now, because the long poll lock the MPEG_DASH_Input::Stream execution.
• Jack's preference: issue as many sub_enable_stream() calls. It would overwrite the already queued one + msg (Debug level) if we overwrite. Jack suggests processStream() uses the last one.

[rbouqueau]

Done in MotionSpell/signals@68e8243.