A common challenge in the NoTube integration process with respect to the broadcaster’s environments is the connection with existing legacy systems that, in most cases, are content management systems (CMS) dealing with newscasts, advertisement, tv-programmes, etc.
Legacy CMS are usually proprietary, closed software that the broadcaster is not likely to modify without a proper motivation, hence a set of data needs to be collected from them:
- Describe the existing environment in terms of high level blocks (i.e.: involved data bases, legacy systems, testing/production phases, etc.)
- Describe a typical workflow (e.g.: The News is produced, The News is stored within the internal DB, the legacy system extracts metadata from the News, the News + metadata are prepared for broadcasting – multi-channel delivery -, the News is broadcasted – IP, air, …-).
- Highlight which parts of the current environment can be improved by the adoption of NoTube (e.g.: existing like: metadata extraction, multi-channel delivery, audiovisual ingestion, etc. OR additional like: metadata enrichment,
recommendation of potentially interesting News, etc.
- What is the expected impact of NoTube integration? Could it alter the current
workflow? Is it expected to be a key-feature or an additional feature that
could be considered as optional?
- What are the potential threats? E.g.: copyright loss, proprietary data leak, etc.
At the same time, from the platform perspective is important to focus on the technical level where the main obstacle is represented by proprietary contents (data and metadata) formats to be managed in order to enable a smooth integration. The following list of questions represents a good starting point for services developers starting from scratch, basing on the current experience:
- Are broadcasters using standard metadata formats?
- Are broadcasters using standard audio/video formats?
- What is the effort required to create a metadata mapping and conversion service(s) in order to integrate with NoTube?
- Is it possible to rely on already existing metadata conversion services to enable the integration or is it necessary to create ad-hoc services everytime?
- Is it possible to rely on already existing audio/video processing services to enable the integration? Is it necessary to create ad-hoc services everytime?
- Are transcoding services needed and if yes, how they will impact on the integration?
Provided that it sounds reasonable to perform 3 major steps in order to integrate a
legacy CMS in NoTube:
- Metadata level
- Expose metadata (related to News, ads, tv-programmes, etc.)
- Convert the exposed metadata in a standard format
- Content level
- Expose media contents
- EPG (web-based services)
- Audiovisual chunks through air, IP
- Process media contents
- Smart cropping, etc.
- Expose media contents
- User level
- Centralise the management of personal profile
- Manage static and dynamic (user habits) data integrating with Social Networks
- Integrate the NoTube User Portal
A number of activities have been performed by the Consortium for the above bullets in support to the three use cases, showing that this vision appears to be the right direction to follow in order to obtain tangible results. For instance 1.a is comprised in each use case as part of each broadcaster’s environment (i.e.: ANTS Server for UC 7,a, iFanzy for UC 7.b, BBC repository for UC 7.c). Bullet 1.b is addressed by WP2: a set of services has been designed to support initially UC 7.a, providing metadata conversion services between the proprietary Prestospace format and the TV-Anytime standard chosen for NoTube. Bullet 2.a is related to a number of cross-platform activities involving WP1 as well as the individual use cases leading to the design and development of specific services that turned out to be generic enough to be added to the whole set of NoTube services; for instance the ingestion services from UC 7.a allow to ingest audiovisual contents that can be air-broadcasted instead of just IP-exposed. Bullet 2.b is related to WP4 and could add interesting features on top of the already existing media contents. Smart cropping is one of those. The last bullet is a shared requirement and is exactly one of the major activities WP6 is working on. The previous blog articles provides a deeper explanation of the envisaged user portal and its role.
I’s nice to see that the incoming evaluation phase will be very useful in this respect since targeting exactly the abovementioned actors in order to obtain a realistic feedback in light of the prototype achievements, at this point in time.