On Wed, Feb 2, 2022 at 1:27 AM Timo Rothenpieler <t...@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:).
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
>
> _______________________________________________
> 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".
