[FFmpeg-devel] [PATCH 0/5] Add IPFS and IPNS protocol support

[Mark Gaiser]

On Mon, Jan 31, 2022 at 9:23 PM Tomas Härdin <tjoppen at acc.umu.se> wrote:

> mån 2022-01-31 klockan 17:31 +0100 skrev Mark Gaiser:
> > On Mon, Jan 31, 2022 at 4:52 PM Tomas Härdin <tjoppen at acc.umu.se>
> > wrote:
> >
> > > mån 2022-01-31 klockan 14:51 +0100 skrev Mark Gaiser:
> > > >
> > > > 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.
> > >
> > >
> > > Perhaps the protocol should be called something other than just
> > > ipfs if
> > > it doesn't actually implement IPFS. Like ipfsgateway. It could
> > > still be
> > > registered to ipfs:// of course, until someone writes a wrapper for
> > > libipfs.
> > >
> >
> > Do you mean to have it named like "ipfsgateway" as files (and
> > library) but
> > keep the protocol registration of ipfs and ipns?
> > I'm fine with that. The name is only artificial in code anyhow, all
> > that
> > matters are the protocol names.
>
> What I'm really after is if other devs think there might be an issue
> once someone goes an implements proper IPFS support
>

A "proper" implementation is unfeasible for ffmpeg purposes because a
proper implementation would act as an IPFS node.
That means it would:
- spin up
- do it's bootstrapping
- connect to nodes and find new nodes to connect to
- find the CID on the network
- etc...

This all adds a lot of startup time making it very unfriendly to users.
In this scenario it could take up to minutes before your video starts
playing if it doesn't time out.

Rather, the gateway approach uses an already running IPFS instance.
Users are meant to run a local IPFS instance but it doesn't *have* to be
local.
Sure, a user could point it to another local network hosted IPFS node or
some online public gateway.
But the idea is for users to host a node themselves.


>
> It strikes me that this borders on incorporating business logic within
> lavf. A user could achieve the same thing with a small shell script.
> For example adding an alias that inspects calls to ffmpeg and sed:s
> ipfs:// URLs accordingly
>

That might work but isn't really user friendly. It also doesn't help for
tools/applications that incorporate ffmpeg to potentially use IPFS
resources.
KODI (when IPFS is merged into ffmpeg) is one such application where I'll
be adding support for IPFS.
But there are more that could potentially benefit. Think for example of OBS
studio and blender (i haven't been in contact with them, all i know is that
they use ffmpeg).

>
> >
> > Question though. In a V2 patch, would it make sense to squash
> > everything in
> > one commit?
>
> Just look at what other patch series look like. This is small enough
> that a single patch is likely enough yes
>
> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>