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

[sonntex]

So, if I have an rtp stream inside my application and want to save it
somehow to a playable media container, I have to wrap this stream to
something that could be transferred by pipe to ffmpeg, for instance to ivf
or to h264 byte stream. The first format requires deep codec parsing to
extract at least width and height, perhaps other properties. Seems easy but
non-unified. Another approach is to pass the stream to a local udp socket,
simultaneously execute and control the ffmpeg process. It could lead to
data loss and requires socket coding in such a simple application.

I understand why ffmpeg developers don't want to include pcap support to
ffmpeg but it could be implemented as an external code by somebody else for
whom it seems to be useful. I can't really find any blockers to do that
except that all the code inside rtpdec is encapsulated in its *.c file and
is not accessible from a hypothetical new pcap format. What I found is that
udp.c derives url protocol interface and does the same as pcap format
should do - extract rtp packets from a source and pass it further to
rtpdec. The problem is that pcap format is a format, not a protocol, which
reads data from ffmpeg file protocol. And the question was how to build the
chain of <file protocol> -> <input pcap format> -> <input rtp format>?

On Wed, Feb 22, 2023 at 12:54 PM Rémi Denis-Courmont <remi at remlab.net>
wrote:

> Hi,
>
> 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.
>
> Note: Unfortunately, earlier attempts to standardise a container for
> RTP/RTCP packets have failed.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>