Bug Report OBS 14.1 rtsp/udp source broken?

[Fenarinarsa]

Hello and first of all thanks for OBS :)

I was waiting for OBS 14 to be released because I need the deinterlace feature and I saw in the repository that it would be available with this release.

I have a small project to use OBS as a monitoring tool for various streams. They're broadcast streams so it's H264 TS streams in rtsp and udp (multicast).

so there are two ffmpeg network sources which are like:
rtsp://192.168.0.1/fbxtv_pub/stream?namespace=1&service=658&flavour=hd
and
udp://239.x.x.x:1234

In OBS 13.4 they show just fine. But in 14.1 they look completely botched up. I tried to make audio/video buffers larger in the source settings but it doesn't fix them - see the attached screenshots.
Maybe something related to the added deinterlaced filter? (note: I didn't activate deinterlacing) or maybe a change in ffmpeg?

I know this may not really be a top-priority feature but if there's a quick fix I'd be interested to know it (even if I need to get the sources to patch and build OBS).

 

[Lain]

Is there any way I can set this up to replicate? How can I set this up? I'll try to fix it if I can.

 

[Fenarinarsa]

Okay I found a way to replicate this.

Download http://www.nolife-server.fr/files/obsbug/test.ts
(it's a dump of our IP encoder)

To stream it you can use VLC:
Media > Stream (Ctrl-S)
Add test.ts to the file selection
Click on Stream
Click Next
Choose "UDP (legacy)", click on Add
Enter a multicast address, for instance 239.5.5.5 port 1234
Click Next, disable transcoding
Click Next, enable "stream all elementary streams"
Click Stream

In OBS, add a Media Source with input = udp://@239.5.5.5:1234
Frame Dropping Level = None

Now it should work in OBS 13.4 but not in OBS 14.1, provided you don't have a firewall blocking multicast. You might wait a few seconds (=a keyframe) for the stream to appear in OBS.

Note that if you have a router/OS that does not do IGMP snooping the multicast stream will feed all your LAN and some wifi AP don't like it.

 

[Lain]

When you say "enter a multicast address" -- what do you mean?

 

[Fenarinarsa]

In VLC when you choose "udp (legacy)", it asks for an IP and a port. In my example I use a multicast address because there is no proxy server waiting for a connection. You can use my example (239.5.5.5:1234), it should work.


Note that multicast is not related to this bug because I have the issue with a multicast udp stream and with a unicast rtsp (tcp) stream all the same. It's just that it is convenient to use multicast to give you a way to reproduce it.


long version:

When you start an UDP broadcast you can stream as usual in unicast (source IP -> destination IP). Unicast is actually the only way to send TCP packets because it's a connected protocol. But UDP is not.

You can also send a multicast stream. It means that your IP packets will be tagged with a "virtual" IP address called multicast address and basically, they will be broadcast all over the network without filtering until you reach a router that doesn't forward multicast packets (by default they don't). Multicast packets are by default not routed across the internet so it's mainly of use on a LAN.
So that's why you enter a multicast address in VLC when using UDP streaming: it will then broadcast the stream all over your LAN.
On the receiving side, when you run ffmpeg or any other software like VLC or OBS, by using udp://@<multicastIP>:<port>, it will listen for the IP packets tagged with this specific multicast IP. But the sender will never be aware of it unless you use some control protol like rtp.

Multicast is often used in the broadcast world and video datacenters because it's a very convenient way of making streams available on a LAN without setting up proxy servers. The other advantage is that multicast packets are duplicated by switches and routers, so basically the sender will only generate 1 stream even if you have a zillion clients receiving it. It's used a lot for consumers that subscribe to IPTV networks (multicast streams are then sent through a VLAN to avoid the "non-routable on the internet" issue). The drawback is that if packets are lost on the receiving side, there's no way to recover them.
And I lied, the packets are actually not broadcast over the whole LAN, switches implement a control protocol named IGMP which is used to know if an interface starts listening to a multicast IP to avoid sending packets to clients that do not need them.

Multicast addresses in IPv4 are all adresses between 224.0.0.0 and 239.255.255.255
https://en.wikipedia.org/wiki/Multicast_address

 

[Lain]

Ah okay, so that's my lack of network knowledge showing there. Thanks, will get back to you.

 

[R1CH]

I've reproduced this, but this is somewhat expected behavior when using UDP at high bitrates. If applications don't consume the data fast enough, you will lose frames on the socket buffers. I'm not entirely sure why it worked in earlier versions - perhaps ffmpeg was quicker in responding to network events or something.

The fix is to specify a large buffer size (https://ffmpeg.org/ffmpeg-protocols.html#udp) so that the frames don't get dropped. I was able to view your test file successfully using udp://@239.5.5.5:1234?buffer_size=8000000

 

[Fenarinarsa]

Thanks R1CH, it's actually better, the udp stream is now 99% correct (stil some frame drops though). But the issue is still the same with the rtsp (TCP) 3Mbps stream (right picture on the screencaps I sent). Unfortunately I don't have a setup to reproduce it :(

 

[lentrody]

I have same problem in OBS 25.0.8.