[FFmpeg-devel] [PATCH v2 1/1] avformat: Add IPFS protocol support.
Timo Rothenpieler
timo at rothenpieler.org
Wed Feb 2 02:39:56 EET 2022
On 02.02.2022 01:33, Mark Gaiser wrote:
> On Wed, Feb 2, 2022 at 1:27 AM Timo Rothenpieler <timo at rothenpieler.org>
> wrote:
>
>> On 01.02.2022 22:58, Mark Gaiser wrote:
>>> +static int translate_ipfs_to_http(URLContext *h, const char *uri, int
>> flags, AVDictionary **options)
>>> +{
>>> + const char *ipfs_cid;
>>> + const char *protocol_path_suffix = "ipfs/";
>>> + char *fulluri;
>>> + int ret;
>>> + Context *c = h->priv_data;
>>> + int is_ipfs = (av_strstart(uri, "ipfs://", &ipfs_cid) ||
>> av_strstart(uri, "ipfs:", &ipfs_cid));
>>> + int is_ipns = (av_strstart(uri, "ipns://", &ipfs_cid) ||
>> av_strstart(uri, "ipns:", &ipfs_cid));
>>
>> What's the point of this logic?
>> The first half of each check seems pointless, since the second half is
>> true for everything the first one would cover.
>>
>
> Hi Time,
>
> The point it to allow
> ipfs://<cid> and ipfs:<cid>
>
> So for that i want to test for all possible true situations (ipfs://,
> ipfs:, ipns:// and ipns:).
If the url starts with "ipns://", it obviously also starts with "ipns:",
so checking for the longer of the two is pointless.
Same for "ipfs:".
> This is akin to other protocols who seem to do the same check. Look at
> crypto.c for example.
> Another point is further down where the url is composed.
> If it's ipfs it becomes a url like <gateway>/ipfs
> And for ipns: <gateway>/ipns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4494 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220202/de248a98/attachment.bin>
More information about the ffmpeg-devel
mailing list