When publishing a storyline 2 file that was created in storyline 1 the SCORM output zip file is about 3 times larger. Storyline 1 78 mg... storyline 2 222 mg. There were no changes made to the file other than it was opened in storyline 2. There are limits to the size of SCORM assets that I can use in my LMS so this is creating an issue.
I've been following this Forum Thread from afar, and recently stumbled across an explanation for the compression differences that you all have observed between Storyline 1 and Storyline 2.
First, a bit of historical background:
When we released Storyline 1, we felt that compressing large video files for low-bandwidth environments was really important. Our message to our customers was, "When inserting a movie, we recommend using a high quality video. Then let Storyline take it from there."
In line with this philosophy, we felt that the dimensions of a video file should never be larger than the dimensions of its parent slide. Therefore, when inserted, all videos were encoded so that they were no larger than the size of your story.
Now, fast-forward to today:
We had overwhelming feedback from our customers to "Stop touching my video!" so we added a feature that allows customers the option of turning off compression altogether for MP4 videos created with baseline, main, or high profiles.
In order to stay true to the promise of disabling compression altogether, we needed to stop resizing our customers' videos at the time of insertion.
Of course, we still allow multiple levels of compression when publishing, but we're no longer going to resize your videos for you, which is what bought a lot of the efficiency gains in Storyline 1.
We're still working hard to optimize video compression in Articulate Storyline so you'll get the highest possible quality at the lowest possible file size, but my recommendation is that if your audience of learners is significantly bandwidth-constrained, you're going to want to optimize the dimensions of your video before you insert the video into Storyline.
An identical video smaller than the slide size in SL1 and SL2. Note that SL2 on the lowest setting is larger than SL1 on the highest setting.
Setting of 1:
SL1 - 284kbps SL2 - 1070kbps
Setting of 5:
SL1 - 497kbps SL2 - 1900kbps
Setting of 9:
SL1 - 989kbps SL2 - 3848kbps
It looks like the low end could use some tuning to bring the bitrates down for higher compression settings. Sounds like y'all are focusing on tuning it up. I'm really happy with the higher end (a setting of 9 really is 9) but the lower end doesn't allow for more compression at lower settings. Great work on the "hands off my video" - the low end needs to come down to SL1 levels with scales to SL2 levels on the high end and it'll be perfect.
Hmm... I'll need to test to make sure my test video wasn't proportioned larger than the slide. I used one of the WMV's that shipped with Windows as a test. Pretty sure it was smaller than the stage. Will confirm this evening.
Having said this, I inserted Wildlife.wmv into an SL1 .story project file and an SL2 .story project file that had both been increased to 1280 x 720 to double-check my theory, and then published at the various compression levels you mentioned above:
I guess that pretty-much blows my theory to heck, and I should have paid closer attention to your test above. It's still true that SL2 on the lowest setting is larger than SL1 on the highest setting.
I'll share this information with QA and see what they have to say. Thanks!
In the interest of openness, I wanted to revisit this thread with a bit more historical context. No real changes yet, but Seek First to Understand and all, right? :)
Storyline 2 was many months from shipping at that time, and we thought long and hard about whether or not to merge the same functionality into Storyline 2. In the end, we wanted consistency across our products, so we increased the quality in Storyline 2 as well. At that time, the Quality Slider had it's meaning changed, because video quality at the highest compression levels wasn't good enough.
The upshot is that the pendulum has probably swung from forcing our customers to conserve bandwidth, back to forcing our customers to preserve quality.
For now, we're going to continue to observe how this change affects our customers, so we'd encourage more customers to post within this thread or submit a Feature Request if this change is bad news for you and your learners.
In the interim, one possible workaround is to use the Don't Touch My Video feature to your advantage by pre-encoding the media to a size that suits your needs:
As long as the video is a MP4 file with a Baseline, Main, or High encoding profile (these profiles should be the default for most encoding programs out there), we will import that file without compression into the project.
You can then set Compression to None to instruct the publishing step to not perform any additional compression when published.
In doing so, you will be able to set the video to the exact size that you need.
...hope this is useful information, and we look forward to additional feedback!
To clarify the change implication, are you saying the functionality of SL2 has been added to SL1? Or did I misunderstand the explanation of the change?
Thanks Justin! Still thinking that scaling compression at the lower end of the scale would get it.
Maybe I'm not understanding the process used in SL. But it seems reasonable that a factor of compression scaling at the lower end of the scale could make it more like SL1 at setting 1 while retaining the banging (but huge) file quality at a 9 in SL2, with 5 hitting somewhere in the middle.
Thanks for sharing your input, Babette. We'll keep this thread updated with any developments.
We'd also welcome more information on the business need for lower quality videos. Is it an upper limit on the size of LMS content? ...a need to serve low-bandwidth learners? ...both? ...something altogether different?
I see this is an older thread, but we are just now starting to convert our SL files to SL2 and are finding what seem to be significant files size increases in our content files that do not contain any video (in fact some are just a few slides). This is causing long wait times for lessons to open when launched. Are there other factors we should be looking at besides video that is impacting size?
I wouldn't think that a course that's only a few slides would cause such a long wait for it to open - so I'd want to know a little more about where and how your users are viewing them. Do you know what browsers? Is the course hosted in your LMS or web server? What's the file size difference you're seeing from SL1 to SL2; is it just the .story file or the published output as well? If you've got a sample .story file from SL2 we can take a look and publish it to another testing site to see how that one behaves for you too! Just upload it here using the "add attachment" button or send it along to our Support Engineers here.
37 Replies
Hello, all.
I've been following this Forum Thread from afar, and recently stumbled across an explanation for the compression differences that you all have observed between Storyline 1 and Storyline 2.
First, a bit of historical background:
Now, fast-forward to today:
We're still working hard to optimize video compression in Articulate Storyline so you'll get the highest possible quality at the lowest possible file size, but my recommendation is that if your audience of learners is significantly bandwidth-constrained, you're going to want to optimize the dimensions of your video before you insert the video into Storyline.
...hope this helps, and have a Happy New Year!
Hey Justin -
I see the point here with video oversized. I'm not sure this is what Brian is seeing. Looking at the anecdotes here:
https://community.articulate.com/discussions/articulate-storyline/storyline-2-scorm-zip-files-much-larger#reply-227737
An identical video smaller than the slide size in SL1 and SL2. Note that SL2 on the lowest setting is larger than SL1 on the highest setting.
Setting of 1:
SL1 - 284kbps
SL2 - 1070kbps
Setting of 5:
SL1 - 497kbps
SL2 - 1900kbps
Setting of 9:
SL1 - 989kbps
SL2 - 3848kbps
It looks like the low end could use some tuning to bring the bitrates down for higher compression settings. Sounds like y'all are focusing on tuning it up. I'm really happy with the higher end (a setting of 9 really is 9) but the lower end doesn't allow for more compression at lower settings. Great work on the "hands off my video" - the low end needs to come down to SL1 levels with scales to SL2 levels on the high end and it'll be perfect.
Steve
Hmm... I'll need to test to make sure my test video wasn't proportioned larger than the slide. I used one of the WMV's that shipped with Windows as a test. Pretty sure it was smaller than the stage. Will confirm this evening.
Thanks, Steve.
The dimensions of the Wildlife.wmv file that ships with Windows are 1280 x 720, so unless you increased the story size, that file would have undergone some resizing in Storyline 1.
Having said this, I inserted Wildlife.wmv into an SL1 .story project file and an SL2 .story project file that had both been increased to 1280 x 720 to double-check my theory, and then published at the various compression levels you mentioned above:
Video Quality 1 (small):
Video Quality 5 (standard):
Video Quality 9 (high):
I guess that pretty-much blows my theory to heck, and I should have paid closer attention to your test above. It's still true that SL2 on the lowest setting is larger than SL1 on the highest setting.
I'll share this information with QA and see what they have to say. Thanks!
Hey, folks.
In the interest of openness, I wanted to revisit this thread with a bit more historical context. No real changes yet, but Seek First to Understand and all, right? :)
Last Autumn, we took a lot of heat for favoring bandwidth conservation over the preservation of quality within Studio '13. When we released Studio '13 Update 2 last March, we listened, and we included a fix for this problem.
Storyline 2 was many months from shipping at that time, and we thought long and hard about whether or not to merge the same functionality into Storyline 2. In the end, we wanted consistency across our products, so we increased the quality in Storyline 2 as well. At that time, the Quality Slider had it's meaning changed, because video quality at the highest compression levels wasn't good enough.
The upshot is that the pendulum has probably swung from forcing our customers to conserve bandwidth, back to forcing our customers to preserve quality.
For now, we're going to continue to observe how this change affects our customers, so we'd encourage more customers to post within this thread or submit a Feature Request if this change is bad news for you and your learners.
In the interim, one possible workaround is to use the Don't Touch My Video feature to your advantage by pre-encoding the media to a size that suits your needs:
...hope this is useful information, and we look forward to additional feedback!
Hey Justin -
To clarify the change implication, are you saying the functionality of SL2 has been added to SL1? Or did I misunderstand the explanation of the change?
Nope, no changes to SL1. Sorry if I was unclear on that. I'll revise my text above.
Thanks Justin! Still thinking that scaling compression at the lower end of the scale would get it.
Maybe I'm not understanding the process used in SL. But it seems reasonable that a factor of compression scaling at the lower end of the scale could make it more like SL1 at setting 1 while retaining the banging (but huge) file quality at a 9 in SL2, with 5 hitting somewhere in the middle.
Please add my name to the list of people waiting for a resolution to this issue, Justin. I know I speak for several of my colleagues too.
Has anyone in Staff tried Steve Flowers' compression scaling? Is that difficult to accomplish with a version update?
Thanks all!
Thanks for sharing your input, Babette. We'll keep this thread updated with any developments.
We'd also welcome more information on the business need for lower quality videos. Is it an upper limit on the size of LMS content? ...a need to serve low-bandwidth learners? ...both? ...something altogether different?
Thanks again.
I see this is an older thread, but we are just now starting to convert our SL files to SL2 and are finding what seem to be significant files size increases in our content files that do not contain any video (in fact some are just a few slides). This is causing long wait times for lessons to open when launched. Are there other factors we should be looking at besides video that is impacting size?
Hi Amy,
I wouldn't think that a course that's only a few slides would cause such a long wait for it to open - so I'd want to know a little more about where and how your users are viewing them. Do you know what browsers? Is the course hosted in your LMS or web server? What's the file size difference you're seeing from SL1 to SL2; is it just the .story file or the published output as well? If you've got a sample .story file from SL2 we can take a look and publish it to another testing site to see how that one behaves for you too! Just upload it here using the "add attachment" button or send it along to our Support Engineers here.
This discussion is closed. You can start a new discussion or contact Articulate Support.