[FFmpeg-devel] [PATCH] http: make caching of redirect url optional

[Ronald S. Bultje]

Hi,

On Mon, Dec 27, 2021 at 2:08 PM Ronald S. Bultje <rsbultje at gmail.com> wrote:

> Hi,
>
> On Mon, Dec 27, 2021 at 4:38 AM Eran Kornblau <eran.kornblau at kaltura.com>
> wrote:
>
>> > -----Original Message-----
>> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> Ronald S. Bultje
>> > Sent: Sunday, 26 December 2021 16:07
>> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org
>> >
>> > Subject: Re: [FFmpeg-devel] [PATCH] http: make caching of redirect url
>> optional
>> >
>> > Hi,
>> >
>> > (I was asked to respond since I'm listed as HTTP maintainer, not sure I
>> should be since I'm mostly working on video codecs nowadays.)
>> >
>> > On Tue, Nov 2, 2021 at 9:00 AM Eran Kornblau <eran.kornblau at kaltura.com
>> >
>> > wrote:
>> >
>> > > The motivation for this feature is S3 signatures – currently we have
>> a
>> > > problem where S3 signatures cannot be created with an expiration of
>> > > more than 12H. In some cases, a transcoding task may execute for more
>> > > than that.
>> > > If we use a pre-signed S3 URL, and ffmpeg disconnects/seeks after the
>> > > expiration of the URL, it will fail.
>> > >
>> > > The solution we are planning is to have some local server on the
>> > > machine running ffmpeg that will generate an S3-signature, and
>> > > redirect to the full pre-signed URL. For this to work, I need to
>> > > disable the caching of redirects, and have ffmpeg always start from
>> > > the initial URL.
>> > > The nice thing about this solution is that the video data is pulled
>> > > directly from S3 – in other words, the local server doesn’t hold any
>> > > real load, it just builds the signature and returns a redirect.
>> > >
>> >
>> > Uhm... This is a really weird solution, but it does look right.
>> >
>> > Generally speaking, we're typically concerned about the default being
>> the right behaviour. I would say that (maybe after some time, at the next
>> ABI break or so), 0 should be the default, not 1. This is the same as what
>> Marton/Hendrik said also, I think, so consider this consensus. I would just
>> do that with the appropriate ABI macros so the default behaviour changes at
>> the next bump.
>> >
>> Thank you, Ronald!
>>
>> I attached a new patch with the change you requested, I hope I understood
>> your intention correctly...
>>
>
> Yes, LGTM. I'll give it a few days to let Marton/Hendrik respond before I
> push.
>

Merged.

Ronald