NAB 2015 MOS Meeting Presentation

MOS Group
NAB 2015 Conference
14 April, 2015
Westgate Las Vegas Resort, Conference Rooms 7-­‐8
Las Vegas, NV
Welcome
For all local attendees, please ensure that you sign in with your name, affiliation and e-­‐mail address.
For remote participants: Please introduce yourselves and your organization. We are planning to use bi-­‐directional audio links in the WebEx session. Please keep your phones on mute when not speaking.
If we experience severe technical issues with audio, we may need to restrict all Q & A to within the chat room for remote participants.
NAB 2015 Proposal Voting
• One designated individual per organization will represent their company for voting. • Remote attendees/organizations may vote, but must identify themselves, their organization, and their named representative for voting.
• Proposals will need a simple majority vote from those in attendance (local and remote attendees) to pass.
NAB 2015 Agenda
• IBC 2014 Review
• HTML5 Supplement to ActiveX
– Shawn Snider, Ross Video
• Generic CG Item (Graphics Builder Object)
– Jim Martinolich, ChyronHego
• Any other business ?
IBC 2014 Review
• Standard vocabulary for objPath/objProxyPath Tech Descriptions (Seen as overly complex at this time)
• Codifying that paths need to be direct paths to the object not involve client-­‐side redirection (Will reflect in next version documentation)
• Codifying that objPaths and objProxyPaths end in file type extension (Will reflect in next version documentation)
IBC 2014 Review
• Proposed a new MOS standard for pushing content into graphics
• Sub/child running orders (need a sub group formed)
• HTML5 supplement to ActiveX NAB 2015 Business
HTML5 Supplement
• HTML5 Proposal update from Shawn Snider
• Group Discussion
• Call for a vote to accept
Graphics Builder Object
• Graphics Builder Object update from Jim Martinolich
Graphics Builder Object -­‐ Objectives
• A proposal for a more modern method to create graphics objects. An open update to the CII serial Protocol.
• The goal is for any system to be able to create a ‘Graphics Builder Object’ and insert it into a story or rundown and be sent to a graphics device. • The generic MOS Object may be converted to a real MOS Object by the graphics device.
• The MOS Objects may be based on standard graphics templates. Graphics Builder Object -­‐ Proposed Format
<mosID> Fully Qualified MOS ID ( e.g cg.generic.mos)
<ncsID>
<objID>
•
•
A unique ID generated by the author system and assigned to this object. It may be replaced later in the production chain after redirection. <objSlug>
•
An object description defined by the author system
<mosAbstract>
•
Abstract of the Object intended for display by the NCS defined by author system.
<objPaths>
•
•
The content author system may want to provide an object proxy, such as thumbnail
These proxies may be replaced by graphics system after redirection.
<itemChannel>
Channel assignment may be assigned when the item is created, or left blank and assigned later.
Graphics Builder Object -­‐ Proposed Format <mosExternalMetadata> •
•
This MEM Block c arries the i nformation needed to c reate the desired graphic. It defines the base template and the text and media assets which will populate i t. <template>
•
GBOs c an be based on using standard template styles familiar to news production.
<templateID>
•
•
•
Template ID i s an agreed upon, dictionary – defined name for the base template. A basic set of templates will be defined by the MOS Group. Beyond that, a TemplateID may be designated, defined and implemented by any graphics system vendor or graphics c ontent originator.
<elements>
•
•
Each template has several replaceable text and media elements.
The number and name of these elements are defined i n the TemplateID specification. •
A text field will be populated with the text defined in this node and/or a pointer to a data value. If a pointer i s used, i t should be a complete and fully -­‐accessible HTTP path that requires no additional credentials. The pointer should be wrapped i nside of a <reference></reference> tag set. <text>
•
<image>
•
<video> •
A complete and fully-­‐accessible HTTP path, that requires no additional c redentials, to a still image file to be used i n a graphic. A complete and fully-­‐accessible HTTP path, that requires no additional c redentials, to a video file to be used i n a graphic. Graphics Builder Object -­‐ Proposed Format Sample Template Definition
TemplateID = LowerThird1
<template>
<templateID>LowerThird1</templateID>
<elements>
<text>
<text1>Breaking News</text1>
<text2>Ron Burgundy</text2>
<text3>Today’s high temperature
<reference>http://wx-­‐sys.com/today/hitemp.txt</reference>
</text3>
</text>
<image>
<logo>http://wknwm.com/media/chan4logo.tga</logo>
</image>
</elements>
</template>
Graphics Builder Object
Group Discussion
Graphics Builder Object -­‐ Proposed Format Comments from MOS Group members
From Stuart Clow at PixelPower
Would it not make sense to include this information within a new Payload type? Say <mosPayloadGenericGraphic>
In this way, a graphics vendors ActiveX could (when configured appropriately) create both the <mosPayload> containing the proprietary information and a <mosPayloadGenericGraphic> which contains your proposed format.
When a rundown was then redirected away from the originating graphics MOS id then the target MOS would see that the graphics object contained a mosSchema
which it was not capable of interpreting. It would however see that a <mosPayloadGenericGraphic> existed and would therefore be able to create mosPayload for the target graphics device using the <mosPayloadGenericGraphic>. The MOS object would then be updated with this new mosPayload.
Graphics Builder Object -­‐ Proposed Format Comments from MOS Group members
From Rolf Rasmussen at Vizrt
Interoperability concerns
Transfer of machine readable TemplateID specifications
Evolvability and extensibility of GBO format
Baseline image and video support
Uses where the proposal is insufficient
Encryption of inflight media transfers
Areas that need clarification
Name scopes and reserved names
Graphics Builder Object -­‐ Proposed Format Comments from MOS Group members – Mark Gilbert/Gallery
•
I agree with Rolf that we need an easily and cleanly extensible mechanism. The initial proposal looks really nice and simple -­‐ and this will be *critical* to getting widespread adoption (too complicated = no adopters).
•
Mechanism for targeting the CGs. In our work this month we quickly realised there was the opportunity to have a CG be 'targetted' to one 'show' template or another. In our example we did this by taking a parameter from the MOS Rundown (eg Program Name) and using that as a substitution for the path to the CG. In this example there were 2 directory structures on the CG, one for each show, and thus moving a story from a rundown for 6pm news, to a rundown for breakfast news automatically gave the CG a different look. I don't claim to know how other systems currently offer this, but it seems like this 'topic' would be appropriate to consider for these generic objects. By definition, we want the objects to be generic, but we also want a method to 'target' them to a show in a way which an end CG could process.
•
So -­‐ any suggestions ? Where in this chain does the decision about the target show come ? Where is it defined ? do we need to have something about this inside the object ?
Graphics Builder Object -­‐ Proposed Format Comments from MOS Group member Mark Gilbert/Gallery
•
Finally, on the topic of a universal authoring GUI -­‐ I wanted to touch on a standardised
mechanism for 'previewing' CGs when creating them. This is clearly not an easy one, but its a fundamental part of the CG authoring process. For want of a better suggestion, I would like to pitch the concept of an HTML 'proxy' for a CG. The idea is that the system which 'creates' a template can publish a simple HTML page which contains tags/ fields and images / video such that a 3rd party 'tool' for assembling these generic CG objects can present the user with a kind of WYSIWYG experience. So maybe we could expand the spec to allow CGs to publish their offerings in a standardised HTML mechanism which could drive the user experience when creating these generic objects.
•
The end result would be a universal interface in an NCS (or other type of system, automation for example) where a user can get a generic list of templates (provided by a query to the known CGs) and for each one, the template defines the fields and an HTML representation -­‐
which again can be rendered by a universal tool to give 'some idea' of how the page would look. Worst case the HTML page would be blank with fields in specific positions with a generic font. For sure this could be generated by any CG with very little effort. Best case, the HTML page would be a rich representation of the graphic, perhaps even with animation, accurate font rendering etc
Graphics Builder Object
Next Steps ?
Any other Business
• Any new items for discussion?
Thank you all for participating with the MOS steering group during NAB 2015
We hope to see you all again at IBC 2015 in Amsterdam
Copies of the NAB presentation will be posted to the mosprotocol.com website