UDP Output is Waving

[smallishzulu]

Summary of the bug (not sure if a bug):

I use a valid TS file and use below command:
ffmpeg -re -i test.ts -c:v copy -c:a copy -vb 2500k -minrate 2500k -maxrate 2500k -bufsize 5000k -muxrate 2500k -flush_packets 0 -f mpegts udp://225.2.1.1:1234?pkt_size=1316

FFmpeg version is 2.4.3 (not a nightly git version)

I traceout UDP packets using tcpdump and I see constant UDP traffic output:

11:41:14.306157 IP 172.31.35.47.43299 > 225.2.1.1:1234: UDP, length 1316

There is a Window PC in the network and using Wireshark, I can see Windows PC receives 1472 bytes payload. Also constant.

I replaced Windows PC with a Linux PC and I traceout the traffic and I found also constant receive of UDP packets in 1316 bytes.

However, I monitored the traffic over a Mikrotik router and I watched the network graphic of this UDP packets, they are waiving, not constant.

I removed the Mikrotik router and plugged a Windows PC directly to FFmpeg output server and I traced network traffic using StreamXpert, I see traffic is waiving again.

If I generate a UDP multicast traffic using iperf, i see constant UDP traffic on Mikrotik router.

I dont know why but FFmpeg UDP multicast output is 1316 bytes but there maybe a problem with output timing, which I mean is output is not constantly 2.5Mbps

Please see attached image file. On each run of same command, output graphic slightly varies/changes.

Am I doing something wrong or is there a bug?

(Extra note: If I pipe out same output to an ASI card instead of UDP stream, output Mbps is constant as well.)

[smallishzulu]

UDP Stream outputs of same TS file with same FFmpeg command.

[Zach]

To my knowledge, this problem is not new. It has been around for a while. I can confirm that there is a problem with the UDP packet engine in FFmpeg. FFmpeg has excessive jitter in it's UDP streaming output to the point where hardware decoders can't handle it. My solution was to buffer to disk and have my own program read and send the datagrams via a very tight event loop.

[Kieran Kunhya]

This isn't a bug - use multicat to index the file and play it out smoothly.

[Carl Eugen Hoyos]

wontfix would indicate that there is a bug.

[Zach]

Here is the link to multicat.

​http://www.videolan.org/projects/multicat.html

This program is an external application that doesn't support the same platforms as FFmpeg and is only relevant to ways to fix this bug. This is a bug because it is also present with streams that originate with FFmpeg that shouldn't have to pass through an external program.

[Zach]

Because this issue is also present when FFmpeg encoders originate the stream, I think a fix that involves running through an external program is not valid. My testing shows that the graphs provided with this ticket are accurate in showing excessive jitter in the FFmpeg output stream which is a bug that should be fixed.

[Carl Eugen Hoyos]

Why would this be a bug in ffmpeg und not in libavformat?

[smallishzulu]

This issue is fixed by;

​https://github.com/FFmpeg/FFmpeg/commit/cc16229d914aa0eea827599f9df7716bb2afa36b

If bitrate parameter is set, now FFmpeg produce stable MPEGTS UDP output.
This update should be done on rtp as well. RTP output still waves.

[rycius]

Replying to smallishzulu:

This issue is fixed by;

​https://github.com/FFmpeg/FFmpeg/commit/cc16229d914aa0eea827599f9df7716bb2afa36b

If bitrate parameter is set, now FFmpeg produce stable MPEGTS UDP output.
This update should be done on rtp as well. RTP output still waves.

Issue is fixed until first circular buffer underflow, after that it starts to wave again.
Problem is with timestamps, they must be updated then buffer fillsup again.

Another problem is with circular buffer overflow. In overflow case it simple exits. There must be implemented overrun_nonfatal option for output.

I tried to fix it my self, my fix works well, but i'm not 100% sure that i did everything right.