Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Eran Kornblau <eran.kornblau@kaltura.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: [FFmpeg-devel] http: honor response headers in redirect caching
Date: Tue, 11 Jan 2022 14:43:04 +0000
Message-ID: <AS8PR04MB8913F7E4704B74F5D74106E0F5519@AS8PR04MB8913.eurprd04.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

Hi all,

Recently I’ve submitted a patch that adds a config option to disable the caching of http redirects.
We planned this as a workaround to the fact there’s a limit on the expiration that can be set on S3 pre-signed URLs.
The idea was to have a service that generates signed S3 URLs and redirects to them, ffmpeg would hit this service
on every seek/disconnect, and get a fresh S3 URL.

We found that in some cases, ffmpeg seeks on every frame (probably due to some gap between the positions of
video/audio frames in the file). In these cases, completely disabling the redirect caching becomes quite inefficient -
our S3 signing service gets called ~20 times/sec by a single encoding task.

The attached patch provides a more complete/correct implementation of redirect caching – the decision whether
to cache/for how long is now determined according to the response from the server - status code (e.g. 301 vs 302),
expires header & cache-control header. The behavior (detailed in the comment of the commit) is more aligned
with how browsers handle it.

In high level, these are the changes that were implemented in the patch –

  1.  Added a dictionary on HTTPContext for keeping the cache – since I need to save both the target URL
and the expiration, I’m formatting them together on a single string (“expiry;target-url”)
  2.  Added a string on HTTPContext to save the value of the location header – this makes the existing
flags new_location/location_changed redundant, and they were removed
  3.  Added functions for parsing Cache-Control/Expires – for Expires I used the existing function for
parsing cookie expiration time. The result is saved on a new integer on HTTPContent -
a zero value means that no such header was encountered yet, a negative value means the response
should not be cached.
Once this patch is merged, IMHO we can remove the flag that I added in the previous patch (=always treat it as 0,
and have the caching work based on the new dictionary). I will happily submit another patch for this.

Thank you!

Eran

[-- Attachment #2: 0001-http-honor-response-headers-in-redirect-caching.patch --]
[-- Type: application/octet-stream, Size: 13646 bytes --]

[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

             reply	other threads:[~2022-01-11 14:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 14:43 Eran Kornblau [this message]
2022-01-17 12:10 ` Ronald S. Bultje
2022-01-18 22:36   ` Ronald S. Bultje
2022-01-19  7:13     ` Eran Kornblau
2022-01-30  6:14       ` Eran Kornblau
2022-01-31 14:37         ` Ronald S. Bultje
2022-01-31 19:09           ` Ronald S. Bultje

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AS8PR04MB8913F7E4704B74F5D74106E0F5519@AS8PR04MB8913.eurprd04.prod.outlook.com \
    --to=eran.kornblau@kaltura.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git