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

Sat Mar 12 17:14:48 EET 2022

On Fri, Mar 11, 2022 at 02:45:17PM +0100, Mark Gaiser wrote:
> 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.

ok


> 
> 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!

ok with me


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220312/38f063da/attachment.sig>