Varied Video Publishing Results in SCORM 2004

[Crystal_Klarich]

I am using Captivate 8 on a Windows 7 machine.

I published a file to SCORM 2004 3rd edition in both SWF and HTML for a customer. This file has an mp4 video inserted as a progressive download video type. The customer was receiving an error when uploading the published zip folder to their LMS - specifically calling out the imsmanifest and the video file. I blacked out any information regarding the customer, but this is the error they received in Cornerstone:

I opened up the zip folder I sent the customer. The video file was placed into a folder called vr, so it did exist as an asset. I then took a peek in the imsmanifest to check the links to the video. There were two references to the video file:

--one that points to the video being in the root folder (which it wasn't)

--and one that correctly points to the video being inside the vr folder

I corrected the folder location for the first link in the imsmanifest, packaged it back up, sent it to the customer, and everything uploaded perfectly.

Thinking that maybe there was just a problem when I published the file, I republished and got the same incorrect linking. I then updated the video file in the library before republishing, and this time the video was placed inside both the root folder and the vr folder - the imsmanifest was then correct. Why does it need to publish it twice?

I was curious to see if other files did anything weird using the same publishing settings, so I published another file with the same video type - progressive download - (though f4v instead) and checked its output. The f4v video was renamed to vi1 and exported as an mp4 - it pops open the media encoder while publishing, so I figured that the renaming was normal. The imsmanifest correctly pointed to the renamed mp4 video inside the vr folder. There were no f4vs in the zip or the imsmanifest.

I checked a third file, again with f4vs as progressive download video types. This output saved both the f4v and the exported mp4 files (with their original file names) in the vr folder and the imsmanifest points to both video types - all within the vr folder.

I never would have looked into this if my customer's system hadn't popped up an error... Any ideas why Captivate publishes each file so differently (the settings are all identical, barring the actual videos) - or why it dropped a file in the first place - or why it duplicates them sometimes? My plan is to replace all of our older f4vs with mp4s, but if there is a possibility that they won't publish correctly, I'm a little nervous that I'll have to go in and check the imsmanifest on everything I publish. (Yikes!)

I appreciate any incite on this!

Thank you,

--Crystal

[Erik_Lord]

First, very well done on the overall troubleshooting!

I don't know why this would happen, and have not experienced it myself, but given that most of your testing resulted in correct locations and manifest files, the key would seem to be,

I then updated the video file in the library before republishing, and this time the video was placed inside both the root folder and the vr folder - the imsmanifest was then correct.

So what exactly does 'updated the video file in the library' mean? That seems to have been the step that resolved the problem.

I'd suggest trying another file update, replacing the older .f4v files with .mp4 files as you suggest. Maybe just do a couple of them, or if it's a bit project, make a copy and just delete all but a few slides with the video replacements.

Publish and see if the issue remains.

If so, 'update the video file' as you mentioned and test again.

Does it seem that fixes the problem and you'll just need to do the 'video file update' for each project?

Would that be terrible?

Aside: I'd strongly recommend just not publishing to SWF unless your customer requires it. All current browsers can handle HTML output now, though CP8 is a little old and it would be more reliable to publish with a new version of Captivate. Seems like you could avoid this issue entirely, as well as any issues with the Flash player, if you just publish to HTML5 alone.

E

[Crystal_Klarich]

Thanks Erik!

Unfortunately, we still have some Flash content to update in our courses, hence the hybrid publishing method. It’s a work in progress...

To update the video file, you click on it in the library and hit update - then browse to the same video file. It refreshes the cached copy inside the library.

Back to my issues… So I went back to file #3 (that created a copy of both the mp4 and the f4v) and replaced one of the f4v files with an mp4. I published it, and got one copy of the mp4 in the right spot with a correct imsmanifest.

I then went back to file #1 and added a slide with the same mp4 I inserted into file #3 and published again. The imsmanifest had two links for each video – one to the root folder and one to the vr folder. The first video file published to both places, but the brand new video only published to the vr folder! How bizarre! I updated the file in the library and republished, but this time, the video did not republish to the correct place. Maybe there is some glitch in the file?

[RodWard]

The VR folder is for video assets in the HTML5 version of your content.  Not the HTM/SWF version.  When Captivate publishes SWF output any video assets to be pulled in by the SWF file are placed at the same level as that SWF file.  Since you are using dual publishing, you needed two separate instances of the same video file.

With dual publishing there is an extra file called multiscreen.html that gets linked to first and the code in this file determines which of the two versions gets served to the user. However, please be aware that the way this multiscreen.html file decides the branching is based on whether or not the end user is viewing the content in a MOBILE browser, NOT based on whether they are using a browser that can render HTML5.

So, with dual publishing your desktop users will ALWAYS get the HTM/SWF version of the course, regardless of whether or not their browser would be fine with the HTML5.

As Eric pointed out, almost all organisations nowadays are using HTML5-capable browsers.  And browser vendors are progressively making it unattractive to use Flash at all.  One day, your organisation might do a silent browser security update and the next thing you know all of your SWF courses (including the dual published ones) will suddenly stop working and your phone will start ringing with angry managers on the other end.

[Crystal_Klarich]

Thanks Rod! That makes sense.

I didn't realize that mobile was the deciding factor to delivering HTML5 or not... We are working through updating our legacy content with the end goal of HTML5 in mind - until that point, I am keeping a close eye on the browser roadmaps for what they are doing to Flash so that I can keep our company and customers updated.

[Jefferbob]

We are seeing the same behavior with Cap 9.0.2.437 - manifest has 2 entries, but the file is only placed in the /vr folder. (We're in the process of transitioning to an LMS that actually cares about the manifest, so I hadn't noticed the behavior until now.)

Rod - I agree that you'd need two instances of the video file, but if Cap knows you're publishing to both, it should put an instance in both locations specified in the manifest that it creates.

[RodWard]

Agreed.  The fact that there are two references and pathways to the video file listed in the manifest makes it definitely SEEM like a bug.

However, when I just tested a simple three slide project with a 5 second video file and a quiz question in Captivate 2017 set up to report to SCORM 1.2 and uploaded the zip file to SCORM Cloud, I found that the HTM/SWF content correctly showed the video file even though the original content did NOT have two MP4 videos.  There was only ONE video file and that was in the vr folder of the HTML5 content.

So it seems to me that Captivate IS using the same MP4 video file in the vr folder for both HTM/SWF and HTML5 outputs.  The imsmanifest,xml file is listing a second MP4 at the root level incorrectly.  There isn't one there.

[Jefferbob]

If the LMS is following the instructions in the manifest, and those instructions say there should be an MP4 at the root AND an MP4 in /vr, then the LMS is well within it's logic to throw an error. And if the error is thrown during the zip upload process, you can't confirm whether or not the LMS will play the course with only 1 MP4.

Regardless, it IS a bug - either by not copying the video to both places (as the manifest it creates would dictate) or the creation of the manifest itself is wrong by creating a root reference which isn't needed.

[RodWard]

Jeff,

Perhaps you noticed that I AGREED with you that this issue IS a bug. But getting Adobe to fix bugs of any kind in Captivate is not guaranteed to happen within a fixed timeframe.  (Trust me I know.)

What I was trying to do with my previous post was provide you with a workaround so that you might have a chance of successfully uploading your current project to the LMS and getting it to work.  Correct me if I am wrong, but in your current situation I would have thought getting the project to work was a higher priority.

[Jefferbob]

I never said you didn't, but there was an implication that you questioned it. It's great that SCORM Cloud can adapt to this invalid manifest, but other LMSs can't or won't, and in this case, I wouldn't expect them to since the manifest is specifying something that doesn't exist.

Workarounds are fine in the interim, and we've already been doing this one for weeks with all existing content to prepare for an LMS transition. Right now, my biggest priority is having a product that works as designed without requiring unnecessary post-processing cleanup work.

[RodWard]

OK.  I'll leave you to arm-wrestle Adobe into compliance then.  I won't take up any more of your time.

[Jefferbob]

Uh, OK. This is why I rarely post here.