The Hidden Work Behind a Paste
OmniGet's first difficult decision happens before it downloads anything: it must decide what a pasted URL represents and which kind of evidence is needed to handle it. This chapter examines that resolver and preview stage so readers can predict why OmniGet treats a direct file, an HLS playlist, a recognized platform, and an ordinary web URL differently. The practical payoff is a better reading of the app's choices: a preview is not decoration, and a downloader is not one universal extraction path.
The distinction matters because URLs are poor descriptions of user intent. A link may point directly to bytes, identify a page whose media must be discovered, refer to a playlist rather than one item, or lead to a host where the request only works with a particular session. OmniGet turns that uncertain input into a more explicit media model before the queue takes responsibility for the transfer.
Routing is a form of evidence gathering
A single universal path sounds simpler than several routes. In practice, it would either repeat work unnecessarily or assume facts that are not true for every source. If a URL already ends in a recognizable file extension, invoking a full extractor adds a process and a failure surface without revealing much. If a page is a YouTube video or an Instagram post, a direct HTTP request may retrieve an HTML shell rather than the media. If a URL is an HLS playlist, the useful object is a manifest and its fragments, not one ordinary file response.
OmniGet therefore begins with lightweight recognition. Its platform layer parses the host, checks special schemes such as magnet links and peer-to-peer codes, and recognizes a broad set of platform identities. It also checks for direct-file extensions. This is not a promise that a recognized host will succeed; it is a way to select the next question. The resolver asks, in effect, “What kind of source is this, and which component knows how to investigate it?”
For recognized platforms, native code can carry platform-specific knowledge or session behavior. The repository includes platform modules for services such as YouTube, Instagram, Reddit, Twitch, Pinterest, Bilibili, and others. The point is not that every host has a completely separate universe inside the app. The point is that some sources expose enough recurring structure to justify a focused path, especially when the app needs more than a generic media URL.
Direct media follows a different route. The generic downloader checks whether a URL looks like HLS or a direct video or audio resource. A direct path can build a media description from the URL itself, use the original resource as the available quality, and pass the request to a streaming downloader. HLS still needs special treatment because a playlist can reference many fragments and may require a referer, cookies, or a playlist text captured from the browser. The input looks like a URL in both cases, but the transfer contract is different.
Everything else can go through yt-dlp. Here yt-dlp is not merely a last resort; it is the project's broad compatibility layer. OmniGet asks it for structured information rather than guessing from a page title or launching a blind download. That lets the app keep one user-facing flow while using a mature extractor for the long tail of sites that do not justify native handling in the desktop code.
The resulting architecture is layered rather than uniform:
- platform recognition narrows the problem;
- native code handles sources that need focused knowledge;
- direct and HLS paths avoid unnecessary extraction when the URL already identifies a transfer;
- generic yt-dlp covers the long tail and supplies structured metadata.
These are not four competing products. They are four answers to different evidence conditions. A direct file provides a strong hint about what to fetch. A recognized page provides an identity but may need an extractor. An unfamiliar page provides less certainty and benefits from a general engine. An HLS URL provides a playlist-oriented transfer rather than a single finished file.
Why the same-looking input can become a different job
The difference becomes clearer when the user pastes three URLs that all appear to point at video. The first may end in .mp4 and contain enough information to name the output from its path. OmniGet can prepare a direct-media description instead of first asking an extractor to reconstruct a page. That saves work, but it does not remove the need for the later transfer checks: a server can return an access page or an expired response while still using a successful-looking HTTP exchange.
The second may be a page on a recognized platform. Its host tells OmniGet which native knowledge is available, but the host alone does not reveal the final stream. The app may need to ask for metadata, select a representation, carry platform-specific headers, or use the user's session. A recognized identity narrows the search; it does not prove that the current account can open the requested item.
The third may be an unfamiliar page with a media player. That is where generic yt-dlp is useful. It can inspect the page through its extractor ecosystem and return structured formats without OmniGet having to maintain a custom parser for every service. The trade-off is dependency exposure: if the upstream extractor changes, if a JavaScript runtime is required, or if the platform introduces a login or rate limit, the generic path inherits that uncertainty.
HLS makes the distinction especially visible. An HLS URL is not usually a finished video file; it is a description of a sequence of media fragments. The downloader must retrieve the playlist, follow its references, combine the resulting streams when needed, and preserve the page context that authorizes the request. When a browser player exposes the playlist only through a blob: URL, the extension may send the playlist text itself because the synthetic browser address is not a usable network location. The route is chosen not for conceptual elegance but because the source has a particular shape.
Routing also decides what can be known early. A direct URL may provide a filename but no author, duration, or thumbnail. A platform extractor may provide rich metadata before the actual media request. A generic page may return several format records that need to be condensed into meaningful quality choices. OmniGet cannot promise that every route produces the same preview fields, so the media model has to allow missing values rather than inventing them. The absence of a thumbnail is weaker evidence than the absence of a playable format, and those two gaps should not be treated as the same failure.
This is why the resolver is part of the product's reliability story, not merely an optimization layer. Choosing an unnecessarily broad path can create extra startup time and extra opportunities for a platform to reject the request. Choosing a path that assumes too much can produce a misleading preview or an unusable file. A route is good when it matches the evidence available from the input and leaves the next uncertain question visible.
From a URL to a media model
Once OmniGet has chosen an investigation path, it needs more than a boolean answer such as “supported” or “unsupported.” The generic yt-dlp path requests structured metadata and extracts a title, uploader or author, duration, thumbnail, webpage URL, media type, and available video heights. It examines the formats to determine whether video is present; a source with no usable video stream is treated as audio. Distinct heights become visible quality options rather than a long list of nearly duplicate format records.
That transformation is important because it gives the user something to decide about. A page title answers “what might this be?” Duration helps reveal whether the result is a short clip, a lecture, or an unexpectedly long playlist item. The media type influences whether the user should expect a player, an audio-only result, or another local tool. Available heights make quality a concrete choice instead of a hidden command-line expression.
The app also avoids making every preview request independent. The queue keeps a bounded metadata cache, and simultaneous requests for the same URL are coordinated so that several UI actions do not launch redundant extraction work. Prefetching can obtain information before the user starts a download, but it is also bounded: the point is to make the interface responsive without creating a storm of yt-dlp processes that competes with active transfers.
The preview is therefore a small control plane. It does not move the main payload yet, but it determines which payload the user believes they are requesting. It also gives the queue a reusable object to carry forward: title, author, thumbnail, duration, media type, and selected options can accompany the job instead of being rediscovered at every stage.
The sequence has two important boundaries. First, the resolver owns route selection, while the preview and queue own the user-visible choice. Second, metadata is evidence about an external source at a particular time; it is not ownership of the source and not a guarantee that the same formats will remain available when the transfer starts.
Quality is a constraint, not a promise
OmniGet's quality selection illustrates why a friendly control can still encode a nuanced rule. When a user asks for a height such as 720p, the generic path looks for the highest available option at or below that height. If there is no suitable numeric height, it can fall back to a matching label or to the first available quality. When no distinct qualities are found, the model offers a “best” fallback rather than pretending it knows more than the extractor returned.
This behavior is more useful than treating a quality label as an exact contract. Suppose a platform exposes 480p and 1080p but not 720p. A cap of 720p should not silently select 1080p just because it is the next visible number; the point of a cap is to respect the user's limit. Conversely, a source may expose only one representation, in which case “best” describes the available choice rather than a standardized resolution.
The selection can still fail later. A format may disappear between metadata retrieval and download, a platform may require a different client, or a native extractor may apply its own rules. OmniGet's generic path includes controlled fallbacks for format errors, but those are recovery from a known mismatch, not a guarantee that every requested quality exists. The preview makes the choice explicit; it cannot freeze a remote service.
The same qualification applies to thumbnails, authors, duration, and media type. They are useful for organizing the queue and judging whether the link is the intended item, but they are supplied by an extractor or source response. A stale cache can preserve old information for a short period, and platform-specific downloaders may expose different metadata behavior. The model improves decision quality without turning remote metadata into certainty.
That is why the resolver stage belongs inside the local-artifact chain rather than outside it. Before OmniGet can preserve a file, it must establish enough identity to avoid saving the wrong thing; before it can schedule work, it must expose enough choice to let the user select a quality or mode; before it can claim success, it must still validate the transfer. Each stage narrows uncertainty, but none eliminates the external source's ability to change.
The route determines the next boundary
Once a media description and a quality choice exist, OmniGet can hand the job to the queue. But that handoff does not mean the desktop process has everything it needs. A public direct file may proceed with an ordinary request. A page discovered through a browser may need cookies or a referer. An HLS playlist may have been visible only inside a page player. A platform extractor may need the browser session even though the preview itself succeeded.
This is the key consequence of layered routing: the next unresolved dependency depends on the route already chosen. The project does not add a browser extension because every URL needs one, nor does it use yt-dlp for every direct file because generic coverage is always desirable. It adds each layer when the source's evidence and access conditions justify it. The next question, then, is what happens when the browser knows something the desktop app does not.