From patchwork Wed Feb 16 22:35:11 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Gaiser X-Patchwork-Id: 34346 Delivered-To: ffmpegpatchwork2@gmail.com Received: by 2002:a05:6838:d078:0:0:0:0 with SMTP id x24csp114434nkx; Wed, 16 Feb 2022 14:36:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJy8SYwzSw5ZhBPvJqI81TlGfIPyixfYWnWcT97YZhYPJ6zyYRMFqd0iSYyZY7tin+1v5fQw X-Received: by 2002:a17:906:38d2:b0:6b7:9639:fd74 with SMTP id r18-20020a17090638d200b006b79639fd74mr124381ejd.215.1645051016709; Wed, 16 Feb 2022 14:36:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645051016; cv=none; d=google.com; s=arc-20160816; b=U1Y8LKWmhJduH0PfOHRPT3/ebgsfTyJFXoOze3puXUwj6AoWuBjavxnAlNFS9yCjRJ 1hlkgARKucjl14bETFZ4r0nDApat8Wgc2KKbX6Rsc9E3TixbDyqYcjB4Hlt6BjpCLXbx IYItd8UmKcgiYq1MlwuT1g1To6eh/IaQ1kGcog+bvUxMqEGQUl2hGrdHpVZB7Mkxnbg8 wqi0tv41lqPFqDiDRwjuermlv4jfjimQV7LldauxAM4Fpsv9SsBUTZ8osCd4NlPBT6cO rMaAQj6GmU1l4I2K2J7vEKIFFrorWafsy+HgZriX1lVTJTpVdhJGwSzlT+uFQd5DX9zw A1rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:cc:reply-to :list-subscribe:list-help:list-post:list-archive:list-unsubscribe :list-id:precedence:subject:mime-version:message-id:date:to:from :dkim-signature:delivered-to; bh=wAc4ywf9je+sFAUbWwZhUsdd2NbbdM0r8Xqo2cANMPw=; b=s2nrKgn+FLvcSxVOnkNdH6LentCggjPKJ7Cs0xo315EM17y3tYiePvnK+r8GPAoeXX 3VXhxXKjK2wDwZ+kEapicvGm2AY1Jt56HPSHmiXmXtXyq/XRVvvL8g162wkHJngG6IFF rOsY7gleOLR/Yx27OYrb39D05qP8Ptp9u+jiSTfF9f0oozA/xDGewrzvBrsJPVEynnOV ifRxiHnTTCcXhR/eoDd7JI2L1JIdU82gVKzlEbbV0Dmy96j+nPMsK1smSGTkLqVlMAqX 9enKCIWxwAGkIie0Sxr9FL6OZ+HXe9f8GmwkIwNT1eTXZZmbMIze+B2a4Hu67cPIG+e1 /XSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20210112 header.b=gP4PGqA2; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id d1si2733000edo.398.2022.02.16.14.36.55; Wed, 16 Feb 2022 14:36:56 -0800 (PST) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20210112 header.b=gP4PGqA2; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D75D968B199; Thu, 17 Feb 2022 00:36:51 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6458A68B050 for ; Thu, 17 Feb 2022 00:36:45 +0200 (EET) Received: by mail-ej1-f49.google.com with SMTP id d10so2497968eje.10 for ; Wed, 16 Feb 2022 14:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=X4vUCvZIReWzcFXSUyiNrUYo04rnZxM+NfV1ThPLuK4=; b=gP4PGqA2JfZ8QV0sPwErlOc8xTZUq0AXxENjuKGjhDZ/t8hmyq4gZmE8SuczTzfOM1 tqewwy4lrt5LjAPpuR381StfoFYsavLo7Zs+B+i+Aoi0ecRwbjWnGQu53JtQZed1QeyB xJ3hIfiTZJjtaYSYQY8edEBoozSv4iedch3yiiAFPIH7avqQFtMDMeA/41uCb75wUvoN VrKYuxcjTKjhNYAZgl/X/ZOfXjvqaj5YiAwlShIwFaemiMQJSad2YcBjJy97lkp4rEKs FdSylGFq/rc96vBo7QkSoUI9PrwxHNDtkxZ99tlL9xznrdVtwHmSyQqGKXLAD9R4Pjpi X/Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=X4vUCvZIReWzcFXSUyiNrUYo04rnZxM+NfV1ThPLuK4=; b=MlqlRT/p71q/iFY96B8z2Enb9y2WcPU/UB5voYQyQIzaNilHp6xrtwx23wNCeYDfHi KWX72yTaof11Ogr9yxGkJni72H2PcF5KzkkayYFmQxeYTWsFYktneshBwR+1wOIanUqF dsVZrk2Hav5h1D76ZqOr7VbVW0BDeAg9UELNNtaAUcc6inrA29v5XXJudknsnWX6ML2z UJ3uhVguFIsSNRvJWrSRNk3zq76x6E/rAVb+Oj0+vne0ymN3UiEgrhi7A+jiLt78vzhD 9GWCy0CFrgROyMZ8bQoQYFOAeEopKk0kTbhm0XIOVOanHzy7ip9pyExvmvDBv16MhYyb vYSw== X-Gm-Message-State: AOAM531n38RbwvC523cb+EAi37RK79+W72w7guP2Q6rqrrn3LvVnBwyY ObIG+n4oxmep8Tt/FbsofzT+m56QQ9X/wQ== X-Received: by 2002:a17:906:3ad1:b0:6ce:a880:7745 with SMTP id z17-20020a1709063ad100b006cea8807745mr157739ejd.46.1645051004206; Wed, 16 Feb 2022 14:36:44 -0800 (PST) Received: from localhost.localdomain (ip60-253-211-87.adsl2.static.versatel.nl. [87.211.253.60]) by smtp.gmail.com with ESMTPSA id x12sm2292636edv.57.2022.02.16.14.36.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 14:36:43 -0800 (PST) From: Mark Gaiser To: ffmpeg-devel@ffmpeg.org Date: Wed, 16 Feb 2022 23:35:11 +0100 Message-Id: <20220216223512.122043-1-markg85@gmail.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH v7 0/1] Add IPFS protocol support. X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: Mark Gaiser Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" X-TUID: 1mJP92ZKQKAy Hi, This patch series adds support for IPFS. V7: - Removed sanitize_ipfs_gateway. Only the http/https check stayed and that's now in translate_ipfs_to_http. - Added a check for ipfs_cid. It's only to show an error is someone happens to profide `ffplay ipfs://` without a cid. - All snprintf usages are now checked. - Adding a / to a gateway if it didn't end with it is now done in the same line that composes the full resulting url. - And a couple more minor things. V6: - Moved the gateway buffer (now called gateway_buffer) to IPFSGatewayContext - Changed nearly all PATH_MAX uses to sizeof(...) uses for future flexibility - The rest is relatively minor feedback changes V5: - "c->gateway" is now not modified anymore - Moved most variables to the stack - Even more strict checks with the auto detection logic - Errors are now AVERROR :) - Added more logging and changed some debug ones to info ones as they are valuable to aid debugging as a user when something goes wrong. V3 (V4): - V4: title issue from V3.. - A lot of style changes - Made url checks a lot more strict - av_asprintf leak fixes - So many changes that a diff to v2 is again not sensible. V2: - Squashed and changed so much that a diff to v1 was not sensible. The following is a short summary. In the IPFS ecosystem you access it's content by a "Content IDentifier" (CID). This CID is, in simplified terms, a hash of the content. IPFS itself is a distributed network where any user can run a node to be part of the network and access files by their CID. If any reachable node within that network has the CID, you can get it. IPFS (as a technology) has two protocols, ipfs and ipns. The ipfs protocol is the immutable way to access content. The ipns protocol is a mutable layer on top of it. It's essentially a new CID that points to a ipfs CID. This "pointer" if you will can be changed to point to something else. Much more information on how this technology works can be found here [1]. This patch series allows to interact natively with IPFS. That means being able to access files like: - ffplay ipfs:// - ffplay ipns:// There are multiple ways to access files on the IPFS network. This patch series uses the gateway driven way. An IPFS node - by default - exposes a local gateway (say http://localhost:8080) which is then used to get content from IPFS. The gateway functionality on the IPFS side contains optimizations to be as ideal to streaming data as it can be. Optimizations that the http protocol in ffmpeg also has and are thus reused for free in this approach. A note on other "more appropiate" ways, as I received some feedback on that. For ffmpeg purposes the gateway approach is ideal! There is a "libipfs" but that would spin up an ipfs node with the overhead of: - bootstrapping - connecting to nodes - finding other nodes to connect too - finally finding your file This alternative approach could take minutes before a file is played. The gateway approach immediately connects to an already running node thus gives the file the fastest. Much of the logic in this patch series is to find that gateway and essentially rewrite: "ipfs://" to: "http://localhost:8080/ipfs/" Once that's found it's forwared to the protocol handler where eventually the http protocol is going to handle it. Note that it could also be https. There's enough flexibility in the implementation to allow the user to provide a gateway. There are also public https gateways which can be used just as well. After this patch is accepted, I'll work on getting IPFS supported in: - mpv (requires this ffmpeg patch) - vlc (prefers this patch but can be made to work without this patch) - kodi (requires this ffmpeg patch) Best regards, Mark Gaiser [1] https://docs.ipfs.io/concepts/ Mark Gaiser (1): avformat: Add IPFS protocol support. configure | 2 + doc/protocols.texi | 30 ++++ libavformat/Makefile | 2 + libavformat/ipfsgateway.c | 312 ++++++++++++++++++++++++++++++++++++++ libavformat/protocols.c | 2 + 5 files changed, 348 insertions(+) create mode 100644 libavformat/ipfsgateway.c