Supported Video Players & Fullscreen Behavior

Supported players

The SDK inspects your page's video element and its surrounding DOM to identify the player library in use, then applies a player-specific adapter for ad presentation and fullscreen handling.

Player not on the list?

If your page uses a player not in the supported list, reach out to your BRNDTS integration contact before launch.

Detection

Player detection runs automatically against your configured selector; no player-specific configuration is required on your end.

The detection rules above (class names, attributes, URL patterns) aren't fixed on our side. If your integration uses a player or a markup pattern we don't yet recognize, let your BRNDTS integration contact know and we can add or adjust detection to match your setup.

Player sizing

Your player's rendered size decides which ad formats can serve. This is the reference for the minimum, what serves at each size, and how portrait, floating and resizing players are handled.

BRNDTS ads render inside your own player, in one of two styles depending on the strategy configured for you:

• Squeezeback — the SDK briefly scales the video down and renders the creative at full size in the space that frees up. The video is never reduced below 50%. The sizing rules below describe this mode.
• Overlay (smart / realistic) — the creative is placed over the video without resizing it, sized to fit within the video region. For smart and realistic, the model chooses a placement that avoids subtitles, scoreboards and on-screen graphics.

Minimum size

The smallest player that actually shows an ad is around 408 × 224 in landscape, or about 320 × 364 in portrait (where the ad stacks full-width below the video). Below that there isn't room for a creative once the video is squeezed, so nothing is shown. Any normally-sized player is well clear of this; it only matters for very small or collapsed players.

The format is chosen from the rendered size of the player, not the browser window. The SDK frees space by squeezing the video (down to its 50% floor), and a format is eligible only if it physically fits that space — so a smaller player serves smaller formats and a larger player also admits the big ones. Nothing is ever stretched, cropped, or pushed outside the player.

What serves at each size

Milestones for the standard set, measured by running the layout engine over each player size. A larger player admits larger formats; each step also serves everything smaller.

Player size	Largest formats that fit
~408 × 224 (smallest)	234×60 half banner
~480 × 270	+ 150×150, 180×150 squares; 300×50 banner
~640 × 360	+ 250×250, 200×200 squares; 468×60, 320×100 banners
~720 × 405 (good)	+ 300×250 medium rectangle
~1280 × 720 (recommended)	+ 970×250 billboard, 728×90 leaderboard
~1920 × 1080 (optimal)	+ 300×600 half-page, side-rails

Floating & resizing players

Supported. The SDK watches the player container with a ResizeObserver: when the player floats, docks, or otherwise changes size, the layout is recalculated and the ad re-renders live to the new size. An orientation change or a fullscreen transition re-presents cleanly. If a float shrinks the player below the minimum serving size, the ad is withdrawn and then restored automatically once the player regains space.

Notes

• Rendered size, not file resolution — what matters is the player's on-page box after your CSS and responsive rules, not the resolution of the video file.
• If a player can't fit the formats you expect (a fixed embed, a small floating dock), raise it with your BRNDTS integration contact — we can confirm the eligible formats and tune the strategy for your layout.

Fullscreen ad presentation

The mechanism differs by platform because iOS Safari behaves differently from every other environment. The same ad overlay stays on top of the player in all three cases, but how it gets pinned there changes.

Desktop & Android

Fullscreen uses the standard requestFullscreen() API directly on the player's container. If the browser doesn't support the API, the SDK falls back to a CSS-only fake fullscreen instead, pinning the container full-viewport and toggling overflow: hidden on the page body.

iOS

iOS uses a different method because iOS Safari hijacks native video fullscreen (webkitEnterFullscreen) into its own full-screen video chrome, which would bypass the ad overlay entirely. To prevent this, the SDK intercepts fullscreen entry points on the underlying <video> element and container before iOS can act on them, and redirects to the CSS-based fallback instead.

A number of iOS quirks are compensated for automatically: safe-area/notch handling via viewport-meta toggling, stacking-context fixes so the fullscreen overlay isn't trapped behind other page content, scroll-position correction after entering fullscreen, a relayout nudge to force iOS to re-measure the fullscreen box on device rotation, and touch-scroll prevention outside the player during fullscreen. None of this requires publisher-side configuration.

iFrame players (YouTube, Dailymotion)

Embedded YouTube and Dailymotion players run inside a cross-origin iframe the SDK doesn't control, so it can't observe fullscreen state on the provider's own controls, which means it can't know when to keep the ad overlay on top in fullscreen either.

On iOS in particular, calling the native requestFullscreen() on the iframe wrapper causes iOS to hijack the iframe's internal <video> instead, so for these two players the SDK forces the CSS-only fallback immediately, on every platform, rather than attempting the native API first.

Because reparenting an iframe in the DOM forces it to reload (restarting playback), the iframe and its overlay are pinned in place via CSS only, without moving the iframe itself.

Custom control bar workaround

The objective is to be able to show ads in fullscreen on these players too. The current workaround: the SDK renders its own control bar, including its own fullscreen button, below the player. That button drives fullscreen directly on the SDK's own container element instead of the iframe, so detecting fullscreen state never depends on reaching into the iframe at all, and the ad overlay stays in place.

EX.CO

EX.CO fullscreens its own player root (the data-pbs-root element) rather than the SDK's container. The SDK recognizes that element as its own fullscreen target, so the standard fullscreen path applies and the ad overlay is kept on top without any CSS fallback.

Sticky mini-player

When EX.CO docks the player into its floating sticky mini-player, ad presentation is suppressed and any visible ad overlay is torn down — the mini-player is too small to present into. Content keeps playing, and presentation resumes automatically once the player returns to its in-page position. This is distinct from an EX.CO ad break (its own pre-roll or mid-roll slots), which suspends BRNDTS ads for the duration of the break.