|
1
|
- Using New Technology to Implement DTV Master Control Designs
|
|
2
|
- Craig Beardsley, Technical Manager
- Sony Broadcast Systems Solutions Company
Park Ridge, NJ
|
|
3
|
- Should provide more flexibility than current MCR designs
- Should leverage new AV/IT Technology integration
- Should enable future expansion and growth to adapt to new and emerging
broadcast content
|
|
4
|
|
|
5
|
- “Central Casting”
- One Location feeding a number of TV operations with different signals
- Less Local program content
- More Targeted Funding Credits / Commercial announcements
|
|
6
|
- Improved Cost/Benefit of multi-ported server architectures
- Lower Cost of HD and high quality SD acquisition
- Lower Cost of building a completely component digital plant
- Move to Open Standards by manufacturers
|
|
7
|
- AV / IT Technologies
- Asset Management Systems and Structures
- Bridge Products
(tying legacy and new technologies)
- MXF File Transfer
(First presented here in 2000)
- IP Streaming
|
|
8
|
- An Interchangable file format
- It is a Wrapper for Multi-media containers
- An extensible file format
- A compression agnostic file format
- A versatile file format
- A metadata aware file format
- A Streamable file format
- NOT an authoring format
- MXF allows editable packages with simple cuts
- Everything else is AAF
|
|
9
|
|
|
10
|
|
|
11
|
- Different MXF body types can be KLV wrapped
- Body types can be single essence or multiplexed
- Body type is signalled in the first few bytes
- Enables early success / failure when streaming
- Allow rapid identification of body types
- Metadata can be parsed even if essence type cannot be decoded
- Store & Forward devices can report compression type
|
|
12
|
|
|
13
|
- Conceptual System Block Diagram of "e-VTR"
- Merge Current VTR Technology and Network Technology
|
|
14
|
- MXF allows File Transfer of Rich Media Files via standard IT networks
- MXF can provide streaming mode service, on a network than can support
it.
- MXF is compression agnostic
- Allows for specific content to be parsed (i.e. pull out just the audio)
- Editor interface with AAF files
- Gateways such as the e-VTR will provide interconnectivity to existing
libraries
|
|
15
|
- A Building Block Approach
|
|
16
|
- Acquisition
- Satellite (Analog, IP, MPEG, etc.)
- Fiber / Coax (ATM, IP, TV-1, etc.)
- Format normalization
- For materials needing some modification
- Storage (both Data and A/V)
- Local
- Remote
- Asset Management
|
|
17
|
- Playout
- Traffic
- Scheduling
- PSIP generation
- Formatting (SD, HD, NTSC, etc.)
- Multicasting Strategies
- Emission
- DTV, NTSC, Cable, DTH Satellite, Web, etc.
|
|
18
|
|
|
19
|
- With available technology, there are now many ways to assemble the
blocks
- Functions can appear as needed at any stage of the process, and many can
be done under automated control
- Additional functions can be “Patched in” as necessary
|
|
20
|
- Make sure you are building for your current needs
- Leave “hooks” for expansion over the next 5 – 7 years
- Don’t build yourself into a corner – allow for undetermined and/or new
operating parameters (Multicast, Central Cast, HD, etc.)
|
|
21
|
- How many streams do you need to feed/control simultaneously?
- Be sure to include ITV, Cable, and any other feeds that do not go to
the main transmitter
- What resolutions (formats) do you need to emit (transmit)? – Allow for
all necessary conversions
- How much rights management do you need?
- How much Automation is required?
- In what locations are services needed?
- Remote Funding Credit/Commercial drop-in, edge servers, hub and spoke
designs, etc.
- What kinds of connectivity are available and affordable?
- Type, Bandwidth, Availability, etc.
|
|
22
|
|
|
23
|
|
|
24
|
|
|
25
|
- MXF File Transfer over IP
- MPEG Transcoding
- High Quality IP Streaming
- Defined Asset Management Structures/Software
- Improved Automation Functionality
|
|
26
|
- New DTV MCR designs should
leverage traditional and new technologies
- Should provide new functionality as needed
- Should be modular and expandable
- Should leverage AV/IT integration, where it makes sense to do so
- Optimal design will be different for each case
|
|
27
|
- Designs must be tailored to specific needs and resources
- Designs must allow for expansion/adaptation
- Today’s optimal design will be out of date very soon
- Designs should consider AV/IT integration technolgy as a source of
effeciencies
- Designs must make sense – in dollars and operational functionality
|
|
28
|
- WWW.AAF.ORG
- WWW.PRO-MPEG.ORG
|