4GB file size workaround for 32bit OS breaks video streaming in iOs clients
rmufr opened this issue · 6 comments
Using Sabredav embeded with Nextcloud 13 (v4.2.3), on a RPI3 Raspbian stretch server (32bit OS). Webserver is Nginx 1.14.0, fastcgi php-fpm 7.0.30.
Video playback in iOs requires partial content requests (range) support.
When starting a Video playback , from the Nextcloud iOs app (>v2.22) or from the Nextcloud Web UI within iOS Safari browser, both clients start with a partial content GET request of the first 2 bytes.
The #74 change ignores the Content-Length header info, resulting in a response body with the entire video file, but with response headers saying "range: bytes 0-1/filesize" and "content-length: 2".
This mismatch in response information headers and body content is not supported by the iOs client. The client breaks the connection and won't play any image.
👍
Could you provide a failling unit test describing your issue or anything similar which can be used to reproduce your issue?
Could you work on a solution which works for videoastreaming but does not break files > 4gb?
I'm not able to provide a unit test, unfortunately. I've just followed @rmufr 's recommendation and got streaming on my iOS (running nextcloud on a raspberry pi, as described above).
Hi,
The simplest way to reproduce, talking only about what I experienced, woud be
- have a 32bit OS sabre server, and an mp4 video file (<2GB) suitable for HTML5 video playback (e.g. h264/aac)
- on this server, serve http requests with an Nginx (eg. v14.0) server. I didn't test with Apache.
- from a iOs device, use Safari browser , try to playback the video file using the an HTML5 embeded video link. (As it happens with Nextcloud WebUI).
My use case is :
- Nextcloud v13 or v14, installed on a RPI3/raspbian stretch., up to date, default conf
- Webserver Nginx v14.0 or v13.x also running on the RPI , default conf.
- iOS Client = iPhone 7, Nextcloud WebUI in Safari Browser. Tested also with iOs 10, 11, 12. iPhone and iPad.
I'm not skilled developer to propose a target solution, but on my opinion, an acceptable solution would be to go through te 32bit OS workaround only if 32bit OS AND the requested stream size really is >2GB, and not upon the only 32 bit OS condition.
@rmufr Thanks for the good preparation / issue-description
@phil-davis With #184 being merged into version 5.1.5 this issue can be closed IMHO
Thank you guys