On Wed, Feb 22, 2023 at 7:54 AM Rémi Denis-Courmont <r...@remlab.net> wrote: > I agree with Kieran that this doesn't look like it belongs in FFmpeg or in > any media framework. In fact, Wireshark has some support for extracting media > from RTP, and that seems like the right place for it. > > With that said, you can't realistically pass RTP packets on the standard > input. RTP is datagram-based. Packet boundaries are relevant; it can't go > over a pipe. Unless you use a Unix datagram socket as standard input, but > that would be very weird. > > Besides, there may be multiple streams on different ports, with different > payload maps, and the receiver needs to know which port which packet came on.
I generally use tcpreplay for this sort of use case (it replays pcap files back onto the network and then ffmpeg can receive them). It would support the use case with multiple streams. The timing isn't perfect though, so if you play files that are many Mbps you might find the stream is being played out +/- 1% of realtime, which can have some annoying effects with certain applications. Also its important to note that this does mean streams can't be processed faster than realtime (i.e. you can't process five minutes of RTP packets in a few seconds). One other thing worth noting is there can be some unexpected side-effects of tcpreplay that require you to rewrite MAC addresses if playing back on a different host than captured on, and rewriting UDP checksums if the NIC is doing hardware offloading. As a result I typically have to preprocess my pcap files (using tcprewrite) prior to playing them back out. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
