Audio and video sync issues in a MediaPackage-to-YouTube workflow are best diagnosed by finding where the offset first appears. First distinguish sound that is ahead of or behind the picture from a stream that is simply late to reach viewers; those are different symptoms and need different checks.
MediaPackage is an origin and packaging stage downstream of an upstream encoder, not an encoder itself. The sequence below is a practical way to compare available stages, not a vendor-validated test procedure; use the official documentation for the current configuration details of your own workflow.
Distinguish sync drift from delivery latency
Ask viewers for a specific description: is audio consistently ahead, consistently behind, or does the offset grow over time? Or do sound and picture remain aligned with each other while both appear late compared with the live event? These observations help separate an audio-to-picture timing problem from ordinary delivery latency.
Latency is the time between an event occurring and its appearance on a viewer's screen. Encoding and decoding, network conditions and player buffers can all add delay to an HLS workflow. If a temple announcement reaches a viewer well after it happened but the bell strike still matches the visible action, that is a late stream, not necessarily a sync error. AWS discusses these sources of HLS delivery delay in its latency documentation.
With a sync error, the sound and picture disagree with each other. A visible hand clap followed noticeably later by its sound is an example. Drift is different again: the tracks begin close to alignment, then separate as playback continues. A short clip, a single still image, or a viewer's recollection may not be enough to tell which behaviour is occurring, so ask for a timestamp and a repeatable example.
Write down what the viewer means by “late”. Ask whether they mean late relative to the real-world event or late relative to the picture on screen. For a live news loop, both tracks might trail the reporter in the studio because of the delivery path, while remaining aligned. For a bhajan stream, audio might begin a fraction of a beat after a singer's visible movement, even though the stream itself reaches the audience promptly. The distinction changes which stage you should investigate.
Map the encoder-to-viewer signal path
Sketch the actual route rather than assuming that MediaPackage sends directly to YouTube. A common conceptual path is source and capture, upstream encoder, MediaPackage input, MediaPackage packaging output, a relay or publishing component, YouTube ingest, YouTube processing and preview, then the viewer's device and player. Your own workflow may combine or omit components, so name the systems that really handle the stream.
AWS describes MediaPackage v2 as receiving HLS from an upstream encoder and packaging content for downstream playback requests. Its v1 live workflow also receives HLS from an upstream encoder. YouTube separately documents encoder ingest options, including RTMP/RTMPS and HLS. Those roles do not establish a direct MediaPackage-to-YouTube publishing connection; a separate component may be needed to submit or relay the stream. See the MediaPackage v2 live processing flow and YouTube's live encoder guidance.
Make a simple inventory with the protocol and any recording, preview or monitoring point at each hop. Note whether one encoder feeds MediaPackage, whether there are multiple encoders for failover, and what component sends content onwards to YouTube. For each boundary, record which output you can actually inspect. Some workflows expose only a YouTube preview and a final playback, while others provide a local programme recording or a separate packaged output. Do not treat a missing observation as proof that a stage is healthy.
Keep the inventory version-specific. If you are using MediaPackage v2, record the channel's output-locking mode and the endpoint's timestamp mode. Do not assume that a setting documented for v2 exists or behaves identically in v1. If another person manages the AWS or YouTube configuration, ask for the relevant values rather than changing them by guesswork.
Check the upstream encoder output
Start as close to the source as you can. Use a test segment with a clear visual event paired with a sharp sound, such as a hand clap in front of the camera. YouTube recommends a test stream that includes both audio and motion, and advises monitoring stream health and messages during the event. This clap comparison is practical editorial guidance for making the event easy to recognise; it is not a test prescribed by YouTube or AWS.
Compare the source or encoder output with the same event downstream. If sound and picture are already offset in the encoder's output, MediaPackage cannot be the first point where the offset arose. Check whether the encoder is receiving the intended audio input, whether capture paths introduce different delays, and whether the source itself is synchronised. If the offset grows over time, look for clock or timestamp disagreement as well as a fixed input delay.
For a single-encoder workflow, first establish whether the problem is present before the stream reaches AWS. For a multi-encoder workflow, or one with regional paths and failover, compare how each output aligns. AWS recommends locking video frames early in multi-encoder workflows because timestamp and picture alignment can affect failover. Its discussion of encoder synchronisation and failover is relevant to those designs, not evidence that every stream needs local timecode equipment.
YouTube's encoder guidance includes a recommended two-second keyframe interval and says not to exceed four seconds. Those are encoding recommendations, not audio-to-picture correction settings. Check the current YouTube encoder settings against your chosen protocol, but do not change keyframe settings and audio timing together when trying to identify an offset. Changing several variables at once makes it harder to see which stage mattered.
If you need a repeatable record, capture the same brief test at the encoder output and at each later point you can access. Use a clip with both a clear transient and continued motion: one event can reveal a fixed offset, while a longer sample can help show whether the offset grows. Keep the source and event the same when comparing captures. A different test clip or an unsynchronised recording clock can make a good stream look faulty.
Compare MediaPackage input and output
If the upstream encoder output is aligned, compare what enters MediaPackage with what comes out, where your workflow allows those observations. Confirm that the input tracks are the expected ones and that the output has not acquired a new offset. If you cannot inspect both boundaries, note that limit and continue to the next available observation; do not infer that MediaPackage introduced the problem simply because it is in the middle of the path.
In MediaPackage v2, output timestamp behaviour can be PASSTHROUGH or REBASED_TO_CHANNEL_START. Passthrough preserves input presentation timestamps (PTS); rebasing makes output PTS relative to the channel start. AWS says the setting is configurable only when output locking is NON_EPOCH_LOCKED, defaults to passthrough when omitted, and is immutable after endpoint creation. Consult the MediaPackage v2 API reference for the current constraints.
These modes are not universal repair switches. First establish the current mode and output-locking configuration, then determine whether the input is already wrong and whether output timestamps plausibly account for the observed change. Endpoint configuration may be constrained or immutable, and changing a timestamp mode without evidence can create a new problem or make a comparison impossible. Do not recreate or reconfigure an endpoint merely because an offset exists.
If input is aligned but output is not, review the endpoint and track configuration with the person responsible for the AWS workflow. Preserve the original settings and record each change. Compare like with like: the same test event, corresponding audio and video tracks, and captures made at known stages. A timestamp discrepancy can be a clue, but timestamp values alone do not tell you whether the audible and visible content are aligned to a viewer.
Inspect YouTube ingest and preview
When the packaged output is aligned but YouTube's preview is not, investigate the component that submits content to YouTube as well as the ingest path. Establish whether the workflow uses RTMP/RTMPS or HLS and verify the relay's track mapping, timestamps and selected output. MediaPackage's presence earlier in the chain does not rule out a fault in a later publisher or in YouTube ingest.
YouTube's HLS ingest has protocol requirements that differ from a continuous RTMP stream. Its documentation specifies TS segments, a rolling playlist with no more than five outstanding segments, and HTTPS POST/PUT requests. Check the current YouTube HLS ingest requirements if you use HLS; confirm that the relay is actually following them rather than assuming all HLS outputs are interchangeable.
YouTube states that HLS ingest has higher latency than continuous RTMP ingest. That difference concerns delivery time; it does not, by itself, mean audio and picture will be out of sync. Switching protocol may alter how long the stream takes to reach viewers, but should not be presented as a sync correction unless comparisons show that the offset first appears at that boundary.
Use the YouTube preview and stream-health messages as observations, not a guarantee about every viewer's playback. Run a test with motion and audio, record when the distinctive event reaches the preview, and compare its sound with the picture. Note whether YouTube reports health issues around the same time. If the preview is aligned but a viewer's playback is not, move downstream to the player's conditions rather than changing the upstream timestamp mode without evidence.
Compare viewer playback conditions
A viewer's device can introduce a difference that is absent from the source and preview. Ask the reporter to try another device or browser and, if possible, a different network. Compare the same moment rather than asking whether the stream “looks better” in general. A Bluetooth speaker, television audio path or overloaded device can make sound seem delayed even when the stream's encoded tracks are aligned.
Ask whether the offset is stable on one device, present across devices, or changes during playback. A fixed discrepancy across several independent viewers is more likely to justify tracing a shared upstream stage. A problem limited to one player or playback route points you towards that environment, although it is still a clue rather than proof. Record device, browser or app, connection type and the approximate time of the example.
Do not compare the live preview with a separately buffered replay as though they were the same stage. Different players may buffer differently, and a longer wait before both tracks appear is not the same as an audio-to-picture error. If you are checking a VOD or local recording, ensure that it was made from the same point in the signal path; a recording of the source cannot establish what a downstream viewer received.
For a channel that runs overnight, keep a short incident note rather than relying on a viewer report that arrives hours later. Include the event time, whether sound led or lagged, whether it drifted, the playback device, and which stage captures were available. A second report that names the same event and another device can help distinguish a local playback issue from a shared stream fault without treating either report as conclusive.
Use the first point of divergence to narrow the fault
Place the observations in order and identify the earliest one where the tracks stop matching. This is a workflow-based diagnostic inference from the documented roles of the components, not a MediaPackage, AWS or YouTube validated testing sequence. Its value is that it narrows the area to investigate; it does not prove a root cause or guarantee a fix.
| First observation showing an offset | Area to inspect next | Useful follow-up |
|---|---|---|
| Source or encoder output | Capture and upstream encoder | Confirm input mapping, source timing and encoder timestamps |
| Encoder output aligned, packaged output offset | MediaPackage path | Compare input and output tracks, endpoint configuration and v2 timestamp mode where applicable |
| Packaged output aligned, YouTube preview offset | Publisher or ingest path | Check relay track mapping, protocol requirements and YouTube health messages |
| YouTube preview aligned, one viewer affected | Viewer playback path | Compare another device, player and network using the same moment |
| Sound and picture aligned at each point but both late | Delivery latency | Review protocol, network, encoding and player buffering rather than calling it a sync error |
Treat the table as a guide to what to examine, not as a verdict. For example, an offset first noticed at YouTube preview might have been introduced by a relay that sits between the packaged output and YouTube. The first visible divergence brackets the problem; it does not identify which component within that bracket is responsible.
Change one relevant setting at a time, and preserve a record of the original value and the result. If a change moves the offset, repeat the same comparison before deciding whether it helped. Avoid changing timestamp mode, ingest protocol, encoder delay and player configuration in one session. Otherwise, even an improvement will not tell you which change mattered or whether the effect was repeatable.
When the fault lies in keeping a broadcast running rather than in aligning source tracks, the operational question is different. If your source is a prepared video and the recurring burden is keeping a computer on overnight, a cloud-based 24/7 stream workflow may be relevant; it does not diagnose a MediaPackage timestamp issue. StreamNeo removes the need to keep your own computer running for an uploaded-video YouTube stream, but it is not a MediaPackage troubleshooting tool and it is YouTube-only.
For problems confined to a local continuous encoder, the checks in FFmpeg reconnect troubleshooting concern reconnect behaviour, not sync. If your question is instead about persistent audio and picture mismatch on a different YouTube setup, the sleep-sounds sync guide offers another symptom-focused starting point. Keep the current MediaPackage workflow's actual boundaries in view when applying advice from a different setup.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is MediaPackage the encoder in this workflow?
No. MediaPackage is an origin and packaging stage that receives an upstream stream; the upstream encoder creates the encoded live output. Identify the component before MediaPackage and the separate component, if any, that publishes content to YouTube.
Does HLS latency mean my audio and video are out of sync?
No. Latency measures how long the event takes to reach the screen, while sync describes whether audio matches the picture. YouTube says HLS ingest has higher latency than continuous RTMP ingest, but that fact alone does not establish an audio-to-picture offset.
Should I change MediaPackage's timestamp mode to fix an offset?
Not as a first or universal repair. Establish whether the offset first appears at MediaPackage, and check the v2 output-locking mode and endpoint constraints before considering a configuration change. AWS documents that the setting has conditions and cannot be changed after endpoint creation.
What should I send support when I report the problem?
Describe whether sound is ahead, behind or drifting over time, and include the event time and the viewer's device and playback route. Say which stages you compared and where the first offset was visible. That gives the person investigating a useful boundary without claiming the cause is already known.