On Wed, Feb 2, 2022 at 1:33 AM Mark Gaiser <mark...@gmail.com> wrote:
> 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, > oops. Timo obviously. Sorry for the typo in your name. > > 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".