following

Following as well.

I have also raised a support ticket with examples, I will post any responses

@Gary Jarvis What video container are you actually using? .mp4 or mpeg-2? Are you loading this video into Learn as a video file or within a Scorm file? Is it hosted some where else, like on a CDN or Vimeo, YouTube, etc?

I was watching streaming TV last night and noticed a similar behavior and I thought “oh, the movie is just building its buffering cache” and then I thought of your issue. It sounds like this isn’t caching very well. If you are using Mpeg-2 the higher quality, etc. might be the source of the slowness in the caching.

https://www.winxdvd.com/video-transcoder/mpeg2-vs-mpeg4.htm

Will be interesting to hear what Support has to say…

KM

we use MP4 and have done for around 400+ video’s

Response from support: However, this does not explain why then other 400+ videos only blur for a few seconds and these ones take 30 seconds ? 

Interesting comment re ideas suggestion, anyone else think this a good idea?

Hi Gary,
Thank you for contacting Docebo Support. My name is Stefano and I’d be happy to assist!
 
Thank you for reporting this situation about video blurring for the first 30 seconds, I totally understand the importance to have great video for the students and also the impact it can cause on you work in terms of time.
 
Just to recap, when you upload a video in the training material it blur for the first 30 seconds. In the past you used to upload video in H264 then only the first 5 seconds are blurred, but If you use an HEVC H265 codec it takes 30 seconds to become clear.
 
If so, checking the course you gave me, i tried to watch all the videos in that course and I can confirm to you that video were blurring for the first 10 seconds only (please have a look into the video I have attached).
 
After further investigation, and upon consulting with our Product team, I have been informed that this is expected behavior by our video player (third party library), the initial lower resolution is due to the fact that the video needs to be loaded and quality is auto adjusted based on available connection speed and quality.
 
As you can see from the below screenshot, the video's quality automatically is set to "auto" which is why it takes those 10 seconds to auto-adjust.

We found that if we manually adjust the Quality from "Auto" to another quality level the buffering/blurriness is much better, it is still visible to an extent but not for the entire 10 seconds. Currently, we do not have the ability to change the "Auto" to a specific resolution type to be forced onto a user.
 
Let me also share with you our guide about videos for future references:
https://help.docebo.com/hc/en-us/articles/360020128359-Uploading-and-Converting-Video-Training-Material
 
However, this can be submitted as a feature request. Docebo's Ideas Portal in Docebo Community is where you can submit feature requests as well as vote for and comment on ideas submitted by other Docebo customers and Docebo staff. In turn, your ideas are voted on and commented on. The ideas with the most support are then considered for implementation.
 
Please note that due to the volume of product enhancement requests we receive, we are unable to guarantee specific feedback about the approval of this enhancement request. However, you can monitor the Product Updates page for news of new feature implementations.
 
Let me know if the above answers your question, or if there is anything else we can assist with.
 
Kind regards
 
 

Stefano R
Technical Support Analyst
Docebo Support

Adding to this. We’ve got some videos that are doing the same behavior - but the ‘blur’ time is in exact multiples of 10 seconds, and it’s not 10 seconds from wherever you put the playhead, it’s the exact 10 second, 20 second, or sometimes 30 second mark from the beginning of the video (0:00).  If I put the playhead at 8 seconds and hit play, it’s blurry for 2 seconds, not 10, so something in the ‘auto resolution’ code is a little wonky.  It also seems to me that if it’s a buffering situation, once that first buffer has happened, if I go back to the beginning it -should- now be clear, but it’s not.  Again, it will stay low-rez til it hits that 10 or 20 second mark and then everything is nice and clear.
Also, all of the above only happens in full-screen mode.

It would be really nice if we could default our players to “HD” quality instead of “Auto”, as many of our videos are software demos where you need to see some relatively fine detail on screen, or set the video player to buffer enough to play in full rez before the video begins playing.   Our videos are H.264 with modest data rates (many exported out of Camtasia) generally in the 220-360kbps range.

@kgmeloy  Are your bit (data) rates fixed or variable? Fixed is the preferred method, but perhaps try ‘the other’.

Is it only Camtasia that creates these issues, or any? Can you convert your content to another platform for a test?

@KMallette - that’s a good question. I -think- Camtasia exports at a constant bit rate, but the only setting like that I can see is for audio, which is fixed.  The video export settings are pretty basic compared to what I’m used to in Premiere or DaVinci, there’s no constant vs. variable bit rate dialog:

 

So I’ve had my own ticket open on this, and basically gotten the same response @Gary Jarvis received, expected behavior, buffering, etc.

There’s a bit about this that makes no sense to me - the explanation is that the first 10/20 seconds of low-rez is the player essentially blasting through the content and sussing available bandwidth to determine what quality the video can play back at, and it takes a second (well, 10 seconds) to determine it.  
BUT - if that’s the case, no matter where I put the playhead before I press ‘play’, I should get that 10 seconds of low-rez.  But I don’t.  If I drop the playhead a minute in, it’s crystal clear instantly.  It’s only blurry during those initial 10 or 20 seconds as outlined in my post above.

I’ve been told addressing this issue is not something that is on the product update roadmap.

Where this is especially concerning to our use of the video player - we had intended to make a bunch of 7-15 second micro-videos showing users how to perform common tasks in our SaaS software platform, which mostly will be on text-heavy screens.   Since the video stays low-rez for at least 10 seconds, then a 7 second micro-video will -never- be clear unless the users themselves set the resolution manually to “HD”.  I tested hoping a shorter, smaller video would not suffer, but the 12 second one I tested with behaved exactly the same.  10 seconds of low-rez, 2 of high.  Also due to the nature of our business, hosting videos on another platform is not going to fly, so we’re stuck and months of planning may have to be scrapped.  

As a shout term fix we added the same 10 sec intro video to the start of all our operational videos. not the perfect solution but it worked.

Gary

That’s what we’ve done on a lot of our videos - there’s often intro info that doesn’t require hi resolution, but there are many others that weren’t created that way. We’ll probably have to retrofit them.  Those proposed micro-videos though, a 10-second graphic for a 7-second video is, well…. ;)

A side note…. Is it only my that are a bit frustrated about Docebo always claiming that “this is expected behavior” when ever I raise a case about some feature not functioning as it should, and the suggest I raise a new idea...

Besides that, could it be that caging is initiated in the background immediately when you start moving the playhead?

Also when the Quality is set to auto, I guess the player always start out on a low bitrate in ordre to verify what BW you are on before it settles down for a bitrate that is manageable within the BW you have available.
If the player starts out in FullHD every time I am convinced that som of the learners with low BW vould complain that they have bad quality video, as the video would then have bad sound, clipping freezing nd blurry pictures because of to little BW available on the user side

Great description of the problem. I did the same tests and found the exact same behavior. 

Has anyone tried a different video player to address this? We’re new to Docebo, but my impression is that if we use a content authoring tool we can get some additional capabilities for the video playback and maybe that new player will avoid this problem?

For example, we want learners to be able to rewind *and* fast forward to the furthest point they’ve watched. If they’ve completed the course, they should be able to move freely in the course. Such capabiltiy is, surprisingly, not available in Docebo. We’ve been told that using other content authoring tools, such as Rise & Storyline, enable that behavior. I don’t understand the details yet, but I believe this also means the video player will no longer be Docebo’s native player.