Re: [FFmpeg-devel] [PATCH v2 1/1] avformat: Add IPFS protocol support.

[Timo Rothenpieler <timo@rothenpieler.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1390 bytes --]

On 02.02.2022 01:33, Mark Gaiser wrote:
> On Wed, Feb 2, 2022 at 1:27 AM Timo Rothenpieler <timo@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


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4494 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".