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

[Mark Gaiser]

On Tue, Feb 1, 2022 at 5:40 PM Tomas Härdin <tjoppen at acc.umu.se> wrote:

> mån 2022-01-31 klockan 23:00 +0100 skrev 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 sounds similar to Tor, except Tor has a much more elegant way of
> dealing with this stuff by just wrapping ffmpeg with torify. It takes
> care of all the IPC stuff with tor.service
>
> > >
> > > 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).
>
> This sounds like business logic that should live in Kodi, OBS and
> Blender respectively. Or better yet, in the operating system itself
> (read: systemd). How does Kodi handle browsing media stored in IPFS in
> this case? Does it not already have to be IPFS aware for this to work
> reasonably well?
>

I don't entirely agree that this logic should live in kodi. I think ffmpeg
should provide the base essentials (which this patch is doing).
Kodi and other applications should then provide an input field or whatever
to potentially say "i know the gateway you need to use, pick this one".
They would then either pass "-gateway <url>" with the setting they deem
correct or by filling in the $IPFS_GATEWAY environment variable.

Kodi currently has no way to play IPFS data.
Unless one goes through the hassle of translating it manually to a gateway
url.

To give you an idea of how it looks. Kodi has so called strm (stream)
files. They can contain an url that can be played.

Without this patch an ipfs file would look like this:
http://localhost:8080/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T

With this patch it becomes possible to patch kodi to accept:
ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T

In the former case it's gateway specific. In the latter case it's gateway
agnostic.

The gateway specific way has a problem. If i translate it to a gateway then
that url i picked becomes the point to access the file.
If that url goes down, the file isn't playable. Even if the file might
still be online just fine on the IPFS network.
Imagine you get a file from me and have ipfs running locally. I'm guessing
you don't like to edit the file you received to fix the gateway part of the
url, do you? I certainly don't.

The idea here is that a user sets the gateway that needs to be used to
play. The ideal place to do that is ffmpeg because the gateway logic can
then be in one application. Others (kodi, vlc, ...) can either rely on
ffmpeg doing the right thing or overrule the gateway with their own
setting. In either case, ffmpeg needs the option to set the gateway. This
all changes if the logic can't go in ffmpeg. Then each application gets its
own configuration to set the ipfs gateway. That's a situation I actively
try to prevent because it makes accessing files on ipfs just more
complicated then need be.

Also, please forget the systemd and linux specifics here. ffmpeg isn't
linux only neither is ipfs.

Anyhow, V2 of this patch series will be here shortly.


> Come to think of it, why aren't URLs openable as files on Linux?
>
> /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".
>