The njump.me page contains the link to the .mp4 as
https://cdn.onlynostr.club/f3f289b9840a994238f58217620bdee08cf53f8f9c5e8f98dea87ad4376601da.mp4
If you download that file you get a corrupt video file.
Only the first 36 frames decode successfully.
Edit: Oh, I think now it’s a iOS Safari bug where it thinks the video is an image and the video player is "playing" an image … will try to look at it using the m.stacker.news link or on my desktop later.
This is indeed served as video/mp4 by all browsers, some skips to 1:22 timestamp others just plays it. If it was meant to be an image then I'm scratching my head a bit because it could be either related to imgproxy OR it's the 206 Partial Content (a consequence of caching) that tricks browsers into thinking it's a video.
but if it was meant to be a video I see it just fine
If I skip the proxy and visit m.stacker.news (see link above), I am watching the same "video". So I assume it’s a Safari bug that we need to work around because it should have been served as video/mp4 but I didn’t verify yet (I’m still in bed).
This also happens if I open the link directly in Safari and not just in the PWA.
It is served as Content-Type: video/mp4 by iOS Safari though! (I'm using dev tools via usb) and the video is showed the same way consistently on other browsers, so that's why I thought the video got corrupted/recorded bad
https://cdn.onlynostr.club/f3f289b9840a994238f58217620bdee08cf53f8f9c5e8f98dea87ad4376601da.mp4If you download that file you get a corrupt video file. Only the first 36 frames decode successfully.Content-Type: video/mp4by iOS Safari though! (I'm using dev tools via usb) and the video is showed the same way consistently on other browsers, so that's why I thought the video got corrupted/recorded bad