TV2Play's 720p desktop cap lives in the client
I did not contact TV2 before publishing this post.
The Problem
So I’m paying for TV2Play, right? And I’m sitting at my desktop with a 1440p monitor, trying to watch a show, and it’s stuck at 720p. Meanwhile my phone gets 4K. My smart TV gets 4K. But my actual computer? 720p max.
I got curious and opened devtools. The web player hardcodes “720P” in its API request, and that’s the only thing enforcing the cap.
Where the Cap Lives
TV2Play has Widevine DRM set up properly. The licensing works, keys get issued, video plays. But the part of Widevine that’s meant to decide who gets which quality, the security levels, isn’t being used for that. The server doesn’t check what the client is capable of. The player sends “give me 720p” and the server returns 720p.
Here’s what the web player sends:
URL: https://play.tv2api.dk/
Payload:
{
"query": "query play_web_Playback(...)",
"variables": {
"resolution": ["720P"], // ← This is the problem
"codec": ["H264"],
"drm": ["WIDEVINE", "NONE"],
"drmSecurityLevel": "SW_SECURE_DECODE",
"format": ["DASH_MULTI_PERIOD", "DASH_SINGLE_PERIOD"],
"sourceType": "application/dash+xml",
"dynamicRange": ["SDR"],
"maxBPS": [],
"lar": ["IGNORE", "YOSPACE_CS"],
"hdcpVersion": "1.4"
}
}See that "resolution": ["720P"] line? Change it to "2160P" and you get a 4K stream.
Asking for More
Here’s the same request asking for 4K:
URL: https://play.tv2api.dk/
Payload:
{
"query": "query play_web_Playback(...)",
"variables": {
"resolution": ["2160P"], // ← Changed from 720P to 2160P
"codec": ["H264"],
"drm": ["WIDEVINE", "NONE"],
"drmSecurityLevel": "SW_SECURE_DECODE",
"format": ["DASH_MULTI_PERIOD", "DASH_SINGLE_PERIOD"],
"sourceType": "application/dash+xml",
"dynamicRange": ["SDR"],
"maxBPS": [],
"lar": ["IGNORE", "YOSPACE_CS"],
"hdcpVersion": "1.4"
}
}And it works, partially. The server returns the manifest for the 4K stream, and the license server issues a valid content key, even at L3.
There’s a catch, though: codec support.
The web player’s DASH implementation doesn’t support HEVC (H.265). The 4K streams are only encoded in HEVC, so the player can’t decode the video track even with a valid key.
So the browser player can’t actually render 4K. What does work is 1080p. It’s still H.264, the player handles it fine, and it’s a big step up from 720p. My extension defaults to 1080p for exactly that reason. It’s the highest quality that plays back in the web player.
So the restriction is 100% client-side. It’s one value in a frontend request. Ask for 2160P and the API gives you a 4K manifest and a valid key.
To be fair, I get why you’d cap desktop to save bandwidth. 4K HEVC is several times the bitrate of 720p H.264, and that adds up fast across a lot of streams. Plenty of services do it. If that’s the reason, it’s a normal product decision.
It’s just a strange place to put the cap. My TV and my phone both get 2160P on the same subscription, and the phone is the one device that’s actually on a metered connection half the time. The desktop, sitting on unmetered home fiber, is the only thing capped. And it can’t play the HEVC 4K streams anyway, so the most it would ever pull is 1080p H.264. The cap ends up saving bandwidth on the cheapest stream in my household. My guess is it’s something nobody has revisited, not a deliberate plan.
What I’d Suggest
The Widevine setup is already there, so most of the work is done.
Widevine has security levels:
- L1: Hardware-backed, gets you 4K
- L2: Software with secure decoder, usually 1080p max
- L3: Software only, usually capped somewhere between 480p and 720p
The idea is that the license server checks what security level the device supports and only issues keys for the matching renditions. Desktop browser with L3? You get the lower tier. Certified Android TV with L1? Here’s your 4K.
Right now the license server will issue a key for 4K content to an L3 client, so the resolution limit depends entirely on the client asking nicely. Enforcing it server-side, based on security level, would make the cap actually mean something.
Why I Care
Someone’s gonna say “just use the modified request and stop complaining.” Fair, and that’s what I ended up doing.
But the cap doesn’t really stop anyone determined to copy content, because the 4K key is available to any client that asks for it. The people it does affect are paying subscribers watching on a desktop, like me.
If the cap is about bandwidth, I’d honestly rather see that said out loud. A quality selector with a note about data usage, or a plan tier, would be totally fine with me. Right now it just looks like the desktop player is broken.
The Encoding
The encoding could also be better.
Netflix and Disney+ use per-title encoding. They analyze each show to figure out optimal bitrates, detect scene changes, and use different settings for animation, sports, and movies. From what I can see, TV2Play’s streams look like fixed bitrate with fast encoder presets.
See the Difference Yourself
Same frame from the same show:
Same frame at 720p and 1080p. The 1080p stream is a lot sharper.
What Fast Presets Cost
Fast encoder presets save processing time, but the trade-offs tend to be:
- Blocky artifacts in action scenes
- Wasted bitrate on static shots
- No scene-based optimization
Per-title encoding would probably get better quality at the same bitrate, or the same quality at a lower one, which also helps with the bandwidth question above.
The Workaround: Chrome Extension
In the meantime, I made a Chrome extension: TV2Play Quality Fix
It intercepts the API call and swaps “720P” for “1080P”, since the web player can’t play HEVC anyway. It doesn’t touch the DRM. It just asks for a quality the player already supports.
TL;DR
TV2Play’s desktop 720p cap is set by the client, and the license server will issue keys for 4K content to L3 clients. Enforcing resolution through Widevine security levels would make the cap real, and per-title encoding would make every stream look better. Until then, the extension gets you 1080p.
- Marius, who just wants to watch TV in 1080p