[FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

Tomas Härdin tjoppen at acc.umu.se
Fri Aug 19 12:15:44 EEST 2022


tor 2022-08-18 klockan 16:31 +0200 skrev Michael Niedermayer:
> On Wed, Aug 17, 2022 at 05:03:56PM +0200, Tomas Härdin wrote:
> > tor 2022-08-11 klockan 19:35 +0200 skrev Timo Rothenpieler:
> > > On 11.08.2022 19:21, Mark Gaiser wrote:
> > > > 
> > > > Here's the conversation requesting this very feature:
> > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293835.html
> > > 
> > > I generally agree with the points brought up there.
> > > But my conclusion very much is not "just put a somewhat random
> > > default 
> > > into the code".
> > > Even a list of defaults is not Okay.
> > > We can't hardcode "magic servers".
> > > 
> > > If it's not possible to make the protocol work without them, it
> > > likely 
> > > shouldn't have been merged in the first place.
> > > Why can't it access the files directly, but only via some magic
> > > http 
> > > gateway?
> > > Why does it need special code in ffmpeg in the first place, if
> > > you
> > > can 
> > > just access it via that http proxy-gateway anyway?
> > 
> > I raised this very point several times when IPFS support was first
> > suggested, and raised that ipfsgateway.c amounts to business logic
> > that
> > does not belong in lavf. I see now hat others in this thread, like
> > Derek, agree with me on this, which is nice. IIRC I even suggested
> > that
> > users should solve this in bash, a suggestion that was shouted down
> > as
> > being "insecure".
> 
> you cannot do it in bash

Is bash not Turing complete?

> filter="ipfs://..."
> on the command line is translated or not ?
> if its drawtext showing the user on screen a URL it must not be
> OTOH if the filter reads from the URL it has to be
> this just isnt going to work at the bash command line level besides
> bash is
> not even a dependancy of FFmpeg
> not to mention that a ipfs:// link from one container to another
> container
> would never show up on the command line

The point is that this is business logic that belongs elsewhere.

> > 
> > I also suggested we should actually implement ipfs or link to a
> > library
> > that implements it rather than shoving more string mangling crap
> > into
> 
> for reference, mark replied in that thread:
> 
>     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.

Yes that is what implementing ipfs: entails. But ipfsgateway.c is not
actually ipfs: now is it? This would be like gopher.c using overbite as
a gateway instead of actually implementing gopher:

We don't need to shovel everything into this project. We can actually
rely on users being smart. For example vlc could do the business logic
of dealing with IPFS. Or, better yet, the OS.

/Tomas



More information about the ffmpeg-devel mailing list