Video preloading issue

HI All,

Well I have a bit of a problem with video. I have a course that is essentially video based, it is really simple and quite straightforward in its structure. HTML5 output only.

It is made up of 4 scenes each with multiple slides.

Scene 1 -  contains an intro vid and a menu screen.

Scene 2 -  has the collection of videos, 9 in total. ALL on SEPARATE slides each set to play when clicked. So no auto-playing.

Scene 3 -   same as the previous but with 5 videos.

Scene 4 -  selection of mqcs.

From a functional point of view all runs fine on a per slide and per scene basis. However, when running the course as a whole there is an issue. Its tricky to explain but basically when you are on the first scene > menu slide (that contains NO VIDEO) you can click anywhere and one of the video from scene 3 starts to play but cannot be seen.

From what I can tell Storyline outputs an offscreen div structure with video tags for each video featured in the course. Each of the video src is base64 encoded with a preload attribute set to auto. I assume that this is used as some sort of preloading/management sequence.

However, one of the videos in the list is not base64 encoded, its ‘src’ is a full URL to a .mp4 and that is the video that is ‘appearing’ on this slide its not meant to. It looks like if a video is “active” then it’s a full url and not base 64 but that video does not feature on this slide at all so I’m not sure why it's being included at this point.

I’m on a very tight deadline and this has potential to cause some real headaches. I have some further “trial and error” tests to dig a bit deeper into it but I’m hoping some has a “just do this…x” answer out there.

Side note: I’ve been testing this for that last few days and have not noticed it until now – which happens to be the first time I’ve tested after updating with yesterdays Storyline update. Not saying that its related – just sayin’ 

5 Replies
Chris Ridley

Further tests:
1 - completely deleted and re-built the menu screen - same issue
2 - tested in Preview and web-only locally - same issue
3 - uploaded to Review - same issue
4 - used custom js manage the z-index and positioning as it looks like a clickable element - same issue

Into writing custom js to disable clicking on elements outside the main presentation div but - really don't want to be heading down this road for such a simple course. 

Ashley Terwilliger

Hi Chris,

It sounds like you've done a fair amount of trial and error tests already! I haven't heard of a recent issue with Update 17 and videos, but it was released just a couple days ago.  

Have you made any changes to how things are preloading, or you're letting Storyline's default settings remain? If you could share a copy of this .story file we can give it a test in a few different versions and environments (speaking of, where are you uploading/testing the content? Also what browsers have you tested it in?).

Also, if we figure out it's update 17 related, our Support Engineers can get you rolled back to an earlier update. 

Chris Ridley

Thanks for the Reply Ashley.

Unfortunately, I can’t share the file as we are legally tied up quite tight with regards to the content of the course – I can’t even showcase it or use it in a portfolio context. Trust me I’d love to pop the file over but in this case, we simply can’t.

The issue occurs in all 3 major browsers. I’ve not modified anything with regards to preloading – I just assumed its preload related when doing some digging – I may be way off in that assumption.

It seems that this one video is present in the video-pen div as a .mp4 even when it’s not required for the slide that you are viewing. I have added some additional css to overwrite the ‘offscreen’ class so that its absolute position value is top-left 0 0 (from its -9999px value) to bring it into view and sure enough the video appears. I’ve even set the display value of the div to hidden but it is still clickable, point events none and even pushed it back through the z-index so that it sits under the presentation div but it still plays the audio/video when clicked.

I have a possible fix but however, the tricky thing is that I really don’t want to do any post publish JavaScript modifications. I have added some js which adds some additional js and css at runtime to counter the issue – which kind of works (untested in all browsers - chrome only at the mo) but is very “hacky” I’m also not comfortable leaving these in for final delivery as there are some parts of our client agreement that states we won’t do any custom code modifications.

I know this will in all likely hood will not really help in finding a solution but just thought I’d share my findings in case it points to a possible area for investigation or sparks an idea.

I have further testing lined up tomorrow where we will be re-placing all the vids so I’ll test again. 

Ashley Terwilliger

Hi Chris, 

We did release an update to Storyline 360 on Friday afternoon to fix a few issues, but I don't know that it was something that you would have run into. You can look at downloading the latest update here. 

Let me know what your further testing reveals! I understand if you're not able to share your file, but since it's the best way for us to demonstrate the problem and document a defect, we'd happily accept a .story project shared here privately if you change your mind. Our team can sign an NDA if needed. 

Chris Ridley

Hi Ashley, Just a follow up on this - the course has been out for review so testing was halted for a few days until the content review was complete. 

In that time I did apply the follow-up update that came out on the 22nd. I have removed all the javascript that I added to modify the "vid-pen" div and re-published. So far my initial testing looks like all the video src are base64 and there are no videos playing where they shouldn't. 

I did notice in the release notes that "Fixed: Videos would sometimes play on the wrong slides in HTML5 output." Which sounds like the issue I was having, So I'm hoping that this has fixed the issue.

If not I'll follow up here on this thread - but so far so good