Barb TVPR Project
TV PLAYER REPORT
General Info for this Page
Any critical changes to this page will be communicated directly to Project Owners via Barb Dovetail Basecamp.
Last updates of this page:
Released new iOS library 2.0.0
Released new tvOS library 2.0.0
Released new Android library 2.0.1
Released new Roku library 2.0.0
- 1 PROJECT OVERVIEW
- 2 LIBRARY CODE BASE AND ROADMAP
- 2.1 Our Technology Roadmap
- 2.2 Library Downloads
- 2.2.2 Type Game Console Player
- 2.2.3 Notes
- 2.2.4 Release Date
- 2.2.5 Download link
- 2.2.6 Type Settop Box
- 2.2.7 Notes
- 2.2.8 Release Date
- 2.2.9 Download link
- 2.3 Help with Adapters
- 2.3.1 Why do I need an Adapter?
- 2.3.2 Microsoft Silverlight
- 2.3.3 Brightcove
- 2.3.4 YouView
- 3 UNDERSTANDING HOW TO IMPLEMENT THE SPRING LIBRARIES
- 3.1 Our Measurement Ethos
- 3.2 Documentation
- 3.3 Step-by-Step Guide
- 3.4 General metadata tagging instructions
- 3.5 Live Stream Measurement – Instructions
- 3.5.1 METHOD 1 – “Barb OFFICIAL CHANNEL METHOD”
- 3.5.1.1 INSTRUCTIONS:
- 3.5.1.2 Example tracking call:
- 3.5.2 – deprecated – METHOD 2 – “CONTENT ASSET TRACKING METHOD”
- 3.5.2.1 INSTRUCTIONS:
- 3.5.2.2 Example tracking call:
- 3.5.3 METHOD 3 – “CHANNEL-ONLY METHOD”
- 3.5.3.1 INSTRUCTIONS:
- 3.5.3.2 Example tracking call:
- 3.5.1 METHOD 1 – “Barb OFFICIAL CHANNEL METHOD”
- 3.6 New Media Library Code Releases
- 4 FROM IMPLEMENTATION TO PUBLICATION - PROCESS
- 5 CUSTOMER DATA PRIVACY DOCUMENTATION
- 6 FAQ
- 7 FEEDBACK
PROJECT OVERVIEW
Project Summary
The TV Player Report represents the first stage of Barb Project Dovetail.
As audiences continue to fragment across both content and delivery mechanisms, the stresses of using of a sample survey alone to create and report audience estimates at a granular level increase. Project Dovetail sets out an ultimate aim of augmenting a panel approach with new, granular datasets. In short, raw absolute census data providing the totality of what has been consumed, with the panel providing the context of who has viewed. The resulting merged dataset will allow the full dissemination and analysis of viewing behaviour across viewing platforms, who is watching what, and what incremental and de-duplicated coverage is obtained.
The first stage of this unified vision is to standardise and centrally collect the site centric IP data from all participating broadcasters, enabling a regular account of the size and delivery content through a variety of devices. This means that all broadcaster data will be directly comparable without differing definitions or collection methods hindering the direct analysis.
To this end, Barb has chosen Fifty5blue (formerly Kantar Media) as its supplier of this data. Broadcasters are asked to implement the Fifty5blue Media plugin' library sensor into their media players. In addition to the integration of the Fifty5blue measurement, Barb requires a broadcaster consistent approach to cataloguing and tracking of content. This parallel Content ID project is discussed Barb TVPR Project#Content ID.
Participating Broadcasters
The following companies are currently part of the Barb TV Player Report project:
BBC
Channel 4
Channel 5
ITV
Sky
STV
S4C
UKTV
Current Project Status
For more information on the current project status and schedule, please contact Fifty5blue UK and/or Barb.
Project Teams and Resources
The Fifty5blue project team is led by Fifty5blue Audiences in London, UK. Our technology specialists will assist with your technical queries as you begin and progress each player/platform implementation.
Before you start your implementation we will discuss with you and your teams which of our libraries you should use and be available to answer queries arising from your review of our documentation and testing framework.
We will be directly involved in the sign-off process for your implementation, undertaking a review of the data we receive from your implementation once on a staging environment. You can find out more about how together we verify your stream implementation Barb TVPR Project#FROM IMPLEMENTATION TO PUBLICATION - PROCESS.
Who Do I Contact and When?
General Queries
Please contact us at the following address: uk-tvpr-ops@kantarmedia.com
LIBRARY CODE BASE AND ROADMAP
Our Technology Roadmap
This expert-based forward roadmap is constructed based on BARB-driven industry platform coverage priorities. It is expected that each project stakeholder will engage in the process to agree ongoing solution design and prioritisation. We anticipate being able to build upon our existing technologies to meet many of the new target platforms.
The roadmap contains the following key phases:
Discovery stage
Internal project discovery workshop
Identify the player “library product”, and potential alternatives (if any)
Broadcaster workshop (conference call)
Agree scope and boundaries of solution
Initial library development
POC with selected broadcasters
Final standard library development (incorporating changes where necessary)
Library official release
Individual stakeholder implementations scheduled
Each project stakeholder will have the opportunity to critique and validate the roadmap, and that in-house plans across the project lifecycle will be shared with Kantar. A regular 3-monthly review process will be used to review and update project platform priorities between Barb, Kantar, and each broadcaster stakeholder.
Library Downloads
Which library do I need?
You can find our currently available libraries below. We will work with you to identify which library you should use as part of your initial implementation planning discussions.
Streaming libraries and JavaScript downloads
Type Desktop Player | Notes | Release Date | Download link |
|---|---|---|---|
Streaming JavaScript | For the web environment or other Java Script capable environments (not natively supported) 3.0 | Feb 24, 2025 | |
Library for Flash/ActionScript 3 |
| Aug 5, 2013 | |
Library for Flash/OSMF2 |
| Oct 2, 2013 | |
Plugin for Brightcove |
| Mar 11, 2014 | |
Type Mobile Player | Notes | Release Date | Download link |
Library for iOS | May 4, 2025 | ||
Library for Android | Streaming Android newly released on this page 2025-06-16, fixing "java.lang.NoClassDefFoundError"-issue! | May 4, 2025 | |
Type Big Screen Player | Notes | Release Date | Download link |
Library for tvOS | May 4, 2025 | ||
Type Game Console Player | Notes | Release Date | Download link |
Library for Xbox | Supports Xbox One | Jul 15, 2021 | |
Type Settop Box | Notes | Release Date | Download link |
Library for Roku |
| May 4, 2025 |
Help with Adapters
Why do I need an Adapter?
When a library specifically suited for your player is not available, you can still use our measurement by implementing an "adapter". This is a small piece of code that ensures the connection between the Media library and your player. It is typically written by yourself; and Fifty5blue can provide consultancy to aid you with this.
Documentation about how to integrate the libraries by using an adapter is available in the general documentation Implementation of Stream Measurement for Barb TV Player Report.
Some examples that require an adapter are here below.
Microsoft Silverlight
Brightcove
For Flash: /wiki/spaces/KASRLCS/pages/159726836
Not available natively yet for Android or iOS. It can be done currently with the available Android and iOS Spring libraries + a custom adapter to connect the library with the Brightcove API.
YouView
YouView runs a proprietary version of Flash and they do not use "flash.net.NetStream" but "MediaRouter" instead. An adapter is needed in this case to extend flash.net.NetStream and grab information from MediaRouter such as the position and duration. It is similar to what is demonstrated in NetStream adapter for the flash.media.Sound object example in the documentation.
The library does not rely on flash.external.ExternalInterface being available or cookies. The ExternalInterface is normally used for passing an "unload" call from the browser back to the library in case the browser is being closed. However, this "unload()" method can also be triggered from inside the Flash application itself.
UNDERSTANDING HOW TO IMPLEMENT THE SPRING LIBRARIES
Our Measurement Ethos
The Fifty5blue Media technology was conceived and developed to be as platform-agnostic as possible.
Every video player has at least the possibility to report a playhead-position and the duration of the video (enables the user to see how long the video is and can keep track of the progress). These two variables form the basis of our measurement system, and they are common in every environment.
We capture a combination of environment-specific identifiers and additional metadata to attribute each streaming heartbeat to a session and a device.
Documentation
This is one of the most important documents because it describes in a general way how the measurement works. Reading and understanding this document is crucial to taking full ownership of the implementation process.
Our comprehensive Implementation of Stream Measurement document describes how the Fifty5blue libraries work. It includes sample implementations and guidelines for writing a custom adapter for our libraries.
In order to measure any streaming content, a sensor on the client side is necessary, which measures which sequences of the stream were played by the user. These sequences can be defined by time intervals in seconds - therefore, the player or the playing instance must be able to provide a method for delivering the actual position on the stream in seconds.
The regular reading of the current position allows the tracking of all actions on a stream. Winding operations can be identified, if there are unexpected jumps in reading out the position. Stop or pause operations are identified by the fact, that the current position will not change.
User actions and operations like stop or pause are not measured directly (not player event based) but are instead derived from measuring the current position on stream.
Specific app library documentation are included in the library deliverables themselves.
Step-by-Step Guide
The step-by-step guide gives a graphical and concise overview of HOW, WHEN, and WHY to measure. We recommend to have look at it: here.
General metadata tagging instructions
It is essential that you ensure the standardised functions and values are passed in your library implementation.
How to map:
| Metric / Dimension | Description | Variable Namespace | Required for | Source | Notes |
|---|---|---|---|---|---|---|
1 | sitename | unique Fifty5blue system name per broadcaster - | sitename | mandatory | Assigned by Kantar | "bbcios", "itvdotcom", "c4android", etc NOTE: You will be assigned "test"-sitenames for testing purposes! |
2 | player | broadcaster website or app player being used | pl | mandatory | Free choice | "skygo", "demand5", "4oD", etc |
3 | player version | version of media player or app being used | plv | mandatory | Free choice | "1.4.1.1", "1.0.5" |
4 | window dimension width | width of the stream window, embedded or pop-out | sx | optional | Pass value on to Library | recommended although can be blank where unavailable |
5 | window dimension height | height of the stream window, embedded or pop-out | sy | optional | Pass value on to Library | recommended although can be blank where unavailable |
6 | content id | unique BARB system program ID | cq | mandatory | Following BARB convention | linked to separate content id database and master file:
|
7 | stream | description of the content stream | stream | mandatory | Following BARB convention | descriptors of the type and delivery of content, not an identifier of the content itself.
|
8 | content duration | duration of the video being played, reported in seconds | dur | mandatory | Pass value on to Library |
|
9 | Physical Content Source | Origination source of Sky content | ct | optional | Pass value on to Library |
|
10 | Registration ID | Broadcaster application user registration ID | login | optional | Pass value on to Library |
|
Before you start
Once you have read the documentation, and before you begin your implementation, please contact us so we may review together the behaviour of your player and therefore the scope of the implementation.
LIVE and TESTING environments are separated by the sitename. You will be given sitenames for both these purposes.
Live Stream Measurement – Instructions
The instructions for measuring your Live TV streams will vary depending on the features of your Player.
Instructions on how to map the “cq”, “stream”, and “dur” variables for Live TV streams are detailed in the General metadata tagging instructions section. As your implementation requires that you also provide access to other functionality, this section declares in full the Live TV stream requirement.
As part of your implementation, to ensure that all your Live TV streams are included in the BARB TV Player Report production you must inform BARB and our UK Project Manager of the following information:
Complete up-to-date list of your Player channel identifiers (or Service Key identifier) including regional programming identifiers
The official “known as” name of each channel identifier
Date from which the Live TV channel becomes available online
Player platforms the channel is available on
Identify whether the channel carries commercials, and how they are handled
The agreed offset between broadcast time and streaming time for your channel. A table of all existing offsets can be seen here.
METHOD 1 – “Barb OFFICIAL CHANNEL METHOD”
This is the recommended method for implementing livestreams. This method assumes that for live simulcast streams, your Player will not provide any indicator of where a stream crosses a programme boundary. It also assumes your Player will not provide any unique content identifier.
You will call trackMethod whenever a Live TV channel stream begins; a new View will be created. Every time the Live TV stream is pause/resume no action is required. When the Live TV stream is stop/start you will need to stop the library and once again call trackMethod. By doing this you will correctly create a new View.
INSTRUCTIONS:
Map the “dur” variable for Live TV streams as detailed in the General metadata tagging instructions section.
Populate the channel name (or Service Key identifier) into the stream variable as instructed in the General metadata tagging instructions section.
Set the Live TV channel identifier within the stream variable, e.g.
live/channelone
live/channeltwo
live/channeltwosouth
live/channelthree
live/channelfour
live/F230
live/X234
Supply the playhead position (“pst” variable) using the linear broadcast date and time as a timestamp value in seconds. You will need to account for the fact that the delay between linear broadcast and online playout may vary between platforms. Your Player should retain control over how any delay versus linear broadcast is handled.
Handle FFWD/RWD (“tricks”) by updating the broadcast date and time in the pst variable, i.e. for the scenarios commonly understood as “Scrubbing”, “Live Rewind” and “Live Restart”.
Example tracking call:
http://tvplayerplugintest.2cnt.net/j0=,,,,v=A%201.1.0+app=mobiletestapp+pl=mobiletestapp+did=868e10589389fd35+aid=bb97262e90e4ef1f+sy=768+plv=1.0.0.0+sx=1196;+,vt=16+uid=3a8w7ib+stream=live/channelname+pst=,,0+0+na8vcw;+,1407932109+1407932126+na8vcw;;+sy=360+dur=0+sx=640;;;;?lt=hysmffp1
– deprecated – METHOD 2 – “CONTENT ASSET TRACKING METHOD”
This method must only be used if the Live TV channel stream can be restarted at each programme boundary, i.e. your Player must know the programme boundary and relevant EPG information, enabling you to create a new View for each programme. It assumes that your Player can handle the tracking of programmes delivered as part of a live stream in the same way as on-demand content.
INSTRUCTIONS:
You will call trackMethod whenever a new programme on your Live TV channel stream begins; a new View will be created every time. Pause/resume of a Live TV programme represents a continuation of the same stream View. Only when the stream is stop/start or background/foreground will you reset the playhead position to “0” and create a new View.
Map the “cq” variable using the unique BARB system program ID, as detailed above in the General metadata tagging instructions section,
Map the “dur” variable for Live TV streams as detailed above in the General metadata tagging instructions section
Set the Live TV channel identifier within the stream variable, e.g.
live/channelone
live/channeltwo
live/channeltwosouth
live/channelthree
live/channelfour
live/F230
live/X234
Supply the playhead position (“pst” variable) using an offset in seconds, in the same way as for on-demand steams. It is not necessary to expose a variable delay within your player or to pass it to the measurement system.
Handle FFWD/RWD (“tricks”) by updating the offset, in the same way as for on-demand steams.
Example tracking call:
http://tvplayerplugintest.2cnt.net/j0=,,,,v=A%201.1.0+app=mobiletestapp+pl=mobiletestapp+did=868e10589389fd35+aid=bb97262e90e4ef1f+sy=768+plv=1.0.0.0+sx=1196;+,vt=16+uid=3a8w7ib+stream=live/channelname+cq=C4:12345/2+pst=,,0+0+na8vcw;+,1+16+na8vcw;;+sy=360+dur=0+sx=640;;;;?lt=hysmffp1
METHOD 3 – “CHANNEL-ONLY METHOD”
This method assumes that for live simulcast streams, your Player will not provide any indicator of where a stream crosses a programme boundary. It also assumes your Player will not provide any unique content identifier. Moreover the broadcast date and time cannot be exposed to the measurement tracking system.
INSTRUCTIONS:
You will call trackMethod whenever a Live TV channel stream begins; a new View will be created. Every time the Live TV stream is pause/resume or stop/start, the position in stream is reset to “0” and a new View is created.
Map the “dur” variable for Live TV streams as detailed above in the General metadata tagging instructions section
Populate the channel name (or Service Key identifier) into the stream variable as instructed in the General metadata tagging instructions section.
Set the Live TV channel identifier within the stream variable, e.g.
live/channelone
live/channeltwo
live/channeltwosouth
live/channelthree
live/channelfour
live/F230
live/X234
Example tracking call:
http://tvplayerplugintest.2cnt.net/j0=,,,,v=A%201.1.0+app=mobiletestapp+pl=mobiletestapp+did=868e10589389fd35+aid=bb97262e90e4ef1f+sy=768+plv=1.0.0.0+sx=1196;+,vt=16+uid=3a8w7ib+stream=live/channelname+pst=,,0+0+na8vcw;+,1+16+na8vcw;;+sy=360+dur=0+sx=640;;;;?lt=hysmffp1
New Media Library Code Releases
Each and every time our library sensor technology is updated, it is subject to a strict release checklist process as outlined below:
Component Testing
We test the different components of the library with the help of special test-app (Fifty5blue made) that allows
changing internal parameters of the library. With this app we trigger the overflowing of configured maximum values,
in order to make sure that everything is handled correctly.For iOS specifically, we test for memory leaks and search for potential memory leaks.
Tests are conducted with the toolsXCodeandInstruments.These tests are conducted for every new release of the library; and of course also tested on any new feature should
there be one.
Functional and System Testing
Here we test if the data from the libraries are leading to correct results in reporting. All components of the system are being
passed through here.