Ingest TCP mpeg-ts from ffmpeg / OBS

Wowza Streaming Engine
1

I am working on some tests to ingest multiple audio tracks with UDP / Mpegts via OBS and ffmpeg output. This was successful to a local wowza and have HLS switching muliple audio tracks. However, the streaming UDP , even over the LAN I am getting blocky picture and unstable output to HLS.

I am trying temporary real world tests before SRT support is available in OBS.

I’ve not managed to get the remote wowza ingesting the UDP stream via ffmpeg. Only my SRT tests with gstreamer remotely was successful.

Do I need to use TCP mpeg-ts output. And if so how is it possible for a Wowza stream file to target and ingest mpeg-ts tcp ?

I’ve tried this with a local wowza server with no success.

ffmpeg -re -i sintel_lang_2000k.mp4 -codec copy -bsf:v h264_mp4toannexb -map 0 -streamid 0:50 -streamid 1:52 -streamid 2:53 -streamid 3:54 -streamid 4:55 -streamid 5:56 -f mpegts tcp://192.168.4.43:10000?pkt_size=1316

2

If you are using UDP on your local LAN then this may be a problem with your network hardware (unlikely) or a problem with your live stream delivering packets out of order. This can also happen if the encoding computer’s CPU is overloaded. Enabling a jitter buffer may solve the problem with a blocky picture.
https://www.wowza.com/docs/how-to-turn-on-an-rtp-jitter-buffer-and-packet-loss-logging-rtp-and-mpeg-ts

We have an article on how to deliver live content to Wowza Streaming Engine using FFmpeg. I have linked to the TCP based MPEG-TS delivery method.
https://www.wowza.com/docs/how-to-restream-using-ffmpeg-with-wowza-streaming-engine#tcp

As you are specifying that you are using MPEG-TS the “-bsf:v h264_mp4toannexb” portion is redundant.
https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmp4toannexb

3

I’m trying to test a remote UDP push via OBS / Ffmpeg. I can see the udp packets on the server but its not ingesting and playing back correctly for now. Which is why I wanted to try a TCP test. Thanks.

4

I don’t quite get what the stream uri ip is supposed to be for mpegtstcp? I need to set a shared port for multiple stream files to selection different audio PID’s.

5
  1. mpegts tcp with wowza does not support multiple audio tracks unlike udp.

Note also that mpegts tcp works in wowza in PULL not PUSH (unfortunately the doc does not spell it explicitly and I had to post a ticket to retrieve that info):

the encoder does not push the data to wowza; but rather wowza pulls from the encoder.

This means that you have to setup ffmpeg in tcp listener (aka server) mode with option --listen 1

(check ffmpeg doc for tcp protocol).

This won’t work with obs-studio since it can’t operate as a listener.

  1. As to your woes with udp, I’ve used mpegts udp with multiple audio tracks to remote wowza server though one has to accept packet loss and pixellated images; you probably have some firewall/network issues.

  2. even if you get srt support in obs-studio (there is indeed a Pull Request on github), you won’t be able to stream to wowza with multiple audio tracks because wowza does not support as yet srt with multiple audio. I’ve used instead nimble streamer, which is unfortunate because I prefer wowza. I’ve posted a feature request in Suggestions section of this forum. Feel free to voice support for this feature.

6

My extensive tests with SRT ingest via ffmpeg test. I swear I had it working , as HLS was delivering both audio tracks. Suddently SRT ingest won’t share ports. Only one stream file is active. It was in fact ingesting the audio PID for the second track. Starts at 256 for video. So PID of 258 was being ingested fine and packetizing. Now nothing !

I’ll investigate UDP tests again my connection upload is pretty bad so need an external connecting for publishing.

7

Thank you for posting a potential solution and contributing to the community @kv pham.

8

I’ll keep it UDP testing. I am certain 100% I had SRT ingesting language audio PID’s. But all of a sudden the stream files won’t share the port. I have a ticket