When a Hype project makes more than 16 calls to video elements (either all the same or differents):
macOS : all videos will play
iOS: only the 16 first will play. The 17th and higher will show a dark screen.
16 = one byte : Does this means that a one byte index still exist somewhere ?
The post “Videos stop loading after visiting many scenes” does not quote the fact that the problem occurs for the exact number of 16 videos.
Is this a known bug ?
Any suggestion for a workaround ?
I forgot to mention that there is no such problem with Android, therefore there is no reason for such a limitation.
Furthermore, if you call the same video 16 times, you should not allocate 16 times the memory.
Yes I will try to contact the OP of the other thread.
Thank you.
So the only way so far I can get it to work is by adding a Rect and putting the video tags etc inside.
I then make it a persistent Symbol across all scenes.
I then use JS to load the Video dynamically by setting the videos src attribute on scene loads.
I’m the poster of “Videos stop loading after visiting many scenes”.
Our project has 15 videos. All videos are in persitent symbols.
Playing video’s is triggered with JS, not autoplaying.
We did extensive testing on this and it appears to be a memory issue:
-playing more than 15 video’s triggered the behaviour
-also, loading scenes containing the videos triggered the behaviour after about 30 scenes, even if the video’s were not playing.
-Going back and forth between 2 scenes containing video also triggered the behaviour after 30 accumalative scene loads
We were not able to fix the issue.
In the end this was our workaround:
-a scene-counter (for mobile only) that reloads the whole project to the current scene after 30 scenes or 14 video-plays
-“create offline application cache” is used, so that reloading times arre acceptable.
First of all I create an object video using Hype preset
Gives an unique ID to the video object
transform it as a persistant symbol and copy it on all the scenes I need it
Create a function to replace the source attribut of the video object on scene load.
It seams to work on iPad and iPhone …
here is the code :
var video = hypeDocument.getElementById("film");
//get scene name
var scenename = hypeDocument.currentSceneName();
var filmname = "...";
switch (scenename)
{
case "01":
filmname="Video65.mp4";
break;
case "02":
filmname="Video70.mp4";
break;
case "03":
filmname="Video73.mp4";
break;
case "16":
filmname="Video76.mp4";
break;
case "17":
filmname="Video70.mp4";
break;
}
video.src='${resourcesFolderName}/' + filmname;
video.play();
Yep it does..[quote="MarkHunte, post:5, topic:9541, full:true"]
So the only way so far I can get it to work is by adding a Rect and putting the video tags etc inside.I then make it a persistent Symbol across all scenes.
I then use JS to load the Video dynamically by setting the videos src attribute on scene loads.
[/quote]
I am not convinced the initial bug is in Hype if that is what you are saying.
I have seen the same complaint from people creating Apps for iOS using Xcode and the Apple APIs for video in Objective - c and Swift. i.e not webkit or HTML
May be, but this bug appears using internal code of Hype.
May be Hype does not purge from memory instance of video when you move from one scene to another one, if this is true we have too many instances of video object on a single HTML page, and there’s surely a limitation in iOs about numbers of video you can have on a single page.
You may be right in why this is happening in Hype projects.
More a behaviour issue than a bug though. I just did a test of a page made manually outside of Hype. The page had 18 video elements pointing to 1 and the same video. The last two do not load.
There are two workarounds . The one we tested and @willemcc illemcc
In all my days I haven't seen anything like this -- it does appear to be a bug
Probably in iOS, but we can easily protect against this bug to keep people from hitting it. What I think is happening here is that something pertaining to video elements, iOS, and memory limits is keeping the 17th video from loading. This is likely not part of the webkit team's test suite! Usually I see these types of bugs in iBooks' built-in HTML viewer.
Thank you for your answer.
There are now two options for the Hype animations we published online (see below) just before discovering the problem with iOS:
either we wait for an upgrade of Hype if this is reasonably fast enough
or we ask for a budget for implementing the workaround proposed by @Francis.
What is the expected delay for a correction of the bug?
I tested the last release of Hype but unfortunately the bug remains the same. As I wrote in my previous post I’ve found a workaround : only use one instance of a global video player and use javascript to replace the source attribut of the video object on scene load.
Can we except a correction soon ?
Thanks