Re: [FFmpeg-devel] How to implement pcap ffmpeg format?

From: Devin Heitmueller <devin.heitmueller@ltnglobal.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Gijs Peskens <gijs@peskens.net>
Subject: Re: [FFmpeg-devel] How to implement pcap ffmpeg format?
Date: Wed, 22 Feb 2023 08:51:56 -0500
Message-ID: <CAHGibzFqopFTGogYiGUccaj7-t7cVvuZNPrEOYqv8OCMTAAs2w@mail.gmail.com> (raw)
In-Reply-To: <57B02A18-17B3-4BA8-A4AF-E7BA00289E54@remlab.net>

On Wed, Feb 22, 2023 at 7:54 AM Rémi Denis-Courmont <remi@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.heitmueller@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-request@ffmpeg.org with subject "unsubscribe".