Marten, Thanks for the reply. I am currently only copying to eliminate all other settings within my FFMPEG command string as a possible cause. The intent is to transcode, which I can already do from other servers to the receiver here, but I have to resolve this first. Using socat will not help me here.
I had already verified the input side is not dropping packets with debugging in FFMPEG. I had done this with one source stream previously but since you brought it up, this time I decided to pull 15 and they all came in without errors. I did not need buffer adjustments for this. My debug command : ffmpeg -v debug -i udp://@239.1.1.92:59092 -f null /dev/null As far as the output goes, we are regularly using VBR streams in UDP multicast transport and the hd ones can jump from 8000K to 18000K but we do not see this issue. When I started working on this I was setting the bitrate to 3500K cbr and transcoding to h264 and the issue persisted. From a transmit and capture perspective they seem to be staying around speed=1.01x so I think I am good there. Thanks, -James -----Original Message----- From: ffmpeg-user <ffmpeg-user-boun...@ffmpeg.org> On Behalf Of Marton Balint Sent: Tuesday, November 12, 2019 2:23 PM To: FFmpeg user questions <ffmpeg-user@ffmpeg.org> Subject: Re: [FFmpeg-user] Continuity issues with multiple UDP output streams. On Tue, 12 Nov 2019, James E. Baird wrote: > To add to this, I did some further testing and it would seem the lower > the bitrate I make the streams from the transmitter, the more streams > I can have without continuity errors on the receiver side. I did a > resolution change from 1080p to 480p and dropped the bitrate on my > streams from 12000-14000K to 1500K (mpeg2 to mpeg2) and I could add 7 > processes before I started seeing the streams having issues. > > Using this command: > ffmpeg -i 'udp://@237.1.1.92:59092' -s 864x486 -b:v 1000000 -acodec copy -f > mpegts 'udp://@237.129.100.2:59002?pkt_size=1316' > > Not sure if this helps anyone have a eureka moment. If you are only copying streams, then I suggest you use another tool, like socat to relay streams. Not that you can't make ffmpeg work to some degree. First you have to make sure you are not dropping packets on the input side. I suggest you use 0 as fifo size and 512000 as buffer size (see the docs for these options). In order to be able to set this you have to tune linux kernel parameters (net.core.rmem_max) as well. Then you have to make sure your output is not bursting too much. You should limit the output bitrate using the bitrate option. Make sure your processes can still operate at realtime speed, otherwise packets will queue up or get dropped. Even if you do this, depending on your receiver device it might still not work, because ffmpeg mpegts muxer does not honor TS buffering requirements, so the generated TS will not be standard compliant. Regards, Marton CONFIDENTIALITY NOTICE: This e-mail including attachments is covered by the Electronic Communications Privacy Act, 18 U.S.C. ยงยง2510-2521, is confidential and may contain information that is privileged, confidential or otherwise protected from use and disclosure. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, or dissemination of this transmission, or taking of any action in reliance on its contents, or other use is strictly prohibited. If you have received this transmission in error, please reply to the sender listed above immediately and permanently delete this message from your inbox. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
