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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2754 bytes --]

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


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


> lavf. A default gateway didn't exist when I last looked at the
> patchset. Seems I wasn't vigilant enough.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".