Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Fri, Mar 11, 2022 at 02:45:17PM +0100, Mark Gaiser wrote: > On Wed, Mar 9, 2022 at 10:36 AM Michael Niedermayer > 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 < > > mich...@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 < > > > > mich...@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 < > > > > > > mich...@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
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Wed, Mar 9, 2022 at 10:36 AM Michael Niedermayer 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 < > mich...@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 < > > > mich...@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 < > > > > > mich...@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
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Wed, Mar 09, 2022 at 01:30:30AM +0100, Mark Gaiser wrote: > On Wed, Mar 9, 2022 at 12:45 AM Michael Niedermayer > 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 < > > mich...@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 < > > > > mich...@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. thx > > If you insist this would be really better to add then I'll need to go find > the ones managing that site (paying for it) to ask permission if this would > be allowed. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Wed, Mar 9, 2022 at 12:45 AM Michael Niedermayer 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 < > mich...@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 < > > > mich...@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? 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. 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. If you insist this would be really better to add then I'll need to go find the ones managing that site (paying for it) to ask permission if this would be allowed. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If the United States is serious about tackling the national security > threats > related to an insecure 5G network, it needs to rethink the extent to which > it > values corporate profits and government espionage over security.-Bruce > Schneier > ___ > 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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Tue, Mar 08, 2022 at 01:49:22PM +0100, Mark Gaiser wrote: > On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer > 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 < > > mich...@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 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer 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 < > mich...@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 Once you have those then a "mpv ipfs://" works without any additional configuration. We're getting there and this is one (admittedly very significant) step in that direction. Lastly. merge time? Could you do the honors? As I don't have the required permissions. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > ___ > 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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Thu, Mar 03, 2022 at 03:58:53PM +0100, Mark Gaiser wrote: > On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer > 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer 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 :) In an effort to get this patch done, I'm adding the people to the CC that have commented on the earlier versions (v0, 1 and 2) of this patch. @Michael or Thomas, if no reply is here in the next 2 days, could this be merged? As I assume no reply after this much pinging and raising awareness means an implicit OK. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew > ..." > ___ > 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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
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 ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
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 /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".
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
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. On Mon, Feb 21, 2022 at 12:32 PM Mark Gaiser wrote: > On Thu, Feb 17, 2022 at 3:57 PM Mark Gaiser wrote: > >> On Thu, Feb 17, 2022 at 3:50 PM Mark Gaiser wrote: >> >>> This patch adds support for: >>> - ffplay ipfs:// >>> - ffplay ipns:// >>> >>> IPFS data can be played from so called "ipfs gateways". >>> A gateway is essentially a webserver that gives access to the >>> distributed IPFS network. >>> >>> This protocol support (ipfs and ipns) therefore translates >>> ipfs:// and ipns:// to a http:// url. This resulting url is >>> then handled by the http protocol. It could also be https >>> depending on the gateway provided. >>> >>> To use this protocol, a gateway must be provided. >>> If you do nothing it will try to find it in your >>> $HOME/.ipfs/gateway file. The ways to set it manually are: >>> 1. Define a -gateway to the gateway. >>> 2. Define $IPFS_GATEWAY with the full http link to the gateway. >>> 3. Define $IPFS_PATH and point it to the IPFS data path. >>> 4. Have IPFS running in your local user folder (under $HOME/.ipfs). >>> >>> Signed-off-by: Mark Gaiser >>> --- >>> configure | 2 + >>> doc/protocols.texi| 30 >>> libavformat/Makefile | 2 + >>> libavformat/ipfsgateway.c | 309 ++ >>> libavformat/protocols.c | 2 + >>> 5 files changed, 345 insertions(+) >>> create mode 100644 libavformat/ipfsgateway.c >>> >>> diff --git a/configure b/configure >>> index 5b19a35f59..6ff09e7974 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -3585,6 +3585,8 @@ udp_protocol_select="network" >>> udplite_protocol_select="network" >>> unix_protocol_deps="sys_un_h" >>> unix_protocol_select="network" >>> +ipfs_protocol_select="https_protocol" >>> +ipns_protocol_select="https_protocol" >>> >>> # external library protocols >>> libamqp_protocol_deps="librabbitmq" >>> diff --git a/doc/protocols.texi b/doc/protocols.texi >>> index d207df0b52..7c9c0a4808 100644 >>> --- a/doc/protocols.texi >>> +++ b/doc/protocols.texi >>> @@ -2025,5 +2025,35 @@ decoding errors. >>> >>> @end table >>> >>> +@section ipfs >>> + >>> +InterPlanetary File System (IPFS) protocol support. One can access >>> files stored >>> +on the IPFS network through so called gateways. Those are http(s) >>> endpoints. >>> +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to >>> be send >>> +to such a gateway. Users can (and should) host their own node which >>> means this >>> +protocol will use your local machine gateway to access files on the >>> IPFS network. >>> + >>> +If a user doesn't have a node of their own then the public gateway >>> dweb.link is >>> +used by default. >>> + >>> +You can use this protocol in 2 ways. Using IPFS: >>> +@example >>> +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T >>> +@end example >>> + >>> +Or the IPNS protocol (IPNS is mutable IPFS): >>> +@example >>> +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T >>> +@end example >>> + >>> +You can also change the gateway to be used: >>> + >>> +@table @option >>> + >>> +@item gateway >>> +Defines the gateway to use. When nothing is provided the protocol will >>> first try >>> +your local gateway. If that fails dweb.link will be used. >>> + >>> +@end table >>> >>> @c man end PROTOCOLS >>> diff --git a/libavformat/Makefile b/libavformat/Makefile >>> index 3dc6a479cc..4edce8420f 100644 >>> --- a/libavformat/Makefile >>> +++ b/libavformat/Makefile >>> @@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += >>> srtpproto.o srtp.o >>> OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o >>> OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o >>> OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o >>> +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o >>> +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o >>> TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o >>> TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o >>> TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o >>> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c >>> new file mode 100644 >>> index 00..7dfa56871d >>> --- /dev/null >>> +++ b/libavformat/ipfsgateway.c >>> @@ -0,0 +1,309 @@ >>> +/* >>> + * IPFS and IPNS protocol support through IPFS Gateway. >>> + * Copyright (c) 2022 Mark Gaiser >>> + * >>> + * This file is part of FFmpeg. >>> + * >>> + * FFmpeg is free software; you can redistribute it and/or >>> + * modify it under the terms of the GNU Lesser General Public >>> + * License as published by the Free Software Foundation; either >>> + * version 2.1 of the License, or (at your option) any later version. >>> + * >>> + * FFmpeg is distributed in
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Thu, Feb 17, 2022 at 3:57 PM Mark Gaiser wrote: > On Thu, Feb 17, 2022 at 3:50 PM Mark Gaiser wrote: > >> This patch adds support for: >> - ffplay ipfs:// >> - ffplay ipns:// >> >> IPFS data can be played from so called "ipfs gateways". >> A gateway is essentially a webserver that gives access to the >> distributed IPFS network. >> >> This protocol support (ipfs and ipns) therefore translates >> ipfs:// and ipns:// to a http:// url. This resulting url is >> then handled by the http protocol. It could also be https >> depending on the gateway provided. >> >> To use this protocol, a gateway must be provided. >> If you do nothing it will try to find it in your >> $HOME/.ipfs/gateway file. The ways to set it manually are: >> 1. Define a -gateway to the gateway. >> 2. Define $IPFS_GATEWAY with the full http link to the gateway. >> 3. Define $IPFS_PATH and point it to the IPFS data path. >> 4. Have IPFS running in your local user folder (under $HOME/.ipfs). >> >> Signed-off-by: Mark Gaiser >> --- >> configure | 2 + >> doc/protocols.texi| 30 >> libavformat/Makefile | 2 + >> libavformat/ipfsgateway.c | 309 ++ >> libavformat/protocols.c | 2 + >> 5 files changed, 345 insertions(+) >> create mode 100644 libavformat/ipfsgateway.c >> >> diff --git a/configure b/configure >> index 5b19a35f59..6ff09e7974 100755 >> --- a/configure >> +++ b/configure >> @@ -3585,6 +3585,8 @@ udp_protocol_select="network" >> udplite_protocol_select="network" >> unix_protocol_deps="sys_un_h" >> unix_protocol_select="network" >> +ipfs_protocol_select="https_protocol" >> +ipns_protocol_select="https_protocol" >> >> # external library protocols >> libamqp_protocol_deps="librabbitmq" >> diff --git a/doc/protocols.texi b/doc/protocols.texi >> index d207df0b52..7c9c0a4808 100644 >> --- a/doc/protocols.texi >> +++ b/doc/protocols.texi >> @@ -2025,5 +2025,35 @@ decoding errors. >> >> @end table >> >> +@section ipfs >> + >> +InterPlanetary File System (IPFS) protocol support. One can access files >> stored >> +on the IPFS network through so called gateways. Those are http(s) >> endpoints. >> +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to >> be send >> +to such a gateway. Users can (and should) host their own node which >> means this >> +protocol will use your local machine gateway to access files on the IPFS >> network. >> + >> +If a user doesn't have a node of their own then the public gateway >> dweb.link is >> +used by default. >> + >> +You can use this protocol in 2 ways. Using IPFS: >> +@example >> +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T >> +@end example >> + >> +Or the IPNS protocol (IPNS is mutable IPFS): >> +@example >> +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T >> +@end example >> + >> +You can also change the gateway to be used: >> + >> +@table @option >> + >> +@item gateway >> +Defines the gateway to use. When nothing is provided the protocol will >> first try >> +your local gateway. If that fails dweb.link will be used. >> + >> +@end table >> >> @c man end PROTOCOLS >> diff --git a/libavformat/Makefile b/libavformat/Makefile >> index 3dc6a479cc..4edce8420f 100644 >> --- a/libavformat/Makefile >> +++ b/libavformat/Makefile >> @@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += >> srtpproto.o srtp.o >> OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o >> OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o >> OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o >> +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o >> +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o >> TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o >> TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o >> TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o >> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c >> new file mode 100644 >> index 00..7dfa56871d >> --- /dev/null >> +++ b/libavformat/ipfsgateway.c >> @@ -0,0 +1,309 @@ >> +/* >> + * IPFS and IPNS protocol support through IPFS Gateway. >> + * Copyright (c) 2022 Mark Gaiser >> + * >> + * This file is part of FFmpeg. >> + * >> + * FFmpeg is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU Lesser General Public >> + * License as published by the Free Software Foundation; either >> + * version 2.1 of the License, or (at your option) any later version. >> + * >> + * FFmpeg is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + * Lesser General Public License for more details. >> + * >> + * You should have received a copy of the GNU Lesser General Public >> + * License along with FFmpeg; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor,
Re: [FFmpeg-devel] [PATCH v8 1/1] avformat: Add IPFS protocol support.
On Thu, Feb 17, 2022 at 3:50 PM Mark Gaiser wrote: > This patch adds support for: > - ffplay ipfs:// > - ffplay ipns:// > > IPFS data can be played from so called "ipfs gateways". > A gateway is essentially a webserver that gives access to the > distributed IPFS network. > > This protocol support (ipfs and ipns) therefore translates > ipfs:// and ipns:// to a http:// url. This resulting url is > then handled by the http protocol. It could also be https > depending on the gateway provided. > > To use this protocol, a gateway must be provided. > If you do nothing it will try to find it in your > $HOME/.ipfs/gateway file. The ways to set it manually are: > 1. Define a -gateway to the gateway. > 2. Define $IPFS_GATEWAY with the full http link to the gateway. > 3. Define $IPFS_PATH and point it to the IPFS data path. > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). > > Signed-off-by: Mark Gaiser > --- > configure | 2 + > doc/protocols.texi| 30 > libavformat/Makefile | 2 + > libavformat/ipfsgateway.c | 309 ++ > libavformat/protocols.c | 2 + > 5 files changed, 345 insertions(+) > create mode 100644 libavformat/ipfsgateway.c > > diff --git a/configure b/configure > index 5b19a35f59..6ff09e7974 100755 > --- a/configure > +++ b/configure > @@ -3585,6 +3585,8 @@ udp_protocol_select="network" > udplite_protocol_select="network" > unix_protocol_deps="sys_un_h" > unix_protocol_select="network" > +ipfs_protocol_select="https_protocol" > +ipns_protocol_select="https_protocol" > > # external library protocols > libamqp_protocol_deps="librabbitmq" > diff --git a/doc/protocols.texi b/doc/protocols.texi > index d207df0b52..7c9c0a4808 100644 > --- a/doc/protocols.texi > +++ b/doc/protocols.texi > @@ -2025,5 +2025,35 @@ decoding errors. > > @end table > > +@section ipfs > + > +InterPlanetary File System (IPFS) protocol support. One can access files > stored > +on the IPFS network through so called gateways. Those are http(s) > endpoints. > +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be > send > +to such a gateway. Users can (and should) host their own node which means > this > +protocol will use your local machine gateway to access files on the IPFS > network. > + > +If a user doesn't have a node of their own then the public gateway > dweb.link is > +used by default. > + > +You can use this protocol in 2 ways. Using IPFS: > +@example > +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +Or the IPNS protocol (IPNS is mutable IPFS): > +@example > +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +You can also change the gateway to be used: > + > +@table @option > + > +@item gateway > +Defines the gateway to use. When nothing is provided the protocol will > first try > +your local gateway. If that fails dweb.link will be used. > + > +@end table > > @c man end PROTOCOLS > diff --git a/libavformat/Makefile b/libavformat/Makefile > index 3dc6a479cc..4edce8420f 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += > srtpproto.o srtp.o > OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o > OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o > OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o > +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o > +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o > TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o > TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o > TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c > new file mode 100644 > index 00..7dfa56871d > --- /dev/null > +++ b/libavformat/ipfsgateway.c > @@ -0,0 +1,309 @@ > +/* > + * IPFS and IPNS protocol support through IPFS Gateway. > + * Copyright (c) 2022 Mark Gaiser > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301 USA > + */ > + > +#include "avformat.h" > +#include "libavutil/avassert.h" > +#include "libavutil/avstring.h" > +#include "libavutil/internal.h" > +#include
