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". I also suggested we should actually implement ipfs or link to a library that implements it rather than shoving more string mangling crap into lavf. A default gateway didn't exist when I last looked at the patchset. Seems I wasn't vigilant enough. The correct place to solve this is at the OS level. There should be a fully fledged protocol handler in the OS that lavf can rely on, and neither lavf nor any other library should ever try to implement protocols themselvess. But that's more plan9-ish, so it will likely not happen in the Linux world any time soon. /Tomas _______________________________________________ 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".
