A 404 on a YouTube HLS workflow does not identify the fault by itself. First establish which request returned it: a request for a MediaPackage playback manifest or segment, an encoder upload to YouTube, or a request handled by a CDN or proxy.
Those requests travel in different directions and use different URLs. Record the exact failing request before changing configuration; otherwise, it is easy to fix the playback path when the failure was an upload, or to blame MediaPackage for a response generated elsewhere.
Capture the failing request before changing anything
Start with the system that observed the error. It might be an encoder log, a browser’s network panel, a CDN access log, or a monitoring alert. Capture the full hostname and path, the HTTP method, status code, response body, time, and any response headers that identify a cache, proxy, or origin. Record the query parameter names, but redact their sensitive values.
Do not share a stream key, authorisation header, signed URL, or account identifier in a ticket or public log. Preserve enough of the URL to distinguish the host, path, and query structure, while replacing credentials and tokens with placeholders. If you can reproduce the failure, note whether you used the same client and route as the original request.
The method and direction are useful clues, but they are not a diagnosis. An HLS client normally requests playback resources, while an encoder sends ingest requests; the precise method depends on the service and workflow. Record what actually happened rather than inferring it from an error message or a label such as “YouTube HLS output”.
Write down the time with the relevant timezone and align it with encoder, AWS, and intermediary logs. A response body or header can help identify the responder, but it may be absent or rewritten. The hostname in the requested URL tells you where the client intended to connect, not necessarily which component created the 404.
Identify the responder and the workflow direction
There are three main fault domains to separate. In MediaPackage playback, a client or CDN asks an AWS Elemental MediaPackage endpoint for a manifest or media segment. In YouTube HLS ingest, the encoder uploads playlists and segments to the HLS destination YouTube provides. In an intermediary path, a CDN, reverse proxy, or other routing layer receives or changes the request or response.
There can also be a separate AWS ingest leg: an upstream encoder or MediaLive sends content into MediaPackage. That is not the same request as a viewer fetching a MediaPackage playback URL, and neither URL should be substituted for YouTube’s HLS upload destination. Before troubleshooting, sketch the route in plain language: “encoder sends to X”, “client requests from Y”, and “proxy sits between them”, if applicable.
Use the full host and path to check which service the request targets, then compare the same event in logs from that component. A 404 in a CDN log does not establish that the origin returned 404. Conversely, a request that reaches AWS or YouTube and receives a 404 needs to be investigated against that service’s configuration and protocol requirements.
Keep service generations in view. MediaPackage v1 and v2 have distinct configuration and input expectations. AWS documents v2 live input options and endpoint support separately from v1; use the documentation for the generation actually configured, not an example that happens to mention “MediaPackage”. AWS’s MediaPackage v2 endpoint guidance describes endpoint settings, including optional forced endpoint errors. It is a reference for interpreting a playback response, not proof of what caused a particular one.
Trace MediaPackage manifests and segments
If the failed host is a MediaPackage playback endpoint, begin with the configured endpoint and its generated playback URL. Do not guess the manifest path. AWS says the HLS manifest name is part of the URL; index is the default only when no manifest name has been configured. Copy the current URL from the endpoint details or API output and compare it with the exact failed path. A renamed manifest, endpoint recreation, or stale copied URL can leave a client requesting an obsolete path, but confirm the mismatch before treating it as the cause.
Request the top-level HLS manifest directly, then follow the child playlists and segments it references. Note the first individual request that returns 404. If the top-level playlist loads but a child playlist fails, the investigation is different from a top-level path failure. If playlists load and one segment fails, keep the segment path and time; do not label the whole manifest as broken based on that one response.
Next, inspect the endpoint’s manifest filter configuration against the request’s query string. AWS documents a 404 when an endpoint has a manifest filter and a matching query parameter is included in the request. Compare the configured filter with the parameter names and values, taking care not to disclose sensitive query values in shared evidence. In a controlled test, remove a redundant matching parameter or correct the request syntax, then compare the response. Do not make broad changes to a live endpoint without understanding what the filter is meant to do.
Also inspect Force endpoint error configuration in MediaPackage v2. AWS documents optional 404 responses for conditions such as stale or incomplete manifests, missing DRM keys, and slate input. In failover designs, those responses can be intentional signals while problematic segments move out of the exposed timeline. If the setting is enabled, compare its configured conditions with input interruptions, timeline gaps, key changes, or slate events at the recorded time. Do not disable a failover-related setting just to make the status disappear; first establish why it was enabled and what consumes the signal.
Finally, check whether the upstream content is still arriving and whether its media format is supported by the selected input and endpoint. MediaPackage version and endpoint type affect supported inputs, outputs, containers, and codecs. Compare the actual source and output configuration with AWS’s current documentation for that service generation. A stale or missing segment, an unsupported format, and an incorrect manifest path are distinct possibilities; the request trace should tell you which branch to pursue.
Check the YouTube HLS upload destination
If the encoder is sending the failed request to YouTube, verify the current HLS ingestion URL shown for the stream in YouTube Live Control Room. The encoder must use the YouTube-provided HLS destination and the appropriate HLS stream key or protocol selection. Do not use a MediaPackage egress URL, a guessed YouTube URL, or an RTMP destination in its place. YouTube’s HLS setup instructions explain how to set up an HLS stream.
Inspect the encoder’s output log to see whether it is uploading the expected playlists and segment files to that destination, and which exact upload receives 404. YouTube’s HLS ingestion protocol documentation describes the protocol and its upload requirements, including playlist and segment handling. Check the live documentation for the applicable playlist model, HTTPS transport, media format, naming, and sequencing rules; do not assume that a playback playlist format is automatically valid as an upload.
Confirm the destination has not been replaced since the encoder was configured. A saved output can retain an old URL or session after a stream setup change. Compare the configured host and path with the current value in Live Control Room, without copying a stream key into a public report. If the destination is correct, compare the actual request method, playlist, segment name, and response with YouTube’s current specification rather than retrying the same request indefinitely.
This is also a good point to separate the YouTube leg from any AWS leg. If MediaLive or another source first sends content to MediaPackage, that upstream delivery does not turn the MediaPackage playback URL into a YouTube upload target. Confirm each destination in the encoder or service output configuration. For a general explanation of what an encoder does, the encoder selection guide can help you map the sending device to its destination without conflating ingest and playback.
Isolate a CDN, proxy, or other intermediary
If a CDN or proxy is in the route, compare its response with a direct-origin request where your architecture and access permissions allow that test. Keep the path, query structure, method, and timing as close as possible. If the origin responds differently, inspect the intermediary’s access logs, cache status, routing rules, and request transformations. The mismatch narrows the fault domain; it still does not explain the cause until you see what the intermediary did.
A cached error, an incorrect origin path, a query parameter removed or added in transit, or a rule that sends a request to the wrong origin are examples to investigate, not presumed explanations. Review relevant logs and configuration rather than changing cache behaviour or bypassing the intermediary for all users. A direct-origin test may also be unavailable or may not reproduce the public route, so record its limitations.
Look at response headers and cache indicators alongside status and body. Intermediaries can add headers, replace error pages, and pass through origin responses, so no single header should be treated as conclusive without checking the logging and configuration for that service. Keep the request ID, if present, and line it up with the origin event at the recorded time.
When a 404 occurs only on one path through the system, document that distinction. For example, a direct MediaPackage manifest request succeeding while the same request through a CDN fails points the next check towards the intervening route. It does not justify a blanket conclusion about every CDN request or the underlying manifest until the failing path and response have been verified.
Compare the request with the intended workflow
Write down what each URL is supposed to do, then match the observed request to that role. The following comparison helps prevent a common category error: treating a playback origin as an upload destination, or treating an AWS ingest address as a viewer URL.
| Request in the evidence | Direction and expected role | First checks |
|---|---|---|
| MediaPackage HLS manifest or segment | Client or CDN requests packaged playback from an endpoint | Current endpoint URL and manifest name; first failing playlist or segment; filters and forced endpoint-error settings |
| YouTube HLS playlist or segment upload | Encoder sends HLS media to YouTube’s selected ingest destination | Current Live Control Room HLS URL; request method and upload format; current playlist and naming requirements |
| Request through a CDN or proxy | Client or encoder reaches a service by way of an intermediary | Compare origin and intermediary response; check logs, cache, routing, and request changes |
| Upstream delivery to MediaPackage | Encoder or MediaLive supplies input to the configured AWS channel | MediaPackage generation and ingest mode; authentication and supported input format |
If your workflow is MediaLive to MediaPackage v2, AWS currently recommends a MediaPackage output group configured for CMAF Ingest for new workflows, as documented in its MediaLive output-group guidance. That advice applies to the MediaLive-to-MediaPackage leg. It does not make a CMAF ingest or MediaPackage playback URL interchangeable with YouTube’s HLS upload destination. For MediaPackage v1, use the corresponding v1 input documentation rather than applying v2 assumptions.
For an always-on channel, also check that the source is still sending data and that the output configuration matches the intended service path. If you operate a local continuous stream, the OBS devotional playlist guide is relevant to the source-and-encoder side; it does not replace checking a cloud endpoint’s request logs. For output media compatibility, compare your file and stream characteristics with the YouTube video specifications guide. These references help with adjacent configuration questions, but neither can identify which component returned your 404.
If the immediate pain is keeping a file-based channel running without leaving a computer on, StreamNeo removes that specific operational burden by running an uploaded file as a YouTube live stream with your computer switched off. It does not change the diagnosis of a MediaPackage or YouTube HLS request in a workflow that still uses those components.
Retest, preserve evidence, and escalate
Make one controlled change at a time, and repeat the same request or workflow that produced the failure. Record the new timestamp, host and path, method, status, response body and headers, and the component that logged it. Note whether the failing request moved from a manifest to a segment, disappeared, or now fails at a different host. A changed symptom is useful evidence, but do not claim the root cause until the returning component and request are established.
If the fault remains unclear, assemble a concise evidence bundle for the service or platform team. Include the MediaPackage generation and AWS region, relevant channel or endpoint identifiers with secrets removed, the redacted failing URL, request method and time, response status/body/headers, encoder output settings, source and output media characteristics, and whether the request bypassed a CDN or proxy. Include the exact playlist or segment path that failed, not just the words “MediaPackage 404”.
Keep a small change log with the configuration before and after each test. This makes it easier to restore a setting and prevents two changes from obscuring which one affected the response. For an overnight broadcast, avoid unverified changes to failover behaviour or a live destination during a period when you cannot observe the result. Use a controlled test window where possible, and retain enough logs to compare the next event with the last one.
A useful hand-off states what is known and what is not: “This GET for the manifest path returned 404 through the CDN at this time; the direct endpoint returned a different response,” or “the encoder’s upload to the current YouTube HLS host returned 404.” It should not assert “AWS is broken” or “YouTube rejected the stream” unless the evidence identifies that responder. If the available logs do not show which component answered, say so and request that missing evidence.
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
Why is my HLS playlist returning 404?
The status alone cannot tell you. Capture the exact URL, method, time, response, and responding host, then establish whether it was a MediaPackage playback request, a YouTube ingest upload, or an intermediary response. A top-level playlist, child playlist, and segment are separate requests and can fail for different reasons.
Can a MediaPackage playback URL be used as a YouTube HLS ingest URL?
No. A MediaPackage playback endpoint delivers packaged media to a client or CDN; YouTube’s HLS ingest destination receives encoder uploads. Copy the HLS URL from YouTube Live Control Room for the upload leg, and keep the AWS endpoint URL for its configured playback role.
Does a MediaPackage 404 prove that the endpoint is misconfigured?
No. MediaPackage v2 can be configured to return 404 responses for certain endpoint conditions, and request filters can also be relevant. Verify the exact request and endpoint settings, and check whether the response came from MediaPackage or from an intermediary before changing configuration.
What should I send when escalating a 404?
Send the redacted host and path, method, timestamp, status, body and headers, the service generation, relevant endpoint identifiers, and the first failing playlist or segment. Include encoder output details and whether the request passed through a CDN or proxy. Remove stream keys, authorisation headers, signed values, and account identifiers.