[FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.

Fri Mar 11 15:45:17 EET 2022

On Wed, Mar 9, 2022 at 10:36 AM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Wed, Mar 09, 2022 at 01:30:30AM +0100, Mark Gaiser wrote:
> > On Wed, Mar 9, 2022 at 12:45 AM Michael Niedermayer <
> michael at niedermayer.cc>
> > wrote:
> >
> > > On Tue, Mar 08, 2022 at 01:49:22PM +0100, Mark Gaiser wrote:
> > > > On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer <
> > > michael at niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Thu, Mar 03, 2022 at 03:58:53PM +0100, Mark Gaiser wrote:
> > > > > > On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer <
> > > > > michael at niedermayer.cc>
> > > > > > wrote:
> > > > > >
> > > > > > > On Mon, Feb 28, 2022 at 02:09:15PM +0100, Tomas Härdin wrote:
> > > > > > > > sön 2022-02-27 klockan 15:29 +0100 skrev Mark Gaiser:
> > > > > > > > > Ping 2....
> > > > > > > > >
> > > > > > > > > I'd really like to get this merged!
> > > > > > > > > This kinda blocks me right now from proceeding with IPFS
> > > > > integration
> > > > > > > > > in
> > > > > > > > > Kodi, MPV and VLC. Implementations in those (who rely on
> > > ffmpeg)
> > > > > are
> > > > > > > > > significantly easier once this patch is finally landed in
> > > ffmpeg.
> > > > > > > >
> > > > > > > > I'd like to hear at least one other dev chime in on this one
> > > > > > >
> > > > > > > what exactly are you not sure about ?
> > > > > > > what exactly needs a 2nd look ?
> > > > > > >
> > > > > >
> > > > > > My assumption.
> > > > > > In general just a second look by someone other than Tomas.
> > > > > > And, as he was skeptical about this patch at first, likely
> another
> > > > > opinion
> > > > > > if this makes sense to add in ffmpeg.
> > > > > > To me it does very much but i'm biased :)
> > > > >
> > > > > ipfs support makes sense to be added to ffmpeg. ive seen ipfs urls
> and
> > > ive
> > > > > already been annoyed that some tools dont "just" work with them.
> > > > > While if i compare this to many other formats which i have never
> seen
> > > > > outside the context of FFmpeg. So from this biased single sample
> that i
> > > > > am, ipfs seems more widespread and thats why iam in favor of its
> > > support
> > > > >
> > > > > thx
> > > > >
> > > > > Great to have your support :)
> > > > Reading that is quite motivating to work on it, no joke!
> > > >
> > > > Just to be clear here. Having this in ffmpeg won't make it "just
> work"
> > > yet.
> > > > For a minimal feeling of "hey, it works out of the box" you'd need:
> > > > - The next or version after the next IPFS.
> > > > - MPV support which relies on this patch to even be supported in mpv
> > > > - Have a node running locally
> > >
> > > if theres no local node it should fallback to a public node
> > > ATM
> > > IPFS_GATEWAY=https://dweb.link ./ffplay ipfs://...
> > > works
> > > so such a fallback is all thats needed for it to just work
> > >
> >
> > Yes, the beauty of gateways.
> >
> > Are you suggesting that I update the patch to add this default?
>
> Iam not sure
>
>
> > I would prefer not to add that even though it would give a feeling of
> "just
> > works".
>
> > I'm mostly concerned about the bandwidth usage it could cause on that
> site.
>
> you could add more than one
> you could point people to https://ipfs.io/ipns/ipnso.com/ to let them
> select
> their own or maybe theres a better way
>
>
> > But also about potential hacks. If this is a default and well used then
> it
> > becomes quite appealing for hackers to take control of dweb.link and send
> > back data that wasn't requested.
>
> Thats a valid concern but not adding a default is not really solving this
> Because what do most people do then ?
> They google for a gateway and pick the first that works.
> Thats plausibly not going to give them the fastest nor the most secure nor
> even not the same as the last million people searching.
>
> To setup a ipfs node on ones own machiene, first it would be needed that
> this
> is VERY simple and clean
> if i run "apt search ipfs", theres none, so that already fails here
> but for the fun, i tried to search for ipfs node on the app store on my
> iphone
> no, also nothing.
>
> so i dont think "install an ipfs node" is really a viable solution for the
> average joe.
>
> we have a wide range of platforms, linux, windows, android, ios just to
> name
> the major ones. This protocol should work on all of them.
> I think a default gateway is the easy way to make that happen, asking the
> user to set a gateway will already leave android and iphone users probably
> wondering how to do that. Is there a way ?
>
> So really iam not saying "add a default", iam really saying "make it work
> for everyone", its ok if the user has to choose one or set some default but
> it really has to work on all platforms and with all user apps using
> libavformat. It should not be specific to mpv or windows/linux
>
> you can also print a big nasty warning that a default is used and the user
> should really setup their own node and why that is better.
>

Sorry for the belayed response but i had to discuss this with someone from
Protocol Labs (they manage IPFS).

I'd like to propose the following:

1. First and foremost, the gateway detection stuff is used. If all of that
still evaluates to no gateway then a fallback on dweb.link will be used. I
have asked them for their approval. This would be the most ideal gateway as
it is managed by the same company as IPFS (Protocol Labs). Approval on
their part is already a near certain yes but i'm still waiting on an
explicit OK from their end with the knowledge that this might become a
bandwidth beast once i complete specifically the KODI side of ipfs handling
(which would use this IPFS path).
2. There won't be any other fallback gateway
3. The above mentioned fallback gateway will be hardcoded. So no extra
command argument to change it. Changing it later would be a patch to ffmpeg.
4. When the fallback gateway is used, print a warning that a user should
install a local gateway instead. Something along those lines. Just to
motivate the use of local gateways.

On the bright, and that's awesome, it will mean that ipfs url's will just
work!
That includes mobile platforms too! Which is a really big win imho because
mobile/embedded might not be able to change ffmpeg settings/flags at all.
Also for mpv, vlc and kodi (my next projects after it lands here) it will
give an impression of "ipfs urls work out of the box"

The downside is the reliance on dweb.link.
Therefore i'd like to ask your explicit permission that a reliance on -
effectively another service - is OK!

I'll send a mail with a new patch once your approval and that of protocol
labs are known to me.

>
> thx
>
> >
> > If you insist this would be really better to add then I'll need to go
> find
> > the ones managing that site (paying for it) to ask permission if this
> would
> > be allowed.
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
> _______________________________________________
> 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".
>