Videos in shared folders could not be played #45

Closed
kriztan opened this Issue Apr 11, 2016 · 21 comments

Projects

None yet

6 participants

@kriztan
kriztan commented Apr 11, 2016

Hi, i've a problem with OC 9 and a shared folder which contains videos. The MP4 files could not be played with the video player, images inside this folder where displayed correctly.
I've tested it with Chrome on a Windows 7 mashine. The videos could be played after logging in, but not when they are insinde a shared folder.

@timmmmmey

Same here. 9.0.1 stable

@Instagit
Collaborator

Could you make a screenshot that shows the problem?

@timmmmmey
timmmmmey commented Apr 18, 2016 edited

For sure. Chrome's javascript console doens't show any errors ..
github

@Instagit
Collaborator
Instagit commented Apr 18, 2016 edited

I can reproduce the problem now with Chrome on Windows 7, but only for some videos.

What I can say so far is that when the error occurs, the browser gets two replies from the server for the video instead of only one.

Thanks for the report, we're looking into this and I think playing videos directly from shared folders is generally still being worked on.

#18 is probably somehow related.

cc @LukasReschke

@Instagit Instagit added the bug label Apr 18, 2016
@timmmmmey

I can reproduce it on:
Windows 10 x64, Chrome (current)
Android 5.1, Chrome (current)
Fedora x64, Chrome (current), Firefox (stable) is working (!)

And yes, the problems occours only on a few files, I grabbed some examples and it seems no codec problem. The following 4 files were tested and were working as logged in user. With a shared link as a guest, only two files were working. And File 2 and 4 had the same codec (source: avprobe)

Not working:

  • Stream #0.0(eng): Video: h264 (Constrained Baseline), yuv420p, 408x720, 676 kb/s, 30 fps, 30 tbn, 60 tbc (default), Stream #0.1(eng): Audio: aac, 48000 Hz, mono, fltp, 95 kb/s (default)
  • Stream #0.0(und): Video: h264 (Main), yuv420p, 640x360, 703 kb/s, 30 fps, 19200 tbn (default), Stream #0.1(und): Audio: aac, 44100 Hz, stereo, fltp, 62 kb/s (default)

Working:

  • Stream #0.0(und): Video: h264 (Constrained Baseline), yuv420p, 212x320, 43 kb/s, 15 fps, 15360 tbn, 30 tbc (default), Stream #0.1(und): Audio: aac, 22050 Hz, mono, fltp, 36 kb/s (default)
  • Stream #0.0(und): Video: h264 (Main), yuv420p, 640x360, 687 kb/s, 30 fps, 19200 tbn (default)
    Stream #0.1(und): Audio: aac, 44100 Hz, stereo, fltp, 59 kb/s (default)
@Instagit
Collaborator

For some files, the server streams the data (works) and for others, it sends everything at once (doesn't work). I need someone who knows more about the video handling, but that seems to be the problem.

@LukasReschke @jancborchardt

@jancborchardt
Member
@PVince81
Contributor

@timmmmmey is this only for shared files or does it also happen for non-shared ones ?

Regarding codecs, some codecs might require to seek to the end of the file to get important information. I suppose the video player should then do a Range request to the end of the file for that. Range requests should work.

Please check the network console for the working vs non-working files, maybe there's a difference in the HTTP requests that could pinpoint whether there's an issue on the server, possibly with range requests.

@timmmmmey

@PVince81 All the 4 files are working, if I login and use the gui to find the path. If I use the shared-link, then 2 are not working.
As @Instagit already pointed out, the not-working videos have 2 download requests.

Not working:
notworking
Working:
working

@PVince81
Contributor

Can you pick one video that works in regular mode and breaks in public mode. Then check the "Range" header in the network console.

I suspect that in publicpreview mode the Range request doesn't work properly.

@PVince81
Contributor

The call in question is likely to be the one with "download?..."

@PVince81
Contributor

At first I'd have said the video player needs to be adjusted to use the public Webdav URL instead, which supports Range requests. However, this endpoint has some issues in some browsers due to the fact that it requires either a username to be passed in the URL or an "Authorization" header to be set, and both aren't supported by the video API.

See owncloud/core#21787 (comment)

@timmmmmey

Okay, that looks strange
First call: Range:bytes=0-
Second call: Range:bytes=48-2341567

@timmmmmey

And for a video thats works in a shared link:
First (and only) call: Range:bytes=0-585642

@lenz1111
Member

This is due to an unsupported http range requests. Temporary solution (tested on 9.0.1) - that add support for this:
owncloud9_download_http_range.zip

@jancborchardt
Member

@lenz1111 if that fixes it, can you open a pull request to this repository please? :) If you need any help, you can ask. Or you are welcome in our IRC channel #owncloud-dev on freenode IRC.

@PVince81
Contributor

I had a look t the patch already and might need a bit of tweaking, but best to discuss this in a PR.
Thanks.

@lenz1111
Member

Opened a pull request with my modifications owncloud/core#24354
Pull request is for core module (not files_videoplayer)

@jancborchardt
Member

@lenz1111 aaawesome! Welcome to the ownCloud community! :)

@PVince81
Contributor

Due to a little rebase incident, the PR has moved here: owncloud/core#24750 😄

@PVince81
Contributor

Please try again with 9.0.3RC1, public share range requests were implemented there

@PVince81 PVince81 closed this Jun 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment