The playback path that gives the best result is usually the one where the server does least. When a native client can take the source container, codec, audio and subtitles as they are, the server only has to move bytes, and nothing is rebuilt while you watch.
Direct play preserves fidelity and capacity
When the client can demux and decode the file itself, Quven hands over the original and skips the video transcode entirely. Source quality survives. Startup should get shorter, and the same hardware will carry more simultaneous sessions than it could otherwise, which is the part people tend to notice once a second and a third screen start playing at the same time in the evening. Lossless audio and styled or bitmap subtitles get their best chance of reaching the screen in the form the disc intended, too.
Remux is different from transcoding
A remux swaps the transport or the container and leaves the encoded tracks alone. A transcode decodes and re-encodes at least one track, because something at the far end can’t take the source codec, the bitrate, the HDR format or the subtitle path. Quven picks between them per session, so no library item ever gets stamped with one permanent format.
Direct play isn’t a property of the file. It’s the outcome of that negotiation, and the same source might play directly on the television while the laptop next to it wants a remux or a transcode, because the two support different combinations.
There’s one deliberate exception on the server side. A client that can take source bytes normally gets them whatever the file holds, and VVC and H.266 video is where that stops, because the native player can’t decode those yet, so anything in that encoding goes down the ordinary compatibility route and reaches the client over HLS.
You don’t have to guess which path a session took
Settings has an Activity tab, and the Active streams card on it lists whatever is playing on the server at that moment. And you need an administrator profile to open it. The desktop app and the browser client show you the same card.
Each session leads with the answer in plain words: Direct play, no conversion, or Direct video, repackaged, or Converting. Beside that sit the quality, whether the viewer is on your network or reaching you from outside, and the acceleration the server picked when it really is re-encoding. Then come a video row and an audio row, and those are the ones worth reading. A track going out as it was stored shows a single value. A track being re-encoded shows what the file holds, an arrow, and what’s actually leaving the machine.
So that pairing is what tells you where the work went. A converting session names both forms on its video row, while the audio row stays a single value for as long as the original audio is copied through, so you can see that the encoder is busy with the picture and nothing else. The card keeps itself current while the tab is open, which is enough to start something on the television, walk back to the desk and read what the server made of it.
The web client remains a premium fallback
A browser is a superb universal client, although its media surface is narrower than a dedicated player’s. That’s why native desktop and mobile work stays at the centre of Quven, and why the hosted web client serves HLS over the managed relay as a polished Pro fallback. But it isn’t a replacement for native playback.
Measure the real route. A codec label proves nothing on its own. Container support, audio, subtitle type, HDR capability and the network route you’re on will all have a say in the final playback decision.
Which of your screens can actually decode the files you own? Answer that before you size a server around transcoding, and read these paths against the current hardware requirements with one file pulled out of your own library.
Frequently asked questions
How do I tell whether my server is transcoding right now?
Open Settings and go to the Activity tab. The Active streams card will name the mode for every session in words, and the video and audio rows beneath it show you which track’s being re-encoded and which one’s going out untouched. It’s an administrator card, so an ordinary viewing profile can’t see it.
Why does one client direct-play a file that another one transcodes?
The decision belongs to the pair, not to the file: each client tells the server which containers, video codecs, audio codecs and channel counts it can handle, and the server answers for that combination. A television with a broad decoder and a laptop browser won’t get the same answer about the same film, and neither of them should.
Does direct play mean the server has nothing to do?
It means nothing’s being re-encoded while you watch. The server must still read the file off the disk and push it across the network, so storage that keeps up and a link with room on it will still matter, and a session coming in from outside can never beat your upload whichever path it took.