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 <r...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ 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".
