On Mon, Aug 15, 2022 at 11:57 PM Nicolas George <geo...@nsup.org> wrote:
> Michael Niedermayer (12022-08-15):
> > It says this now:
> > "IPFS does not appear to be running.\n\n"
> > "Installing IPFS locally is recommended to "
> > "improve performance and reliability, "
> > That removes the gateway (because it cant be trusted and replaced it
> > by a litteral recommandition to install their software)
> > replace loging by code exec ... either you trust them or not
>
> The recommendation was already there, it was not changed by the patch.
> And it definitely should not be there, it is an error message, not a
> novel. Furthermore, even the actual error message, "IPFS does not appear
> to be running", is just wrong.
>
> The error message should be something like "IPFS gateway not
> configured." and the rest in the documentation, starting with which
> configuration files and environment variables it uses, and including
> warnings about security and privacy concerns.
>
I'd like to clarify a few points regarding the gateway. As like many things
said in this thread, it's not all just as black/white as it might appear at
first glance.
First an earlier message from Micheal:
> Before this patch, only "experts" needed to change the IPFS settings.
> After this patch everyone who wants to use IPFS needs to change the IPFS
> settings.
This is both true and false where it entirely depends on the situation.
If one is running an IPFS node and if that node is 0.15.0 or up (to be
released in the coming days or weeks) then:
- the gateway file exists as ~/.ipfs/gateway when IPFS is running
- ffmpeg will find it and use it
- the user uses the local gateway
Granted, that is in the happy day scenario. Users who don't have IPFS
running now have to provide the gateway with one of the available options.
Next the message I reply on, specifically:
> "IPFS does not appear to be running", is just wrong.
I suspect the patch didn't do what it originally did when no gateway was
found (which is the new case).
This message was supposed to be shown in that scenario:
av_log(h, AV_LOG_INFO,
"Installing IPFS locally is recommended to "
"improve performance and reliability, "
"and not share all your activity with a single IPFS
gateway.\n"
"There are multiple options to define this gateway.\n"
"1. Call ffmpeg with a gateway param, "
"without a trailing slash: -gateway <url>.\n"
"2. Define an $IPFS_GATEWAY environment variable with
the "
"full HTTP URL to the gateway "
"without trailing forward slash.\n"
"3. Define an $IPFS_PATH environment variable "
"and point it to the IPFS data path "
"- this is typically ~/.ipfs\n");
In the new reality that message still wouldn't be as accurate as it can be.
It would miss a line explaining the cause and it would likely be an error
typed message instead.
I'd be happy to review and test a patch that fixes this!
Another quote from an earlier message:
> The printed text is adequate to experts but not to the average user.
> It should either explain the privacy & security implications of the
> different options or point to some external documentation.
> Such external documentation needs to stay available at the given link
> also for the lifetime of the releases it is part of
I'd be happy to help to create log messages and documentation that make
sense to everyone targeted as a user.
However, I do consider both ffmpeg and ipfs as fairly low level tools where
it should be expected that some technical jargon would be acceptable. In
other terms, not foolproof but technically correct and clear enough.
Applications building on top of ffmpeg should probably be the one giving a
end user friendly message (for example, vlc, kodi, mpv, ..)
Just let me know how I can help!
Lastly, I'd really appreciate it if I can get a cc when there is a change
in the ipfsgateway implementation in ffmpeg.
I'm not an ffmpeg dev at all thus it can be assumed that I don't monitor
the ffmpeg mailing lists.
A cc would therefore be really helpful. My name and mail is in the source
file.
> Regards,
>
> --
> Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
