What Is Player-Side Blurring?
A live stream passes through two main stages: the footage is first delivered from the streaming server to the viewer, and then drawn on screen by the player on the viewer's device. "Player-side blurring" happens at the very last link of that chain — after the footage has already reached the viewer's device — where a software layer running in the browser (a CSS filter, canvas or WebGL pass) paints blur over the face and plate regions.
Here is the critical point: with this technique, the stream itself is never blurred. The footage that leaves the server and travels across the internet is raw and unblurred. The blur exists only in that player window, at that moment, as a purely visual veil.
Who Does the Processing? The Viewer's Device
Genuinely processing and blurring video takes serious computing power. When it is done at the source, that load is carried by the platform's GPU servers — a real infrastructure cost. With the player-side approach, that cost is zero, because the entire job is dumped onto the viewer's device:
- Every viewer's CPU/GPU computes the blur for its own screen. A thousand viewers = a thousand separate devices making a thousand separate, mutually independent attempts at "protection".
- On weak devices the layer falters: older phones and low-end computers drop frames, overheat and drain battery; the blur may lag behind or never be drawn at all. The protection claim ends up entrusted to the horsepower of the viewer's phone.
- This is also why it is free for the provider: real source-side processing requires servers and GPUs, while a player-side layer costs the provider practically nothing. That is usually the technical explanation for how a "protection" service can be offered for free or at a token price.
Why Is It So Easily Bypassed?
Because the blur is drawn on the viewer's device, inside a software layer under the viewer's control, removing that layer is also in the viewer's hands. The raw footage has already arrived on the device; the veil the player draws does not change the data that was delivered:
- Anyone with direct access to the stream's source address can watch the footage unblurred in any media player, without ever touching the web player.
- The footage has already been downloaded: a live stream arrives on the viewer's device as small video chunks (.ts or .mp4 segments). Even if the stream address is hidden or token-protected, these raw chunks are visible in the browser's network traffic; they can be saved to disk and played back unblurred in any player, such as VLC. The blur only ever sat on top of the screen — it was never inside the downloaded file.
- A browser's standard developer tools can reveal or disable the visual layers on a page — no expertise required.
- Screenshots and screen recorders aside, every device and every scenario in which the layer fails to run is a scenario in which the raw footage is exposed.
In short: player-side blurring is not a security measure — it is a visual effect. It is not a locked door; it is a lock drawn onto a photograph of the door.
Try It Live: Defeating the Blur with One Click
The sample player below blurs the face and the plate on screen only — exactly like some of the "GDPR player" claims on the market. The "Remove the Blur" button represents the single line of code that any visitor could run in their own browser. (The person and the car in the scene are entirely fictional drawings; no real personal data is involved.)
document.querySelectorAll('.demo-blur').forEach(e => e.style.filter = 'none');
The stream never stopped and the footage never changed — the blur only ever existed on your own screen.
The blur above is assumed to be real protection. Yet press the "Remove the Blur" button and you will watch a single line of code expose the face and the plate instantly. This can be done in an ordinary browser with no expertise whatsoever — because the raw footage has already reached the viewer's device.
Why Is It Void Under the GDPR?
Under the GDPR, recognisable facial images and vehicle licence plates are personal data; in a live stream, the processing and transfer of that data takes place the moment the footage is delivered to viewers. With player-side blurring:
- The personal data (the unblurred footage) is actually transferred to the device of every viewer who opens the stream. Displaying it blurred afterwards does not undo that transfer.
- The GDPR obliges the data controller to implement appropriate technical measures — and that obligation must be met at the source of the data, not at the end of its journey. A layer that can be removed at the viewer's will does not qualify as a technical measure.
- And here is the riskiest part: this approach gives the organisation's decision-makers a false sense of security. Footage published in the belief that "we are blurring it" in fact continues to be transferred unblurred — and in the event of a data breach, the liability rests with the data controller.
Note: this section is provided for general information only and is not legal advice. For your organisation's GDPR obligations, please consult your legal team.
Why Don't We Offer It?
Let us be frank: adding a blur layer on top of a player is simple enough to be done in a few lines of code. yayin.com.tr does not offer it — not because we technically cannot, but as a deliberate choice:
- Every feature we present to a customer as "protection" must still be protection behind closed doors. If the footage reaches the viewer unblurred, the blur on the screen is part of a marketing pitch, not part of a safeguard.
- A false sense of security is more dangerous than no protection at all: the organisation keeps broadcasting in the belief that it is protected.
- Municipalities and public institutions carrying privacy-law responsibility are our largest customer base — we do not sell them visual effects.
Real Protection: Detection + Action at the Source
yayin.com.tr's AI-powered GDPR protection runs at the source of the stream, not in the player: before the footage ever reaches a viewer, the AI on our servers scans your cameras 24/7. When a recognisable face or a readable plate is detected it will — depending on your preference — either simply notify you, or automatically take the camera off air and send an e-mail with an evidence image. No viewer can access footage that has been taken off air; the protection happens to the data itself.
- No identity recognition: the system never asks "who is this?" — it only asks "is there a recognisable face or plate in the frame?" (presence detection).
- 100% local analysis: footage is never sent to any third party for analysis and is never stored.
- Sensitivity and ignore zones are in your hands per camera; 3 ready-made GDPR disclosure-notice templates are included in your package.
The entire system — scan modes, actions, evidence documentation, disclosure texts — is explained step by step in the GDPR Protection guide.
Comparison: Player-Side Blurring vs. Protection at the Source
| Question | Player-side blurring | yayin.com.tr GDPR protection |
|---|---|---|
| Where does the processing happen? | In the viewer's browser (after the footage has arrived) | At the stream source (before the footage reaches any viewer) |
| Whose hardware does the work? | Every viewer's CPU/GPU | yayin.com.tr servers |
| Is the stream itself protected? | No — the raw footage keeps being delivered | Yes — the stream can be stopped on detection |
| Can a viewer bypass it? | Yes, with trivial methods | No — footage that never reaches the viewer cannot be bypassed |
| Its standing under the GDPR | Does not qualify as a technical measure | A technical measure at the source + evidence documentation |
| Why can it be offered cheap or free? | It costs the provider nothing; the load is on the viewer | Requires real server and AI infrastructure |
Frequently Asked Questions
I use a system that blurs in the player — am I GDPR compliant?
Will yayin.com.tr ever add player-side blurring?
Does protection at the source slow the stream down?
Why Did We Write This Guide in Such Detail?
We chose to cover this topic in real depth, technically and legally, because our customers keep asking us the same question: "Other companies blur the footage — why don't you offer this feature?"
Those companies rarely say where the blurring is performed; they simply say "the footage is blurred". What this guide demonstrates is that, technically, the blur is applied in the viewer's browser — that is, on the player. And that is the heart of the matter.
The question is entirely fair, and it deserves a straight answer. The short version is this: what we decline to offer is not a feature — it is an illusion. Player-side blurring is easy to set up, costs nothing in servers, and is easy to market — but as we have shown step by step above, it provides no real protection. As an enterprise service provider, we do not consider it right to sell a solution that protects nothing under the name of "GDPR protection".
Our customers who carry data-protection responsibility — municipalities, sports facilities, public institutions — have the right to know exactly what the service they buy does. This guide is part of that transparency: it lays out the reasoning behind our own choice, and it gives a decision-maker the technical grounding needed to ask the right questions. To us, lasting trust is worth more than a short-lived marketing line.