Opened 4 years ago

Last modified 2 years ago

#4155 reopened defect

UDP Output is Waving

Reported by: smallishzulu Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: udp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.)

Attachments (2)

udp.png (63.4 KB) - added by smallishzulu 4 years ago.
UDP Stream outputs of same TS file with same FFmpeg command.
underflow_overflow_fix.diff (3.7 KB) - added by rycius 2 years ago.

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by smallishzulu

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

comment:1 Changed 3 years ago by zcybercomputing

  • Version changed from unspecified to git-master

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.

comment:2 Changed 3 years ago by kierank

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:3 Changed 3 years ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Keywords udp added
  • Resolution changed from wontfix to invalid

wontfix would indicate that there is a bug.

comment:4 Changed 3 years ago by zcybercomputing

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.

Last edited 3 years ago by zcybercomputing (previous) (diff)

comment:5 Changed 3 years ago by zcybercomputing

  • Component changed from undetermined to ffmpeg
  • Reproduced by developer set
  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:6 Changed 3 years ago by cehoyos

  • Reproduced by developer unset

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

comment:7 follow-up: Changed 2 years ago by 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.

comment:8 Changed 2 years ago by cehoyos

  • Component changed from ffmpeg to avformat
  • Resolution set to fixed
  • Status changed from reopened to closed

comment:9 in reply to: ↑ 7 Changed 2 years ago by rycius

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

Changed 2 years ago by rycius

Note: See TracTickets for help on using tickets.