What Controls Playback Speed in a Stored Ultrasound Loop?
The useful question is whether the receiving workstation is displaying the stored frames at the intended tempo. DICOM means Digital Imaging and Communications in Medicine; PACS is the picture archiving and communication system. A successful transfer and a recognizable moving image answer different questions from timing fidelity. Start with one affected instance and one repeatable observation rather than changing the whole department’s cine preset.
This guide covers conventional Ultrasound Multi-frame Image Storage objects, identified by SOP Class UID 1.2.840.10008.5.1.4.1.1.3.1, as listed in the Lumify and Viamo statements. SOP means Service-Object Pair. Record the class before applying this checklist: a rendered video, private-format loop, secondary capture or enhanced volume object needs its own applicable documentation. Do not infer that every ultrasound export uses the same timing structure. 7 8
The first distinction is between encoded intervals and a recommended viewing rate. Medical Connections explains the interval-to-rate conversion and why a display recommendation need not equal the calculated rate. A difference is a finding to explain, not automatic evidence of corruption. For instance, 150 ms between frames implies about 6.67 fps; an integer display field cannot reproduce that fraction exactly. 4
| Attribute | Tag | What to record | Decision use and limit |
|---|---|---|---|
| Frame Increment Pointer | (0028,0009) | Every target tag and whether it is present with a value | Resolve the applicable frame-sequence description; check the object’s IOD. |
| Frame Time | (0018,1063) | Nominal milliseconds per frame | Evaluate when named by the pointer; a single-frame value can be zero. |
| Frame Time Vector | (0018,1065) | All millisecond increments, including the initial zero | Preserve per-frame intervals rather than replacing them with one average. |
| Recommended Display Frame Rate / Cine Rate | (0008,2144) / (0018,0040) | Presence and integer fps values | Optional fields; do not infer the workstation’s precedence from presence. |
| Number of Frames | (0028,0008) | Positive frame count | Establish the sequence being compared; a still needs no playback-speed test. |
| Frame Delay | (0018,1066) | Milliseconds from Content Time to the first frame | Offsets the timeline; it is not the trigger-delay attribute. |
| Effective Duration | (0018,0072) | Seconds of actual data-taking time | Corroborating field; do not assume it equals the first-to-last timestamp span. |
| Preferred Playback Sequencing / trims | (0018,1244) / (0008,2142–2143) | Looping or sweeping; start and stop frame | Explain direction or displayed subset before comparing whole-loop duration. |
Source: Field references: DICOM Cine and Multi-frame Modules; display-rate distinction: Medical Connections. See sources 1, 4 and 10.
Which Timing Was Actually Written?
A header containing Frame Time is not enough to establish the active timing path. Read the Frame Increment Pointer first, then confirm that its target exists and has a value. The Multi-frame Module makes this requirement explicit, including for a one-frame instance. Its permitted targets depend on the Image Object Definition (IOD); do not treat every multi-frame SOP class as interchangeable. 10
For a fixed-interval sequence, use the pointer-designated Frame Time to build relative timestamps. For a vector sequence, retain the individual increments. This distinction describes the stored object; it is not a command to force a particular playback mode in every viewer. The receiving product’s documentation and acceptance test must establish how its display controls use those values. 1 4
Do not classify an absent optional display-rate field as an export failure. Conversely, a populated Cine Rate does not excuse a missing pointer target in an object that requires it. Validate the required attributes against the object’s class, not the workstation’s ability to play something. A tolerant viewer may display an incomplete file successfully.
An encoding boundary also merits attention for very long vectors. The current Cine Module page identifies itself as PS3.3 2026d and permits VR UN for a vector exceeding 65,534 bytes in an Explicit VR transfer syntax. The selected 2025b page instead contains an older encoding caution. Record the actual value length, transfer syntax and decoder behavior before raising this possibility; the note alone does not prove a receiver defect. Do not trim a clinical loop or change its transfer syntax merely to make a test pass. 1
Why the Same Loop Can Play Differently in Two Viewers
Separate three observations: the header’s rate, the user’s current speed setting and the rate chosen when usable timing is absent. These are implementation questions. The Cine Module does not establish a universal 15 or 30 fps fallback or a general precedence rule for viewer controls. Product help is therefore consequential evidence, but only within its documented scope.
Synapse’s hospital-hosted WebHelp5 guide describes a header default and a 30 fps fallback when neither the header nor Cine settings provides a rate. It also documents interactive speed changes. Its statement that a header rate overrides a saved user default should not be expanded into a claim that users cannot change speed during review. The page does not identify the exact deployed software build. 2
InteleViewer PACS 5.4.1 P2 documents header-based startup, relative speed controls and an average rate when a scanner cannot provide an exact one. It also warns that slow computers can drop displayed frames. The guide does not explain its Frame Time Vector algorithm; it does not support an assertion that the product flattens a particular cardiac phase. Record dropped-frame indicators as well as the displayed rate. 3
A historical MicroDicom thread supplies a narrower example. In January 2022, a user reported FrameTime-only parsing and a 15 fps fallback when other rate tags were present. The vendor offered a beta on 11 January, and the user confirmed resolution on 19 February. The thread does not identify a current-release defect, prove that the original file met every required attribute, or justify calling 15 fps a universal default. 5
Another user’s April 2019 thread reports that adjusting a global fps setting improved one loop while making others too fast. This is useful workflow evidence for checking the scope of a setting, not a measurement of how frequently timing failures occur. Two MicroDicom threads remain one publisher chain; they are not two independent product validations. 6
The sender-side documents add a different kind of evidence. Philips Lumify R5.0 and the historical Toshiba Viamo statement declare different attribute-generation patterns. Their tables show what the named implementation declares, not what a particular installed unit actually exported. In Viamo, ANAP means present when applicable and USER identifies the value source; those cells alone do not document an export-menu option or exactly when the field will be omitted. 7 8
| Reference | Declared behavior | Useful acceptance question | Limit |
|---|---|---|---|
| Philips Lumify R5.0 — HSDP-1299212, version 01 (2023) | Tables 60–61: automatic display rates; pointer to Frame Time Vector | Does a sample from the matching release contain and preserve its vector and rate fields? | Declaration for this release; verify the actual installation. |
| Toshiba SSA-640A Viamo V1.20 — MIIUS0041EA (2009) | Tables 8.1-15–16: Frame Time ALWAYS/AUTO; display rates ANAP/USER | Which timing and user-sourced display values are actually written? | Historical model-specific document; no inferred menu behavior. |
| Synapse — WebHelp5 Using Cine | Header default; user controls; 30 fps fallback if neither header nor settings supplies a rate | What is the starting rate, saved default and current slider value? | Exact build unspecified; verify local help and behavior. |
| InteleViewer — PACS 5.4.1 P2 | Header startup; relative multipliers; average-rate display; possible dropped frames | Are multiplier and displayed-frame delivery documented during the comparison? | No vector-decoding algorithm established by this help page. |
| MicroDicom — thread 4134, January–February 2022 | Reported FrameTime-only fallback; beta and confirmed resolution | Does the affected installed version reproduce the documented behavior? | Historical case, not a current ranking or conformance verdict. |
Source: Model/version-specific synthesis from sources 2, 3, 5, 7 and 8. These rows are not a compatibility certification or vendor ranking.
Does a Playback-Speed Difference Change the Stored Evidence?
Changing a viewer’s playback speed alone does not rewrite the stored pixel values or existing measurement objects. That limited observation does not verify that all frames, calibration or measurements reached the receiver correctly. Keep the timing question separate from those completeness checks; the structured-report measurement delivery guide covers the distinct image-versus-measurement handoff.
Timing-dependent review may need a verified tempo, so record the discrepancy and ask the responsible clinical team how the affected display can be used while it is investigated. Do not declare stored measurements valid, diagnose an abnormality, or estimate Doppler velocity from the apparent animation speed. No cited source here establishes a legal admissibility test, accreditation failure or particular patient outcome from this symptom.
The practical acceptance question is whether the team can explain the relationship between the source loop, stored intervals and displayed sequence. If it cannot, report temporal playback as unresolved. A good-looking animation is insufficient proof; equally, a deliberate slow-motion setting is not automatically a defect.
A Read-Only Verification Sequence
Use facility-approved tools and authorized access to inspect one affected instance without changing it. DICOM metadata can contain patient identifiers; keep header dumps and screenshots within approved systems. Do not upload clinical files to public viewers, forums or a service enquiry. Use synthetic or approved de-identified reproductions for external escalation.
- Identify the exact instance. Record the SOP class and instance identity, sender model/software, receiver build and transfer syntax. Confirm you are comparing the same stored loop, not a separately rendered clip or a trimmed subset.
- Resolve the pointer. Record every target and its value. For this conventional timing path, distinguish Frame Time from Frame Time Vector. Missing Frame Time is acceptable when a different permitted target supplies the required information. 10
- Calculate the encoded timeline. For positive fixed intervals, convert milliseconds to fps. For a vector, preserve cumulative timestamps and calculate an average only as a summary. Exclude the initial zero from the interval average.
- Record display controls. Capture optional rate fields, trims, direction, workstation fps, multipliers and any dropped-frame indicator. A stored recommendation and a user-selected speed can legitimately differ. 2 3 4
- Compare controlled displays. Use the same unmodified object on a second approved viewer after it has loaded. Record settings on both. Different behavior narrows the investigation but does not certify the file or either viewer.
- Compare the stored source. Review the corresponding local saved loop, not just live scanning. Record its playback settings and export path. If an authorized source-side DICOM sample is available, compare its metadata with the received instance to locate the first difference.
This sequence is an engineering synthesis, not a vendor service procedure. A displayed console fps value may refer to acquisition or local review; establish its meaning before treating it as the reference for an export. If the source is no longer available, state that limit rather than constructing replacement timing from memory.
| Observation | What it supports | What remains unproven |
|---|---|---|
| Pointer and target are present | The declared timing path can be inspected | Full SOP conformance, complete pixels and receiver behavior. |
| Two viewers show different speeds | A setting or implementation difference needs investigation | Which behavior is correct; whether either compensates for incomplete metadata. |
| Saved console loop appears normal | Initial focus on export and receiver is proportionate | Absence of every hardware, software or intermittent fault. |
| Sender and received timing fields differ | A boundary in the delivery path needs investigation | Which component changed them without intermediate evidence. |
| Displayed fps differs from computed rate | A rate choice or delivery limitation needs explaining | Corruption; intentional slow review remains possible. |
| Pointer target is absent in the applicable IOD | A required timing relationship is incomplete | The responsible component or an appropriate replacement value. |
Source: Engineering synthesis based on standard requirements and documented viewer controls. Sources 1–5 and 10 provide the mechanics; the inference limits are editorial guidance.
Synthetic Examples: Avoid the Average-Rate Trap
The following values are invented for explanation. They are not a complete DICOM dataset, a conformance test, a patient record or a captured export from a named system.
Fixed-interval subsetNumber of Frames: 75— Synthetic timing-field subset; no patient information.
Frame Increment Pointer: (0018,1063)
Frame Time: 33.333333 ms
Recommended Display Frame Rate: 30 fps
Preferred Playback Sequencing: 0 (looping)
The calculated rate is approximately 30 fps. With 75 timestamps there are 74 gaps, so the first-to-last timestamp span is about 74 × 33.333333 = 2,466.667 ms. A player holding all 75 displayed frames for one interval would take about 2.5 seconds before restarting. Those are different quantities. Do not force Effective Duration to equal either one: it describes actual data-taking time and needs sender-specific interpretation.
For a synthetic five-frame vector [0, 40, 60, 40, 60] ms, cumulative timestamps are [0, 40, 100, 140, 200] ms. There are four nonzero inter-frame gaps across 200 ms; their mean is 50 ms and the corresponding summary rate is 20 fps. Averaging all five entries, including the initial zero, would incorrectly produce 40 ms and 25 fps.
Even the correct 20 fps summary loses the alternation between 40 and 60 ms gaps. Compare the individual timestamps when variable timing matters. An average displayed by a workstation does not prove how it schedules every frame, and an apparent smooth loop does not show whether frames were skipped. This is why the evidence pack retains the vector, frame count and viewer indicators rather than just one fps number.
Locate the Difference Before Assigning the Cause
Treat export configuration, intermediate conversion and receiver decoding as hypotheses to test. The cited sources do not quantify the most common cause or establish buffer exhaustion, print spooling or gateway stripping as the explanation for your case. Avoid assigning a cause from the symptom alone.
At the sender, compare a controlled sample with the conformance statement for the actual model and software revision. Confirm the deliverable and whether export settings deliberately change its frame sequence or display recommendation. Type 3 omissions can be permitted; a matching statement does not guarantee interoperability, as Philips explicitly cautions. 7
Where a gateway or conversion service sits between the console and PACS, ask its owner to compare authorized input and output evidence. Match instance identity, frame count and timing fields, noting any intended transformation. A difference between endpoints warrants inspection of that stage; do not bypass security controls or assume ordinary network transport changes timing tags. For a failure to send or store the loop at all, follow the separate network and I/O verification guide.
At the receiver, distinguish uniform wrong tempo from pauses, blank frames or stutter. InteleViewer documents incomplete streaming and dropped-frame behavior under some conditions. A screen recording alone cannot tell whether the stored sequence is incomplete, the display is still loading or the user requested a rate the workstation cannot sustain. 3
Correct the Responsible Stage and Preserve the Original
Do not silently change timing attributes in the clinical archive to make a loop look normal. A guessed frame interval can hide the original discrepancy. Preserve originals, record the finding and use the facility’s approved correction and reconciliation process. This is evidence-handling guidance: the cited DICOM sections define encoding and timing, not a universal legal prohibition on controlled correction.
If the stored timing is supported and the issue is a local speed control, work with the PACS administrator to verify that setting; re-export may be unnecessary. If the sender’s exported object is demonstrably incomplete or incorrect, seek the OEM-supported correction and a controlled re-export where the source still exists. If the receiver mishandles a supported encoding, escalate the reproducible sample to that receiver’s vendor. Do not change the scanner merely because one viewer differs.
Re-export is not a guarantee of a new SOP Instance UID or correct timing. Record the actual resulting identities and content, and reconcile how the archive handles retained, corrected or duplicate instances. Never alter UIDs arbitrarily, silently overwrite an archived object, or promise that re-sending the same instance will correct it.
Retain the available source and original evidence under facility policy until the correction has been accepted. The storage-commitment and deletion guide explains why a send acknowledgment alone is insufficient for deleting the only copy. Here, add timing verification and documented reconciliation to the acceptance record.
| Finding | Next owner and check | Acceptance boundary |
|---|---|---|
| Unexpected local multiplier or speed preset | PACS administrator / department user: verify documented controls | Same unmodified instance, intended rate, settings recorded. |
| Required pointer target absent in sender sample | Clinical engineering and OEM: investigate the matching export implementation | Corrected sample validated; controlled re-export only if needed and possible. |
| Sender and received timing differ | Gateway / archive owner: compare intermediate boundaries | Explain intended transformations and identify the first changed stage. |
| One receiver fails on a supported vector or encoding | Receiver vendor: reproduce with an approved test sample | Prove timestamp and frame handling; do not trim the study as a workaround. |
| Console review also freezes, corrupts or crashes | Qualified service team: evaluate software, storage, thermal, power and processing possibilities | No board diagnosis from symptom alone; qualified testing before clinical return. |
Source: Engineering routing synthesis, not a vendor service instruction. See sources 1–5, 7–10 and the linked service guides.
When Does the Scanner Need a Separate Service Assessment?
Normal saved-loop review on the console makes a metadata and receiver investigation a sensible first step. It is not a 100% exclusion test for hardware, intermittent faults or export software. Do not order a replacement board solely because an archived loop plays too fast, and do not claim the scanner is cleared for clinical use from one successful local replay.
If the console itself freezes, shows corrupt frames or crashes during review, record the symptom and refer it for qualified assessment under facility policy. These observations do not uniquely identify VRAM, solder joints, power rails or a particular processor. The back-end image-processing guide covers the separate service decision. This article does not instruct readers to open energized equipment or force a reboot that could lose the study.
Where Rongtao Medical Fits — And Where It Does Not
Rongtao is an independent ultrasound service and parts provider. The capabilities supporting this page concern hardware assessment and repair; they do not establish a PACS software product, a viewer patch or a clinical interpretation service. A playback-only discrepancy should first go to the relevant PACS, integration or OEM team with the evidence above.
For a separately established hardware service need, Rongtao documents component-level board repair and 48-hour real-machine testing of repaired boards. Standard board-repair turnaround is 5–8 business days and warranty is typically 90 days; exact scope, availability, evidence and terms require a quote. That supplier test does not replace facility-specific acceptance or qualified return-to-service checks. The published service process explains the handoff. 9
For a hardware enquiry through Rongtao’s contact desk, provide OEM, model, software revision, exact error or symptom, quantity and destination. Include existing label and board photos only when safely available from qualified personnel; do not dismantle a system for this article. State whether the symptom occurs on live scanning, saved console review or only after export, and provide approved, non-patient evidence of the preceding checks.
- Playback ticket: sender model/software; viewer product/build; object class and protected instance reference; frame count; pointer and target values; optional rates; trims and direction; observed fps/multiplier; loading or dropped-frame indicators.
- Comparison record: same-instance confirmation; source-versus-received fields if available; second viewer with settings; saved console behavior; proposed owner; remaining uncertainty.
- Closure record: approved change and responsible person; pre/post evidence; corrected-instance identity; archive reconciliation; documented acceptance and source-retention decision.
Frequently Asked Questions
The loop plays at double speed: what numerical check helps?
A synthetic 15 fps sequence played at 30 fps runs at twice its nominal rate. By contrast, a 60 fps sequence played at 30 fps runs at half speed. Compare interval units and actual viewer controls before applying either explanation; neither example diagnoses a real export.
Can Frame Time be absent without a defect?
Yes, when the applicable timing path uses another permitted pointer target such as Frame Time Vector. Inspect the pointer and its target. An optional Cine Rate field alone does not prove all required multi-frame attributes exist. 1 10
Which viewer should we trust if two differ?
Neither solely because it looks normal. Compare their documented rate selection, current controls, full loading and frame-delivery behavior against the encoded sequence. A receiver may compensate for missing information or intentionally apply slow review. 2 3
Should we average a vector to set playback?
An average is a summary, not a substitute for the individual intervals. Exclude the initial zero when calculating the average gap. The five-frame synthetic example above shows how including it overstates the rate; choosing a clinical display mode requires the responsible team’s acceptance.
Does a wrong display speed invalidate the whole study?
The finding is narrower: temporal playback needs explaining. A speed-control change alone does not rewrite stored values, but this guide cannot certify completeness, measurement validity, clinical suitability or legal status. Preserve the record and escalate any timing-dependent review question.
Will re-export always fix it?
No. It helps only when an identified sender-side problem is corrected and the source remains available. A receiver setting or decoder issue may need a different fix, and re-export can retain instance identities. Document the resulting content and archive reconciliation rather than assuming a clean replacement.
