-
-
Notifications
You must be signed in to change notification settings - Fork 542
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
MP4 video playback without JavaScript #634
base: master
Are you sure you want to change the base?
Conversation
VIdeo streams work nicely with both ff and chromium. |
Oh, does it work if you swap the position of the orig and non-orig routes? I did it because I figured the order might have a tiny impact on performance, but didn't properly test it |
That works 👍🏻 |
@@ -90,38 +90,38 @@ proc renderVideo*(video: Video; prefs: Prefs; path: string): VNode = | |||
let | |||
container = if video.description.len == 0 and video.title.len == 0: "" | |||
else: " card-container" | |||
playbackType = if not prefs.proxyVideos and video.hasMp4Url: mp4 | |||
playbackType = if prefs.proxyVideos and video.hasMp4Url: mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
playbackType = if prefs.proxyVideos and video.hasMp4Url: mp4 | |
playbackType = if video.hasMp4Url: mp4 |
to keep non-proxied videos working
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They don't actually work every time. With the way Twitter serves mp4, a "cache miss" uses chunked transfer-encoding which results in 1 second playing and the video freezing until reload. That's what the retry logic is for in the media router, streaming the file without waiting for the cache is impossible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If proxying videos is disabled, your change would make it impossible to play videos at all, since browsers can't play m3u8 without hls.js (which is bound by CORS, so it only works if videos are proxied). I never experienced the transfer-encoding bug you mentioned, but IMO having it fail some of the time is better than having it fail all the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would hls.js not be there? I tested this thoroughly, the transfer-encoding bug actually happens quite often both in the browser and when fetched via a headless client, it simply doesn't work. If you go to to the search page and filter native video it's fairly easy to hit a cache miss.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would hls.js not be there?
it is, but it doesn't work when proxying is disabled (as far as i understand, it needs CORS headers to be sent from 3rd party domains (like video.twimg.com) in order for its requests to not get blocked by the browser).
but this is besides the point; I'd like to be able to see twitter videos even when javascript and proxying are disabled. and this works right now, and won't if this patch gets committed as-is.
I tested this thoroughly, the transfer-encoding bug actually happens quite often both in the browser and when fetched via a headless client, it simply doesn't work.
If you go to to the search page and filter native video it's fairly easy to hit a cache miss.
just tried that. these are the headers i get served from video files (not proxied): https://pastebin.com/yL485srS the first one is x-cache: MISS
, the second one is x-cache: HIT
. neither are sent using transfer-encoding:chunked and play fine. I went through multiple pages of /search?f=tweets&q=&f-native_video=on
. I could reproduce this on my private instance (us-hosted) and nitter.net by disabling video proying and enabling mp4 playback with the same results.
I'm not saying you're wrong, but maybe we are talking about different things? maybe an alternative would be this:
playbackType = if prefs.proxyVideos and video.hasMp4Url: mp4 | |
playbackType = if not prefs.hlsPlayback and video.hasMp4Url: mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe their US caching works in a different way than in the EU, dunno, but I know for a fact I ran into this chunked encoding issue which broke video playback a lot of times even while proxying through Nitter. It happened when I was working on it in 2019, and it happened a week ago when I worked on this version. I'd be ok with some sort of "Always stream MP4" preference disabled by default, but serving non-proxied mp4 from Twitter is too broken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be ok with some sort of "Always stream MP4" preference disabled by default,
that would be fine for my needs. thank you for considering that!
i also need to retract my earlier statement regarding hls.js requiring proxy: twitter actually sends the required cors-headers (access-control-allow-origin: *
). i must have misremembered them not provididing those.
Signed-off-by: r3g_5z <june@girlboss.ceo>
Signed-off-by: r3g_5z <june@girlboss.ceo>
No description provided.