To convert an RTSP stream to MPEG-TS with constant UDP packets, use the -mpegts_packet_size flag to enforce 188-byte Transport Stream packets and pipe the output to a UDP muxer. This ensures every TS packet is fixed size, while the underlying UDP datagram size depends on your network MTU and whether you enable fragmentation or rely on the OS stack.
Understanding MPEG-TS Packet Structure
The core requirement for many industrial streaming protocols and legacy receivers is that the Transport Stream (TS) payload consists of fixed-size blocks. Standard MPEG-TS uses a packet size of 188 bytes. When FFmpeg processes an RTSP source, it demuxes the incoming video and audio streams, then remuxes them into this specific container format. The-mpegts_packet_size option in FFmpeg controls the size of these individual TS packets. If you set this to 188, FFmpeg will pad or split PES packets to ensure each TS unit is exactly 188 bytes. This is critical for hardware decoders that expect strict alignment and do not handle variable-length framing gracefully. It does not, however, dictate the size of the UDP datagrams sent over the network. The distinction between the logical TS packet and the physical UDP payload is where many users encounter buffering issues or packet loss.
Constructing the Command Line
To achieve the desired output, you must chain the input handling, the TS formatting options, and the UDP output muxer correctly. Below is a robust command structure that addresses common pitfalls regarding packetization.ffmpeg -i rtsp://username:password@ip_address/stream \
-fflags +genpts \
-an \
-vcodec copy \
-acodec copy \
-mpegts_packet_size 188 \
-f mpegts udp://destination_ip:port?pkt_size=1472-fflags +genpts is often necessary when dealing with RTSP streams because some cameras do not provide accurate Presentation Timestamps (PTS). Without generating PTS manually, downstream players may exhibit synchronization errors or freeze. The -an flag disables audio if you are only interested in video, reducing bandwidth and processing load. The -vcodec copy and -acodec copy flags instruct FFmpeg to stream the raw data without re-encoding, which preserves quality and minimizes CPU usage.
The crucial part is -mpegts_packet_size 188. This forces the muxer to create standard 188-byte TS packets. Finally, the output target is the UDP protocol. The query parameter ?pkt_size=1472 in the URL tells the UDP socket what maximum payload size to attempt per datagram. Note that this value is typically calculated as the Network MTU minus the IP header (20 bytes), UDP header (8 bytes), and optional overhead. A common MTU is 1500 bytes, leading to a payload limit of 1472 bytes. Since one TS packet is 188 bytes, approximately seven TS packets fit into a single UDP datagram (7 * 188 = 1316 bytes). This leaves room for headers and prevents fragmentation at the IP layer, which can cause significant jitter in real-time streams.
For more details on troubleshooting why your recorded stream might not play back correctly due to similar packetization issues, see our guide on [Troubleshooting FFmpeg-Recorded RTSP Video Stream Not Displayed in VLC Media Player](/news/1090329/ffmpeg-rtsp-video-stream-not-displayed-in-vlc).
Handling Audio and Synchronization
If you need to include audio, remove the-an flag. However, be aware that adding audio increases the bit rate and may require adjusting the pkt_size calculation if you hit the MTU limit. You should also consider using -f mpegts explicitly before the output URL to ensure the muxer is selected, although FFmpeg often infers this from the extension or the -mpegts_packet_size flag.
Another important consideration is the keep-alive mechanism. RTSP sessions can timeout if no data flows for a certain period. While FFmpeg handles basic session management, aggressive firewalls or NAT devices might drop the connection. For insights on maintaining stable connections with IP cameras, refer to [FFMPEG: RTSP Clients Sending 'KeepAlive' Packets to IP Cameras](/news/1232763/ffmpeg-keepalive-packets-for-ip-cameras).
Network Configuration and MTU
The success of constant-size UDP streaming relies heavily on network configuration. If the UDP datagram exceeds the Path MTU, routers will fragment the packets. Fragmentation is dangerous for real-time media because the loss of a single fragment destroys the entire datagram, resulting in visible artifacts or complete frame drops. Therefore, settingpkt_size to a value below the minimum MTU along the path is best practice.
You can test the effective MTU by pinging the destination with the -f (do not fragment) flag and adjusting the packet size. Once you identify the maximum non-fragmented size, subtract 28 bytes (IP + UDP headers) to get your pkt_size value. If you are streaming multicast, ensure your network switches are configured to support IGMP snooping and appropriate TTL values. See [Creating MPEG-TS Multicast Streams with ffmpeg](/news/1290171/ffmpeg-mpeg-ts-multicast-stream-command) for specifics on multicast routing.
Debugging Common Issues
Even with correct commands, you may encounter issues such as black screens or stuttering. First, verify that the codec parameters are being passed correctly. If FFmpeg cannot find the codec parameters, it may fail to decode the input properly. Check the logs for errors like "Could not find codec parameters." This often happens with proprietary camera codecs. In such cases, you may need to specify the codec explicitly or use a different container format temporarily to inspect the stream. Secondly, monitor the CPU and network utilization. Copy mode (-vcodec copy) should have minimal CPU impact. If CPU usage spikes, you might be inadvertently triggering re-encoding. Use tools like top or htop to monitor the FFmpeg process. On the network side, use tcpdump or Wireshark to inspect the outgoing UDP packets. Ensure they are indeed 188-byte aligned TS packets and that the UDP payload size matches your expectation. If you see large variations in packet sizes, your pkt_size setting or network MTU is misconfigured.
For related issues regarding H.264 streaming specifically, check out [FFmpeg RTSP H264 Streaming Issue: Couldn't Find Codec Parameters](/news/1407011/ffmpeg-h264-streaming-issue).
Frequently Asked Questions
Does -mpegts_packet_size change the UDP datagram size?
No, it only sets the size of the internal Transport Stream packets, typically to 188 bytes. The actual UDP datagram size is determined by thepkt_size parameter in the output URL and the network MTU. Confusing these two leads to incorrect buffer sizing.
Why are my packets fragmented?
Fragmentation occurs when the total UDP payload exceeds the Path MTU. To prevent this, calculate the maximum payload by subtracting IP and UDP headers (28 bytes) from the smallest MTU in your network path. Set thepkt_size in the UDP URL to this calculated value.
How do I fix timestamp errors in the stream?
Add the-fflags +genpts option to your FFmpeg command. Many RTSP sources from IP cameras lack precise presentation timestamps, causing players to desynchronize or freeze. Generating PTS ensures smooth playback.
Can I stream audio with this configuration?
Yes, but you must remove the-an flag. Be cautious about bandwidth, as adding audio increases the bitrate. You may need to adjust the pkt_size to accommodate the additional data without exceeding the MTU limit.