Preloading too much video data

[PVince81]

When opening the view, there's a preloading mechanism that will preload previews for files that haven't been viewed yet.

I'm not sure how this works for videos, in theory it should only fetch a single frame.

What I observed is that the bytes range is quite big and a few previews take a bit more than 1 MB:

@felixheidecke is this by design ? Is this maybe the way the video element works by default ?

I guess it's not easy to fetch the first frame of a video as one might not know in which byte range it is. For some format you might need to read the end of the file to access metadata to be able to then seek to find said frame.

I'm fine closing this as by design if there is no improvement possible.

[PVince81]

note: this was observed while testing https://github.com/owncloud/files_mediaviewer/pull/36 in public view mode

[felixheidecke]

It's a regression of the "first video not playing" fix. Will get to it.

[PVince81]

did you fix this in #36 ? I didn't retest it.

else can be scheduled later

[PVince81]

I guess the problem is mostly that one needs to find a keyframe to be able to render video data.

For some reason it seems the HTML5 component is trying to load in the middle of the video, even though I moved the "moov" token to the beginning of the file.

Maybe the proper solution is to have the preview system to deliver a pre-generated preview for videos, like https://github.com/owncloud/core/issues/24480

[PVince81]

just now I have a case where it seems to download the full video (66mb) even though I did not play it

[PVince81]

I just found this article: https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video/

it seems that Chrome defaults to either preloading metadata or a few seconds of video, but not the full one.

we could try setting preload="metadata" to enforce the same behavior on all browsers

[PVince81]

possible fix: https://github.com/owncloud/files_mediaviewer/pull/70