What a converted video course reports
To convert a video to SCORM is to wrap it in a SCO: an HTML player page plus an imsmanifest.xml, with JavaScript that watches playback and talks to the LMS runtime. Without that wrapper, a video in an LMS is just an embedded file — the platform knows it was launched and nothing else. With it, the package can report three things: how far the learner has watched, where to resume on the next launch, and whether they have watched enough to count as complete.
"Enough" is a decision, not a default. The single most important step in the whole conversion is choosing the watch threshold and writing it down as a sentence — "complete at 90% watched" — because everything else in this guide either implements that sentence or tests it.
Chaptering and captions
Two pieces of preparation pay for themselves before you touch a converter.
- Chapters. A 40-minute video as one undifferentiated timeline is hostile to resume and to reporting. Chapter markers give the player a menu, give the learner a legible bookmark ("resumes at: Handling objections"), and give you somewhere sane to split if the video should really be several shorter SCOs. If the source has no markers, list the timestamps before converting — it is five minutes of work.
- Captions. Ship a subtitle track (WebVTT or SRT) inside the package. Captions are an accessibility requirement in most corporate and public-sector settings, and they also cover the mundane case of learners without headphones. Burned-in subtitles are the fallback, but a proper track can be toggled and searched.
Also check the encoding: H.264 MP4 at a web-friendly bitrate plays everywhere; a 2 GB conference-room recording does not belong inside a SCORM zip. If the file is that large, re-encode it — packages that exceed the LMS upload cap fail before tracking is ever at issue.
Completion by percent watched
The honest completion rule for video is cumulative watch coverage: the share of the timeline the learner has actually had play, not the furthest point they dragged the scrubber to. A good player keeps a map of watched ranges, so skipping the middle does not count and rewatching the intro twice does not count double.
Where the number goes depends on the standard. In SCORM 2004, the player writes progress to cmi.progress_measure as a value from 0 to 1, and sets cmi.completion_status to completed when the threshold is crossed — the LMS can show 0.62 watched mid-course. In SCORM 1.2 there is no progress field: the package tracks percent watched internally (in its suspend data) and flips cmi.core.lesson_status from incomplete to completed at the threshold. Same behaviour at the finish line; less visibility along the way.
Pick the threshold deliberately. 100% is brittle — a learner who missed the last two seconds of outro music stays incomplete forever, and support tickets follow. 80–90% is the usual range: high enough to mean the content was watched, low enough to survive credits and buffering. Whatever you choose, the moment completion is set, the package should Commit immediately rather than waiting for exit — the mechanics of why are in why SCORM courses lose completions.
1.2 vs 2004 for video
For a single video with a watch threshold, SCORM 1.2 is usually enough and imports on everything. Choose SCORM 2004 when you want visible progress (cmi.progress_measure), when completion ("watched it") and success ("passed the quiz after it") must be reported as separate facts, or when the package stores a lot of state — long multi-chapter videos with a fine-grained watched-ranges map can press against 1.2's 4,096-character cmi.suspend_data cap, where 2004 allows 64,000. A compact range encoding keeps most single videos far below either limit, but check the number rather than assuming. The general decision guide is SCORM 1.2 vs 2004.
Seek locking and resume
Seek locking — refusing to let the learner scrub past the furthest point watched — is how a watch threshold is made meaningful for compliance content. Without it, "90% watched" can be achieved with one drag of the slider. With it, first-time viewing is linear, while review of already-watched ranges stays free. Use it when the rule is regulatory; skip it for optional material, where it reads as punitive.
Resume is the other half of the learner experience. The package stores the playback position (and the watched-ranges map) in suspend data at every commit, and on relaunch asks the LMS for it and offers "continue from 23:41". Two details separate a solid implementation from an annoying one: commit on a timer or chapter boundary during playback, not only on exit — browsers kill unload-time API calls with regularity — and resume to slightly before the stored position, a few seconds of context rather than mid-sentence.
Testing the watch threshold
Test the rule, not the happy path. In a player with the runtime log visible: watch normally past the threshold and confirm completed is set at that exact moment, with a Commit straight after. Then the hostile passes — relaunch and confirm playback resumes where you left; try to scrub past the lock and confirm coverage does not advance; close the tab mid-video and relaunch to confirm the last timer-commit held; and finally watch to 100% to make sure nothing (an end-screen, an autoplay next) prevents the final state landing. Only then upload to the destination LMS and repeat the short version there — platforms differ in how often they accept commits and how they display progress. The wider pre-upload checklist is in testing a SCORM package before the LMS does, and if the destination changes later, keeping SCORM working through an LMS migration covers what to re-verify.
Where SCORM Central fits
SCORM Central converts files you already have — video, PDF, PowerPoint, or Word — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.