On Sat, Aug 27, 2022 at 09:05:06AM +0200, Tomas Härdin wrote:
> ons 2022-08-24 klockan 22:54 +0200 skrev Michael Niedermayer:
> > On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
> > > But for some reason the notion
> > > that the same applies to *all* parsers, including decoders and
>
lör 2022-08-27 klockan 10:34 -0700 skrev Baptiste Coudurier:
> On Aug 27, 2022, at 4:30 AM, Tomas Härdin wrote:
> >
> > lör 2022-08-27 klockan 09:53 +0200 skrev Paul B Mahol:
> > > On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin
> > > wrote:
> > >
> > > > ons 2022-08-24 klockan 23:03 +0200 skrev M
On Aug 27, 2022, at 4:30 AM, Tomas Härdin wrote:
>
> lör 2022-08-27 klockan 09:53 +0200 skrev Paul B Mahol:
>> On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin
>> wrote:
>>
>>> ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer:
Also we have regression tests, external libs make that
lör 2022-08-27 klockan 09:53 +0200 skrev Paul B Mahol:
> On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin
> wrote:
>
> > ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer:
> > > Also we have regression tests, external libs make that impossible
> > > as the version of external libs can chan
On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin wrote:
> ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer:
> > On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
> > [...]
> > >
> > > This goes especially for formats like MXF, which I have made the
> > > case
> > > on here mul
ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer:
> On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
> [...]
> >
> > This goes especially for formats like MXF, which I have made the
> > case
> > on here multiple times that we should not maintain our own decoder
> > for,
>
ons 2022-08-24 klockan 22:54 +0200 skrev Michael Niedermayer:
> On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
> > But for some reason the notion
> > that the same applies to *all* parsers, including decoders and
> > demuxers, this notion is hard to swallow. And similarly for
> > enc
> > You will never fit all the features of complex
> > containers like MXF, MP4, TS (and for argument's sake XML) inside a
> > generalised framework like FFmpeg.
>
> Maybe true but the reason is not that it cant be dont just that there are
> features noone uses and noone needs.
> I do know some vid
On Wed, Aug 24, 2022 at 10:18:04PM +0100, Kieran Kunhya wrote:
> >
> > for libxml2 these problems are less likely to hit us as we likely never
> > need a
> > "new xml feature" but for a (de)muxer we quite likely will need the
> > latests version on every platform.
> > Also we have regression tests,
>
> for libxml2 these problems are less likely to hit us as we likely never
> need a
> "new xml feature" but for a (de)muxer we quite likely will need the
> latests version on every platform.
> Also we have regression tests, external libs make that impossible
> as the version of external libs can c
On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
[...]
>
> This goes especially for formats like MXF, which I have made the case
> on here multiple times that we should not maintain our own decoder for,
> but rather pull in bmx. And everytime I have suggested this it has been
> made cl
On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
> mån 2022-08-22 klockan 14:52 +0200 skrev Nicolas George:
> > Tomas Härdin (12022-08-22):
> > > I'd actually argue that in that case we should link a library that
> > > implements IPFS, not split developer effort by trying to implement
mån 2022-08-22 klockan 14:52 +0200 skrev Nicolas George:
> Tomas Härdin (12022-08-22):
> > I'd actually argue that in that case we should link a library that
> > implements IPFS, not split developer effort by trying to implement
> > it
> > ourselves.
>
> Is FFmpeg meant to be just a convenient set
Ronald S. Bultje (12022-08-23):
> I think it usually comes down to a developer wanting to, you know, spend
> time on it.
Sure, it can be that. But not only. I have seen people, including Tomas
himself, oppose code in favor of using a library.
Regards,
--
Nicolas George
signature.asc
Descrip
Hi,
On Mon, Aug 22, 2022 at 5:52 AM Nicolas George wrote:
> Tomas Härdin (12022-08-22):
> > I'd actually argue that in that case we should link a library that
> > implements IPFS, not split developer effort by trying to implement it
> > ourselves.
>
> Is FFmpeg meant to be just a convenient set
Tomas Härdin (12022-08-22):
> I'd actually argue that in that case we should link a library that
> implements IPFS, not split developer effort by trying to implement it
> ourselves.
Is FFmpeg meant to be just a convenient set of wrappers for existing
libraries, then?
If not, what is your criterio
fre 2022-08-19 klockan 14:52 +0200 skrev Mark Gaiser:
>
>
> I believe we went over this in detail during those patch rounds when
> this
> was brought up (by you?).
> I didn't go back in the archives to find it, but some reasons that
> come to
> mind:
> - just handing the mere edge cases would mak
On Fri, Aug 19, 2022 at 11:15 AM Tomas Härdin wrote:
> 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:
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 f
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/29383
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
On Mon, Aug 15, 2022 at 11:47:53PM +0200, Michael Niedermayer wrote:
[...]
> If one was concerned that using a default gateway could be seen
> as endorsment by us. Be concerned please about how FFmpeg looks
> when its developers attack other projects on its official development IRC
> channels.
iv
On Mon, Aug 15, 2022 at 11:57 PM Nicolas George 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 re
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
On Mon, Aug 15, 2022 at 08:35:18PM +0100, Derek Buitenhuis wrote:
> On 8/10/2022 11:27 PM, Derek Buitenhuis wrote:
> > A gateway can see everything, and we should not be shipping a hardcoded
> > default from a third party company; it's a security risk.
> >
> > Signed-off-by: Derek Buitenhuis
> >
On 8/15/2022 4:35 PM, Derek Buitenhuis wrote:
On 8/10/2022 11:27 PM, Derek Buitenhuis wrote:
A gateway can see everything, and we should not be shipping a hardcoded
default from a third party company; it's a security risk.
Signed-off-by: Derek Buitenhuis
---
libavformat/ipfsgateway.c | 11 ++
On 8/10/2022 11:27 PM, Derek Buitenhuis wrote:
> A gateway can see everything, and we should not be shipping a hardcoded
> default from a third party company; it's a security risk.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/ipfsgateway.c | 11 ---
> 1 file changed, 4 inserti
On Wed, Aug 10, 2022 at 11:27:08PM +0100, Derek Buitenhuis wrote:
> A gateway can see everything, and we should not be shipping a hardcoded
> default from a third party company; it's a security risk.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/ipfsgateway.c | 11 ---
> 1 file
Yo,
On Mon, 15 Aug 2022, at 16:09, Nicolas George wrote:
> As for what to do now, I suggest we approve Derek's patch removing the
> default gateway, and discuss the rest after.
I agree. This is the simplest for now, yes.
What one can do, is suggest known examples of gateways in the error log
m
Michael Niedermayer (12022-08-13):
> what iam a bit "upset" about is that running a IPFS node is presented as
> if that was more private than using a gateway.
I do not think it was suggested that it was more private and/or secure.
A more accurate and detailed statement of the issue is that both
s
On Sat, Aug 13, 2022 at 09:06:50PM +0200, Timo Rothenpieler wrote:
> On 13.08.2022 18:29, Michael Niedermayer wrote:
> > I fully support better IPFS support
> > what iam a bit "upset" about is that running a IPFS node is presented as
> > if that was more private than using a gateway.
>
> That's no
On 13.08.2022 18:29, Michael Niedermayer wrote:
I fully support better IPFS support
what iam a bit "upset" about is that running a IPFS node is presented as
if that was more private than using a gateway.
That's not what people are suggesting.
The primary upset is about FFmpeg having hardcoded i
On Fri, Aug 12, 2022 at 07:21:02PM +0200, Timo Rothenpieler wrote:
> On 12.08.2022 19:18, Michael Niedermayer wrote:
> > And i dont think removing IPFS support entirely from FFmpeg is a smart
> > choice.
>
> I wouldn't at all be upset about having proper IPFS support in FFmpeg,
> there's no argum
On 12.08.2022 19:18, Michael Niedermayer wrote:
And i dont think removing IPFS support entirely from FFmpeg is a smart choice.
I wouldn't at all be upset about having proper IPFS support in FFmpeg,
there's no argument there.
The issue is that this has very little to do with actual/native IPF
On Fri, Aug 12, 2022 at 07:01:49PM +0200, Nicolas George wrote:
> Michael Niedermayer (12022-08-12):
> > Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog
> >
> > to grab data from DNS you can implement a full DNS server which recursivly
> > resolves the request starting
Michael Niedermayer (12022-08-12):
> Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog
>
> to grab data from DNS you can implement a full DNS server which recursivly
> resolves the request starting from the root name servers (which it needs to
> have
> hardcoded in some
On Fri, Aug 12, 2022 at 12:03:17AM +0200, Timo Rothenpieler wrote:
> On 11.08.2022 22:18, Michael Niedermayer wrote:
> > On Thu, Aug 11, 2022 at 07:56:04PM +0200, Mark Gaiser wrote:
[...]
> > >
> > > This is just your - valued! - opinion, but still just 1. I insist on
> > > waiting to hear from M
Derek Buitenhuis (12022-08-11):
> I agree... we should never send a users data through *any* service they
> haven't explicitly asked for. Ever. Regardless of who runs it and who
> is deemed "trustworthy".
Absolutely. And Kieran's simile with DNS is very good. It is not just a
question of whether t
On Fri, 12 Aug 2022 at 15:48, Derek Buitenhuis
wrote:
> On 8/12/2022 3:34 PM, Mark Gaiser wrote:
> > Great opinion you 2, 0 constructiveness.
> > That doesn't help at all.
>
> Your tone has been pretty rude in this whole thread.
>
> > Please try again in a constructive manner that convinces me of
On 8/12/2022 3:34 PM, Mark Gaiser wrote:
> Great opinion you 2, 0 constructiveness.
> That doesn't help at all.
Your tone has been pretty rude in this whole thread.
> Please try again in a constructive manner that convinces me of your
> undoubtedly great arguments!
You seem to be defining anythi
>
> Great opinion you 2, 0 constructiveness.
> That doesn't help at all.
>
> Please try again in a constructive manner that convinces me of your
> undoubtedly great arguments!
>
Please let me know what IPFS has to do with Interplanetary Communications.
(hint: none).
Kieran
__
On Fri, Aug 12, 2022 at 4:30 PM Kieran Kunhya wrote:
> On Fri, 12 Aug 2022 at 15:22, Vittorio Giovara >
> wrote:
>
> > On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis <
> > derek.buitenh...@gmail.com> wrote:
> >
> > > As it exists right now though, I don't really see why lavf needs what
> > >
On Fri, 12 Aug 2022 at 15:22, Vittorio Giovara
wrote:
> On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
> > As it exists right now though, I don't really see why lavf needs what
> > amounts to a URL builder for a service as a "protocol" - this totally
>
On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:
> As it exists right now though, I don't really see why lavf needs what
> amounts to a URL builder for a service as a "protocol" - this totally
> the wrong layer to do that at...
>
Agreed, this protocol should
On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:
> On 8/11/2022 11:03 PM, Timo Rothenpieler wrote:
> > Any kind of built in hardcoded server is not acceptable imo.
> > Even with it pointing to our own infrastructure, we can't really
> > guarantee its availabil
On 8/11/2022 11:03 PM, Timo Rothenpieler wrote:
> Any kind of built in hardcoded server is not acceptable imo.
> Even with it pointing to our own infrastructure, we can't really
> guarantee its availability, specially should the protocol gain traction
> and heavy use.
I agree... we should never
On 11.08.2022 22:18, Michael Niedermayer wrote:
On Thu, Aug 11, 2022 at 07:56:04PM +0200, Mark Gaiser wrote:
On Thu, Aug 11, 2022 at 7:35 PM Timo Rothenpieler
wrote:
On 11.08.2022 19:21, Mark Gaiser wrote:
On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler
On 11.08.2022 18:26, Mark Gaiser wr
On Thu, Aug 11, 2022 at 07:56:04PM +0200, Mark Gaiser wrote:
> On Thu, Aug 11, 2022 at 7:35 PM Timo Rothenpieler
> wrote:
>
> > On 11.08.2022 19:21, Mark Gaiser wrote:
> > > On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler > >
> > > wrote:
> > >
> > >> On 11.08.2022 18:26, Mark Gaiser wrote:
>
On 8/11/2022 6:56 PM, Mark Gaiser wrote:
> This is just your - valued! - opinion, but still just 1. I insist on
> waiting to hear from Michael to hear a decision on this, mainly because he
> was quite persistent in asking for this feature to begin with.
> The risks were clear and - somewhat - ment
On Thu, Aug 11, 2022 at 7:35 PM Timo Rothenpieler
wrote:
> On 11.08.2022 19:21, Mark Gaiser wrote:
> > On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler >
> > wrote:
> >
> >> On 11.08.2022 18:26, Mark Gaiser wrote:
> >>> Hi all,
> >>>
> >>> On the IPFS side we do have a solution for that with CA
On 11.08.2022 19:21, Mark Gaiser wrote:
On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler
wrote:
On 11.08.2022 18:26, Mark Gaiser wrote:
Hi all,
On the IPFS side we do have a solution for that with CAR files, you can
read more about that here [1].
Within the scope of this ipfs gateway protoc
On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler
wrote:
> On 11.08.2022 18:26, Mark Gaiser wrote:
> > Hi all,
> >
> > On the IPFS side we do have a solution for that with CAR files, you can
> > read more about that here [1].
> > Within the scope of this ipfs gateway protocol handler there isn't
On 11.08.2022 18:26, Mark Gaiser wrote:
Hi all,
On the IPFS side we do have a solution for that with CAR files, you can
read more about that here [1].
Within the scope of this ipfs gateway protocol handler there isn't a
solution yet to use CAR files, it is on our radar but still in the
discussio
Hi all,
On the IPFS side we do have a solution for that with CAR files, you can
read more about that here [1].
Within the scope of this ipfs gateway protocol handler there isn't a
solution yet to use CAR files, it is on our radar but still in the
discussion phase.
On the cURL side we had this sam
On 11/08/2022 00:27, Derek Buitenhuis wrote:
A gateway can see everything, and we should not be shipping a hardcoded
default from a third party company; it's a security risk.
Signed-off-by: Derek Buitenhuis
---
libavformat/ipfsgateway.c | 11 ---
1 file changed, 4 insertions(+), 7 de
A gateway can see everything, and we should not be shipping a hardcoded
default from a third party company; it's a security risk.
Signed-off-by: Derek Buitenhuis
---
libavformat/ipfsgateway.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/ipfsgateway.
56 matches
Mail list logo
