Change video quality in progressive download sources #342
Comments
|
I totally agree with Julian. At the University of Bern we currently have over 75000 videos in Opencast, encoded in three different resolutions. We are currently using Paella Player 6 and progressive download to play the videos. |
|
HI Julian and Sascha At Valencia we have a similar issue with the legacy videos, and we do have a plugin that allows Paella Player 7 to work with progressive downloads. However, it has several issues, most of them related to changing resolution while playing a video. In the current state, changing the resultion does a full reload of the interface and goes back to the beggining. Also, going to fullscreen may trigger the same effect if there is a resolution change involved. We didn't found a good solution for those, and because of that we dropped support of progressive downloads in PP7. Of course we may share the plugin, and you will be welcome to improve it. However, we are not eager to provide long-term support of it. Maybe we may set up a meeting next week to discuss options |
|
Meeting sounds good. 😄 I'll just email you with a few suggestions for an appointment if that's ok with you, @turro. |
|
Unfortunately, I'll be on holiday next week. But of course I'll be interested in the outcome of your discussion. |
ferserc1
added
invalid
|
Dynamic quality change in progressive download videos was abandoned in paella-core because of the problems it caused. In the current context it is even impossible to implement on some platforms, due to the restrictions imposed by browsers with autoplay videos. To make this resolution change, the video source must be replaced, playback must start and jump to the previous time instant. There are several actions that must be done asynchronously, and although the main action is triggered by the user, after the first asynchronous response it is usual that the browser blocks the action. This is detailed in the presentation document: https://paellaplayer.upv.es/#/doc/paella_player_7_presentation.md Because of all this, this feature will never be officially implemented, but remember that in case you don't mind dealing with all these problems, you can implement your own video plugin: |
Fixes polimediaupv#342 I based this on db5dfce1 [1] but had to add additional changes. A few notes. For one, it is not sufficient to pause & resume each video on its own when changing the quality. Everything has to be stopped, all videos have to be loaded in the new quality settings, and then all have to be resumed. That's why changes in `StreamProvider` were necessary. I also changed that all videos are loaded simultaneously instead of serially, like before. This should make quality switching a bit faster. Another change I had to do is move the `autoplay` attribute thingy. I first thought that autoplay couldn't possible be important if it is stopped immediately anyway. But I too found weird behaviors in Chrome and FF when first playing the video. The time sync was triggered a few times, making one of the two videos jump a few times. I am not 100% sure why that happens, but with the autoplay it is indeed fixed. However, the `.pause()` in `waitForLoaded` posed a problem for quality changing. It always confused the "playing state" after changing the quality, as some videos got randomly paused. I solved this by just moving the autoplay attribute to `loadStreamData` and also resetting it there. One final change is that in `loadStreamData`, `waitForLoad` is not used anymore, but the `canplay` event is used, which is more appropriate for that use case. [1]: miesgre/opencast@db5dfce
Fixes polimediaupv#342 I based this on db5dfce1 [1] but had to add additional changes. A few notes. For one, it is not sufficient to pause & resume each video on its own when changing the quality. Everything has to be stopped, all videos have to be loaded in the new quality settings, and then all have to be resumed. That's why changes in `StreamProvider` were necessary. I also changed that all videos are loaded simultaneously instead of serially, like before. This should make quality switching a bit faster. Another change I had to do is move the `autoplay` attribute thingy. I first thought that autoplay couldn't possible be important if it is stopped immediately anyway. But I too found weird behaviors in Chrome and FF when first playing the video. The time sync was triggered a few times, making one of the two videos jump a few times. I am not 100% sure why that happens, but with the autoplay it is indeed fixed. However, the `.pause()` in `waitForLoaded` posed a problem for quality changing. It always confused the "playing state" after changing the quality, as some videos got randomly paused. I solved this by just moving the autoplay attribute to `loadStreamData` and also resetting it there. One final change is that in `loadStreamData`, `waitForLoad` is not used anymore, but the `canplay` event is used, which is more appropriate for that use case. [1]: miesgre/opencast@db5dfce
Fixes polimediaupv#342 I based this on db5dfce1 [1] but had to add additional changes. A few notes. For one, it is not sufficient to pause & resume each video on its own when changing the quality. Everything has to be stopped, all videos have to be loaded in the new quality settings, and then all have to be resumed. That's why changes in `StreamProvider` were necessary. I also changed that all videos are loaded simultaneously instead of serially, like before. This should make quality switching a bit faster. Another change I had to do is move the `autoplay` attribute thingy. I first thought that autoplay couldn't possible be important if it is stopped immediately anyway. But I too found weird behaviors in Chrome and FF when first playing the video. The time sync was triggered a few times, making one of the two videos jump a few times. I am not 100% sure why that happens, but with the autoplay it is indeed fixed. However, the `.pause()` in `waitForLoaded` posed a problem for quality changing. It always confused the "playing state" after changing the quality, as some videos got randomly paused. I solved this by just moving the autoplay attribute to `loadStreamData` and also resetting it there. One final change is that in `loadStreamData`, `waitForLoad` is not used anymore, but the `canplay` event is used, which is more appropriate for that use case. [1]: miesgre/opencast@db5dfce
Fixes polimediaupv#342 I based this on db5dfce1 [1] but had to add additional changes. A few notes. For one, it is not sufficient to pause & resume each video on its own when changing the quality. Everything has to be stopped, all videos have to be loaded in the new quality settings, and then all have to be resumed. That's why changes in `StreamProvider` were necessary. I also changed that all videos are loaded simultaneously instead of serially, like before. This should make quality switching a bit faster. Another change I had to do is move the `autoplay` attribute thingy. I first thought that autoplay couldn't possible be important if it is stopped immediately anyway. But I too found weird behaviors in Chrome and FF when first playing the video. The time sync was triggered a few times, making one of the two videos jump a few times. I am not 100% sure why that happens, but with the autoplay it is indeed fixed. However, the `.pause()` in `waitForLoaded` posed a problem for quality changing. It always confused the "playing state" after changing the quality, as some videos got randomly paused. I solved this by just moving the autoplay attribute to `loadStreamData` and also resetting it there. One final change is that in `loadStreamData`, `waitForLoad` is not used anymore, but the `canplay` event is used, which is more appropriate for that use case. [1]: miesgre/opencast@db5dfce
Paella 7 lost the ability to change video quality for progessive download sources. This is confirmed by the docs in the section "Features lost since Paella Player 6.x" (second paragraph there).
This is slowly coming up as an issue for a couple of our clients to the point where it is blocking them from upgrading. Yes, HLS might be the future, but not everyone is there yet, plus many institutions still have large collections of media published as progressive download that they would like to continue to offer without having to republish and/or -encode everything.
Accordingly, we consider this a rather essential feature for the standard Opencast player, and my question is: Are there any plans to reintroduce it? And if not: Would you be opposed to someone from ELAN trying their hand at contributing the feature?
The text was updated successfully, but these errors were encountered: