Fix input queueing when some of the inputs do not produce frames/samples

[wkozyra95]

Steps to reproduce:

• start more than one stream when one of them is shorter than the others
• when the first stream is finished other streams might disappear

What happens:

• normally queue is
  • checking if all inputs are ready (and pulling from channel if necessary)
  • for each input:
    • dropping old frames
    • taking first frame (first not dropped should be the one we want to use)
• if one input is done without sending EOS, but just stops sending data
  • checking if all inputs are ready is lazy, so if it checks that one specific input that ended it does not check any further
  • for each input:
    • dropping old frames will work, but because previous step did not enqueue new frames from the channel we are left with one outdated frame
    • taking first frame return old frame (latter renderer can see that frame is older by more than 500ms and drops it, replacing with a black screen)

Alternative approach could be to replace call to any https://github.com/membraneframework/live_compositor/blob/master/compositor_pipeline/src/queue/video_queue.rs#L103 with non-lazy alternative, but I think this is cleaner.

[WojciechBarczynski]

It's awful. I hate it. Over and over we rely on some internal behavior of this function (enqueuing frames / reading them from the channel).

I'll try try to simplify this logic, cause reading all the queue code slowly feels like reading brainfuck.

[wkozyra95]

This is a tradeoff we can either:

• check_ready_for_pts even though we don't need return value
• write function that is almost identical, or inline that logic inside this function
• ensure that when we check all inputs that check_ready_for_pts is always called for all inputs

My reasoning here is that:

• approach 1 is very safe, because it's "public` method that can be used atomically. Safe here means that it does not break anything, but still does not grantee that enqueue will happen inside.
• approach 2 would be more readable, but generated more code, or required risky refactor. It might be good idea for follow up, I'm open if you want to try to improve that, but note that this is more tricky than it seems and big rewrite is more likely to introduce more bugs.
• approach 3, Similar to approach 1, but worse because we need to be careful that checking port happens before get_frames

[WojciechBarczynski]

I would prefer having a function like get_frames and calling it here and in the check_ready_for_pts function

[wkozyra95]

that would not work with current architecture:

• get frames needs to return function whether it's ready or not
• currently get frames relies that returned frame will be used (it's needed for example to check whether EOS was sent)

And if you are suggesting to change the above, then your suggestion boils down to almost full rewrite of queuing code.

We can talk about it more at the office, topic is to complex for discussion via comments.