docs: record that the Gitea link answers range requests, so the video seeks
This commit is contained in:
@@ -292,9 +292,12 @@ action except the items marked **[code]**.
|
|||||||
Checked from outside this network: **200**, `Content-Type: video/mp4`,
|
Checked from outside this network: **200**, `Content-Type: video/mp4`,
|
||||||
`Content-Length: 1847900` and `Content-Disposition: inline`, so a reviewer's browser plays
|
`Content-Length: 1847900` and `Content-Disposition: inline`, so a reviewer's browser plays
|
||||||
it in the tab rather than prompting a download, and the served bytes are identical to the
|
it in the tab rather than prompting a download, and the served bytes are identical to the
|
||||||
recording (sha256 match). Two things to know before pasting: the URL is pinned to `main`,
|
recording (sha256 match). A `Range: bytes=0-99` request answers **206** with exactly those
|
||||||
so a re-shoot has to **overwrite the file in place** rather than be added alongside it; and
|
100 bytes even though `Accept-Ranges` is not advertised, so seeking works and a player can
|
||||||
replacing the video at all means resubmitting the declaration.
|
start without fetching the whole file first — which matters here because `screenrecord`
|
||||||
|
writes the `moov` atom at the very end of the file. Two things to know before pasting: the
|
||||||
|
URL is pinned to `main`, so a re-shoot has to **overwrite the file in place** rather than
|
||||||
|
be added alongside it; and replacing the video at all means resubmitting the declaration.
|
||||||
(An unlisted YouTube upload of the same file works equally well if a link that survives
|
(An unlisted YouTube upload of the same file works equally well if a link that survives
|
||||||
future commits is preferred — but then it is a second place to keep in step.)
|
future commits is preferred — but then it is a second place to keep in step.)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user