Re: [FFmpeg-devel] What is FFmpeg and what should it be - Rémi Denis-Courmont

From: "Rémi Denis-Courmont" <remi@remlab.net>
To: FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>,
	Andrey Turkin <andrey.turkin@gmail.com>
Subject: Re: [FFmpeg-devel] What is FFmpeg and what should it be
Date: Tue, 01 Aug 2023 14:48:29 +0700
Message-ID: <C09F81FE-505A-4961-A22A-3F9263935717@remlab.net> (raw)
In-Reply-To: <CAA7-ZoquufTyNCc5sZxBinXCNa6v3LCbc6+TWsDYoHs7LriR4Q@mail.gmail.com>

Le 31 juillet 2023 00:07:37 GMT+07:00, Andrey Turkin <andrey.turkin@gmail.com> a écrit :
>вс, 30 июл. 2023 г. в 16:04, Nicolas George <george@nsup.org>:
>
>> Kieran Kunhya (12023-07-28):
>> > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
>> > WiFi protocol etc etc. Different layers are delegated to different
>> > programs.
>>
>
>There is a good reason to have some part of TCP implemented in FFmpeg
>though.

No because :

> It would be _extremely_ useful to be able to read and replay pcap
>dumps of an RTP stream,

That's UDP, and it wouldn't work anyhow. You need to map MAC addresses, IP addresses and port numbers, and (in the general case) you need the original SDP. You can't get that straight out of a packet capture.

There are proprietary formats to record RTP flows (since IETF steadfastly refused to standardise anything), and they're not normally going all the way to the link layer as a packet capture does.

> Or an HLS or DASH stream, or whichever else
>multi-connection streams are there.

That's even worse. You don't want to implement it in FFmpeg because you'd want to reproduce the behaviour of the original TCP/IP stack, not the different behaviour of whatever TCP reassembly code FFmpeg would have. And realistically, you can't replay duplex packet flows anyway: you'd quickly get critical inconsistencies between how FFmpeg reacts and how the recorded client application reacted (be it an old version of FFmpeg or not).

There are tools to replay packet captures. And however imperfect they may intrinsically be, they are better than whatever FFmpeg could hope to achieve. Also they don't require duplicating existing code, for a very fringe use case.

>There is also at least one demodulator already in FFmpeg, namely VBI bit
>slicer (it is implemented through an external library though).
>_______________________________________________
>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".
_______________________________________________
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".