Transmission using the Teleport filter on a video capture device fails every 2nd time

[YorVeX]

OBS 27.2.4 64 Bit on Windows 10 21H2 with Teleport 0.4.1 I don't have any software firewalls running, Windows firewall is disabled on both PCs.

In my test setup I have one sender OBS on the gaming PC and two receiver OBS instances on the streaming PC. The sender is transmitting a full Teleport stream as configured from Tools -> Teleport (called "Base") and another separate stream only for the cam capture device (called "Face Cam") by using the Audio/Video Teleport filter on this device. The two receivers receive both the "Base" and "Face Cam" streams as separate sources each. I leave the cam setting set to "Partial" for the sake of these tests so that I don't additionally run into issue 1.

The "Base" feed always works for both receiver instances every single time. But the "Face Cam" feed doesn't transmit anything to both receivers. Then I restart the sender and I also get the "Face Cam" feed on both receivers. Restart again, no "Face Cam" feed, restart again, feed is back, you get it, I tried 10 times to be really sure and it's consistent.

If I do the test with only receiver 1 I get the same behavior. And the part why I am sure that it's coming from the sender: if I only test with receiver 1 and e.g. it's working this time, then if I additionally start receiver 2 it will also get the feed. If I only test with receiver 1 and it's not working this time, then if I additionally start receiver 2 it will also not get the feed.

It's weird, maybe some clean-up is not performed by the filter at the end, then the next startup fails but some kind of error handler at least does the clean-up, so that the next start then succeeds again? All I can say is that it's not related to the network port. I set a fixed port for the filter and in both cases where the feed is transmitted and where it's not send I can see with netstat that OBS is indeed listening on that port (and stops listening as soon as OBS is shutdown).

Also it only happens when the filter is used on a video capture device. When I use the filter on a VLC media source that plays a video loop everything works fine every single time.

One more thing: I just noted that after a fresh reboot the cam feed actually worked twice in a row before I started to run into the alternating pattern. So when trying to reproduce this make sure to restart OBS multiple times until it occurs.

[fzwoch]

So, in theory it should be reproducible with:

• Just one teleport sender sending just one cam filter
• Just one receiver receiving this cam

Is that right?

[YorVeX]

Yes. Though in my test case the "Base" feed always existed in addition, so I haven't really tried with only the filter feed existing. I would be surprised if it made a difference, but if I don't forget it I will try later without that and maybe even with an otherwise empty OBS instance with default settings.

Also my test was over network, maybe I should do another test within the same machine to see whether that's a relevant factor.

[fzwoch]

At least I could not reproduce it.

Sender Windows 10, receiver Linux. Using a filter for a camera source on Windows.

I closed and restarted the obs application repeatedly on the Windows machine and the Linux client tuned in correctly every time.

[YorVeX]

I believe it is a timing issue that is triggered by higher OBS load times. First of all, I could reproduce it within the same PC, so network connection is out of the picture. I did this by using a clean vanilla 27.2.4 OBS as receiver but my normal OBS as sender, cam feed was only received every 2nd time.

When I also used a clean vanilla 27.2.4 OBS as sender (with only the cam feed) the issue went away. So I went back to my original OBS and started deleting sources and scenes bit by bit, to see when the issue disappeared. Eventually it did, but unfortunately not consistently after deleting a specific source. Instead it's the number of sources (and probably more so their accumulated loading time) that triggers this issue apparently. So it only happens if OBS has a lot of stuff to load on startup.

I think I remember you writing something about Teleport caching 20 frames. What happens for example if for these first 20 frames the video device isn't outputting anything because OBS is still busy loading other sources?

I will do more tests later and try to create a scenario that can consistently reproduce it based on a clean vanilla client with only specific sources added (I'm thinking maybe several image sources with big images to load) and get back here if I got something more tangible.

[fzwoch]

I will be out for a while so I cannot play with it. If you find something that be helpful. I wonder if the issue is on the sender or receiver. Sounds like it is on the sender, but who knows. I can certainly imagine there is some timing issue, maybe a misunderstanding when it is okay to start..

So I wonder when it happens, whether it helps on the receiver to disable/enable it again and it will find the stream or not.

The internal queue should not matter I believe. It just drops frames in case the queue is full. If there is a receiver it should still get something.

[YorVeX]

So I wonder when it happens, whether it helps on the receiver to disable/enable it again and it will find the stream or not.

All of the tests I have conducted so far pointed in the direction that it's on the sender side. Especially when I leave the receiver running and restart only the sender and keep on getting the error only every 2nd time. But, if it all wasn't confusing and complicated enough already, with some more tests it seems to be...both?

Here's a funny test scenario I just did:

• Start Sender and Receiver 1 and Receiver 2 when the bug occurs
• On Receiver 1 open the Teleport source for the cam, switch to "- Disabled -" in the drop-down list and immediately back to the right Teleport stream
  • Now it's fixed for Receiver 1, the cam stream is received correctly
• Do the same on Receiver 2
  • It's not fixed for Receiver 2, it stays broken!
• Do the same on Receiver 2 once more
  • This time it's also fixed for Receiver 2
• Restart Receiver 2
  • The problem came back for Receiver 2, while Receiver 1 stayed working throughout all of these tests
• Restart Sender
• Now it's working for both Receiver 1 and Receiver 2
• Exit Receiver 1 and Receiver 2
• Start Receiver 2, then Receiver 1
  • It's working on Receiver 2 but not Receiver 1
• Exit Receiver 1 and Receiver 2
• Start Receiver 1, then Receiver 2
  • It's working for both receivers

Honestly, the more I tests the less I seem to understand about this behavior 😀

There seems to be so many factors involved here that it's really hard to detect where it's coming from by such tests. I think the best really is if you get to reproduce it yourself and from there debug it to find out what's going on.

But there's one thing I noticed. I don't know what changed since my last test except that I rebooted the PC and two days went by, but instead of an empty window I now also get the green feed in cases where the issue occurs as in #34 despite color range being set to "Partial" for these tests. Also, unlike for issue #34, switching between "Partial" and "Full" never fixes this issue.

Still I wonder whether this all might actually also be related to #34 in some way.

[YorVeX]

Forget it. All of it. This was entirely my fault.

When doing my tests for #34 I also wanted to know whether I get that green feed bug on another source (before I even knew it had to do with the Color Range setting), so I added another Teleport filter to a different source (a VLC source showing a feed from an IP cam). I also named that Teleport feed "Face Cam" so that for testing I didn't need to change the receiver.

In this test I found that the VLC source didn't have this issue and figured it's specific to the video capture source (and then tried the video capture specific options and found out about the Color Range issue). So everything good up to this point, the test served its purpose. But you can guess what comes next...

I forgot to remove this "Face Cam" teleport filter again after my testing, so from this point on I always had two "Face Cam" Teleport filters, one on the VLC source and one on the actual face cam video capture source. These two conflicting each other is what caused all of this random behavior. As soon as I removed the filter on the VLC source the issue went away and never came back.

Sorry for wasting your time with this! 😞

[fzwoch]

That explains it :)

I wonder if such behaviour can actually occur though. I feel like I have seen a similar behaviour on macOS. But usually on first start only after a fresh install or upgrade of the plugin. I never investigated the cause as it usually only happens once and then is okay.