Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support range requests for video content #768

Closed
wants to merge 8 commits into from

Conversation

BPerlakiH
Copy link
Collaborator

Fixes: #767

@BPerlakiH BPerlakiH linked an issue May 19, 2024 that may be closed by this pull request
@BPerlakiH BPerlakiH changed the title 767 support range requests for video content Support range requests for video content May 19, 2024
@kelson42
Copy link
Contributor

kelson42 commented May 19, 2024

@BPerlakiH Codefactor should pass and I also see a few style problems.

….com:kiwix/apple into 767-support-range-requests-for-video-content
@BPerlakiH
Copy link
Collaborator Author

Please see it updated.

/// As a result of the large volume of small requests, CPU usage will be very high,
/// which can result in app or webpage frozen.
/// To mitigate, opting for the less "broken" behavior of ignoring Range header
/// until WebKit behavior is changed.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did found the root cause of this behaviour. In the original PR the byte range was one off, eg:

Byte-Range: 0-5
Content-Length: 5

Actually it should be either:

Byte-Range: 0-4
Content-Length: 5

OR

Byte-Range: 0-5
Content-Length: 6

Due to this one off error the browser was "kept" downloading the end of the range in chunks about ~8 bytes long.
Once the range was corrected, this side effect no longer exists.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure about this? I am still seeing the 8b range requests on this branch, with mp4 videos. webm videos did not trigger those small range requests…

Copy link
Collaborator Author

@BPerlakiH BPerlakiH May 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well... I did tested with mp4 files, and that is indeed triggering 8 bytes.
I also noticed that the "videojs" version is different on the ZIM file with mp4, than on the ZIM file with the webm test videos.
Maybe we will need an identical JS setup for both webm and mp4.

self?.sendHTTP404Response(urlSchemeTask, url: url)
self?.stopFor(hash)
return
}
self?.sendHTTP200Response(urlSchemeTask, url: url, content: content)
if isVideo {
self?.sendHTTP206Response(urlSchemeTask, url: url, content: content, start: start, end: end)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we only apply the range responses to video type of contents

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only apply to but also Apply to ALL videos

@@ -161,6 +177,11 @@ struct URLContent {
return mime
}
}

Copy link
Collaborator Author

@BPerlakiH BPerlakiH May 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This currently uses the ZIM file's modification date time to create the eTag, which I think a good enough solution for our purposes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is our purpose? Is this related to Range-requests?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thinking here was, that I looked at what headers are returned in Safari / Caddy when webm is played.
So I wanted to have the very same ones, to make sure it works. One of them was this eTag, which can be generated based on the date the ZIM file was changed.
We can omit this if you think it is not needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No harm in keeping it IMO. ETag is supposed to be a uniq version ID for a resource and this implementation is OK in this regard since all resources are single-version made at the same time in a ZIM.
Still it feels like abusing the header to have the same for all resources 😀
Mandates a comment explaining this I think

Copy link
Member

@rgaudin rgaudin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about the long delay !! 😵‍💫

PR has no description while it introduces changes that seems unrelated to the linked ticket: all that date stuff, is it helping the range requests in anyway? Or is it just general improvements?

Otherwise Code looks OK but it doesn't seem to fix what it intends to: webm video did not trigger the many range request so I'm not looking for improvement there.
MP4 videos on the other hand was triggering the 8b requests… and still is with this branch

Screenshot 2024-05-23 at 17 52 26

You are also returning 206 responses to all videos, regarding of whether a range-request was made. While mostly harmful, this is does not respect HTTP

@@ -161,6 +177,11 @@ struct URLContent {
return mime
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is our purpose? Is this related to Range-requests?


import Foundation

extension Date {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, related to ranges or not?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is related to the returned response header, eg. as on your screenshot, we have the Response:

Last-Modified: Thu, 16 May 2024 11:38:20 GMT

in order to have the date of the ZIM file formatted the same way, we need this change.
Again, if you think this is not needed, I can remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it's fine ; just wanted to make sure it was a side thing

/// As a result of the large volume of small requests, CPU usage will be very high,
/// which can result in app or webpage frozen.
/// To mitigate, opting for the less "broken" behavior of ignoring Range header
/// until WebKit behavior is changed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure about this? I am still seeing the 8b range requests on this branch, with mp4 videos. webm videos did not trigger those small range requests…

self?.sendHTTP404Response(urlSchemeTask, url: url)
self?.stopFor(hash)
return
}
self?.sendHTTP200Response(urlSchemeTask, url: url, content: content)
if isVideo {
self?.sendHTTP206Response(urlSchemeTask, url: url, content: content, start: start, end: end)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only apply to but also Apply to ALL videos

@kelson42
Copy link
Contributor

kelson42 commented Jun 1, 2024

Waiting that #784 is properly implemented to move forward.

@kelson42 kelson42 marked this pull request as draft June 2, 2024 03:18
@kelson42
Copy link
Contributor

kelson42 commented Jun 6, 2024

ThisnPR shiukd be rebased and completed has nothing else is blocking.

@BPerlakiH
Copy link
Collaborator Author

Closing in favour of #894

@BPerlakiH BPerlakiH closed this Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support range requests for video content
4 participants