WO2004088553A2 - Procede et appareil permettant de commander dynamiquement un systeme de production de contenu multimedia diffuse - Google Patents

Procede et appareil permettant de commander dynamiquement un systeme de production de contenu multimedia diffuse Download PDF

Info

Publication number
WO2004088553A2
WO2004088553A2 PCT/GB2004/001505 GB2004001505W WO2004088553A2 WO 2004088553 A2 WO2004088553 A2 WO 2004088553A2 GB 2004001505 W GB2004001505 W GB 2004001505W WO 2004088553 A2 WO2004088553 A2 WO 2004088553A2
Authority
WO
WIPO (PCT)
Prior art keywords
resource
user
resources
group
workstation
Prior art date
Application number
PCT/GB2004/001505
Other languages
English (en)
Other versions
WO2004088553A3 (fr
Inventor
Garry Winterburn
Robin Bettridge
Stuart Murray
Brett Cherrington
David Brooks
Michael Koetter
Original Assignee
Bbc Technology Holdings Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bbc Technology Holdings Limited filed Critical Bbc Technology Holdings Limited
Publication of WO2004088553A2 publication Critical patent/WO2004088553A2/fr
Publication of WO2004088553A3 publication Critical patent/WO2004088553A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/34—Indicating arrangements 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42—Arrangements for resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/06—Arrangements for scheduling broadcast services or broadcast-related services

Definitions

  • the present application is related to the field of media editing systems and particularly, but not exclusively, to the management of resources within media editing systems.
  • the systems and methods may be particularly useful in systems with time-critical outputs, for example where the end product of the editing system must be available at a particular time and in a particular format.
  • Media editing systems may be made up of a plurality of elements or resources that perform different editing tasks within the system.
  • the allocation of resources could be controlled using a manual system, but such a system is expensive and time consuming for a user or system administrator to operate and a system administrator may be required to mediate between a number of users who want to use a resource at the same time.
  • manual booking systems may require a user to determine which resources are required to perform a particular task and at what time and to book each resource individually. If a user books a resource for the wrong time, then the resource may not be available when the media item requires that resource for editing.
  • a user may have to oversee the editing process by manually routing the output of one resource to the input of a further resource during the editing process.
  • no system may be provided for booking resources, but surplus resources may be supplied in the system to ensure that vital editing processes can be performed at the required times. However, this may be wasteful as a large proportion of the resources will not be used for the majority of the time.
  • VCRs virtual resources
  • a further problem associated with prior art systems is that users, or groups of users, can monopolise the use of resources. For example, a group of users working on a particularly resource-intensive project may use a large number of resources and may unintentionally prevent other users from using the resources.
  • a further problem with prior art systems is that a user may not necessarily know whether an editing resource is actually available until the user attempts to use the resource. It may not be possible to pre-book the resource and even a booked resource may have become unavailable by the time the user comes to use it.
  • a method of controlling access to resources in a media editing system by at least one user using at least one workstation comprising a plurality of resources, each resource having an associated resource group, a plurality of users, each user having an associated user group and a plurality of workstations, each workstation having at least one associated workstation group, the method comprising: allocating attributes to the resource groups, the user groups and the workstation groups; receiving a request for permission to access at least one resource from a user using a workstation; and determining access permission to the at least one resource for the user at the workstation based on the attributes allocated to the user group of the user, the resource group of the resource and the workstation group of the workstation.
  • Managing resources centrally may advantageously allow resources to be managed intelligently between users or groups of users without requiring a complex manual booking system.
  • Allocating users, resources and workstations to groups and allocating attributes to the groups may advantageously allow the resources to be managed flexibly between the users, for example according to rules defined within the system.
  • dividing the users into user groups may allow resources to be allocated or even dedicated to particular groups of users, for example depending on the role of the user (for example a "news journalist” may require different resources to a "photographer") and the seniority of the users (for example, the group of "assistant reporters” may be allocated fewer resources than the group of "senior editors”).
  • Enabling groups of users to access particular groups of resources may also advantageously allow resources to be spread more evenly between user groups and, as described in more detail below, this may be used to ensure that resources are available for use by particular groups either permanently, or at a particular time.
  • a further advantage of the present system may be that allocating attributes centrally for users, workstations and resources in the system may allow permissions to be changed easily and centrally.
  • the method further comprises determining the availability of the or each resource at the specified time and reserving the or each resource for the user or the user group if the permission is granted and the or each resource is available.
  • the method may further comprise: receiving a request from a user for the system to perform a task at a specified time; determining the one or more resources required to perform the task, including determining the time at which each resource is required; determining an access permission to the or each resource for that user at that workstation determining the availability of the or each resource at the required time; reserving the or each resource for the user if the user is permitted to access the or each resource and the or each resource is available.
  • the method may advantageously allow a user to submit a single request for the system to perform a task and the system may automatically determine which resources are required to perform the task, at what time and whether the resources are available for the user at that time. This may allow the correct resources to be booked without the user having to consider each resource individually.
  • a method of managing resources in a media data editing system having a plurality of resources comprising: receiving an input from a user requesting performance of a task by the system at a specified time; determining the resources required to perform the task and the time at which each resource is required; determining the availability of each resource at each determined time; reserving the resources for the user at each determined time.
  • the method before reserving the or each resource, the method further comprises determining an access permission for the user for the or each resource.
  • the user has an associated user group having user group attributes and each access permission is determined based on the user group attributes.
  • the workstation of the user preferably has an associated workstation group having workstation group attributes and wherein each access permission is determined based on the workstation group attributes.
  • the or each resource preferably has as associated resource group having resource group attributes and wherein each access permission is determined based on the resource group attributes.
  • the user group attributes comprise at least one of: a user group type; a maximum number of resources that the user group can reserve; a maximum number of resources that each user in the user group can reserve; a priority weighting attribute for the user group or for each user; a list of resource groups that the user group can access; a list of guaranteed resources that the user group can always access.
  • the workstation group attributes comprise at least one of: a workstation group location; a maximum number of resources that the workstation group can reserve; a priority weighting attribute for the workstation group; a list of resource groups that the workstation group can access; a list of resources that are directly connected to the workstation group.
  • the resource group attributes comprise at least one of: a resource type; the number of resources in the group; a maximum number of users that can access the resource group at the same time.
  • the access permissions are time-dependent. This may advantageously enable the system to recognise that access priorities for users may not be constant through time. For example, editors for a news programme at 18:00hrs are preferably assigned a higher priority to resources than editors for a news programme at 22:00hrs in the time immediately leading up to 18:00hrs. The editors for the 22:00hrs programme may then be assigned a higher priority to the resources after 18:00hrs.
  • a further advantage of the method of either the first or the second attribute may be that the system may be able to manage the resources centrally. For example, the system may be able to predict clashes in the planned usage of resources and warn users, or reallocate resources, before the usage time arrives.
  • the method further comprises, at each determined time, routing the output of one resource to the input of a further resource to perform the task.
  • the system may automatically connect resources and transfer the media data item being edited between resources.
  • the resources may be allocated on a first-come-first-served basis. Hence a resource that has already been allocated to a user may not be reallocated to a different user without, for example, the intervention of a systems administrator.
  • the method may further comprise assigning a priority weighting to each user or user group and allocating resources based on the priority weighting.
  • the priority weighting for a user varies over time.
  • the method may further comprise permitting a selected user or group of users to override resource reservations within the system.
  • the selected user or users may comprise, for example managers, senior editors or systems administrators.
  • the method further comprises generating a warning that the request cannot be fulfilled.
  • the warning may be transmitted to the user to inform the user that the attempted booking has failed.
  • the method further comprises communicating the warning to a systems administrator.
  • the method further comprises enabling the systems administrator to reserve the resource for a selected user.
  • the method further comprises diverting resources to an urgent task.
  • resources are diverted for a predetermined time period. More preferably, the predetermined time period can be extended.
  • the system dynamically reallocates resources to reservations displaced by an urgent task.
  • resources in the system are reserved for urgent tasks, preferably wherein ports of the system are reserved for record and playout of urgent tasks. This may ensure that ports are always available for playout of media, for example to playout servers.
  • the method may further comprise permitting a selected user or group of users to override resource reservations within the system.
  • the method may further comprise extending the reservation of a resource if a task has not been completed in the reserved time period.
  • users in a user group are prevented from reserving or accessing simultaneously more than a predetermined number of resources from a resource group. This may prevent a particular user or group of users from monopolising the system resources and preventing access by other users.
  • the or each resource comprises a resource selected from a group of resources. More preferably, the user requests the use of a particular type of resource to perform a task and the system allocates a specific resource from a group of resources to the task.
  • the method further comprises raising an event if a resource is not available.
  • the method further comprises receiving an input to the editing system at one of a plurality of input points.
  • the input points may comprise one of a number of different formats, for example, the input may be an external input from a news agency or may be an input from an archive or a VTR.
  • the method further comprises creating a resource reservation table for the resources in the system.
  • the resource reservation table is output for users to view.
  • the method may further comprise enabling selected users to alter reservations within the resource reservation table. For example, a systems administrator may add, delete or move reservations using the table as an interface.
  • the method may further comprise providing a control panel for the user based on the resources reserved.
  • the method may further comprise enabling the system to reserve resources automatically for performing predetermined tasks. This may enable the system to ensure that resources are always available for performing particular tasks, for example tasks that are performed at the same time each day or that are performed regularly.
  • the predetermined tasks are reserved for a predetermined user or group of users. If the tasks are reserved by the system, they may be reserved for a particular group of users. That group of users may then take control or ownership of the task at the time reserved.
  • a reservation may be made for a group of users and any user in the group may take control of the reservation. Reservations may be made in this way by one user from a group of users or by the system on behalf of the user group.
  • the resources may comprise at least one of: a VTR; an input port; a playout port.
  • a method of controlling access to resources in a media editing system comprising defining time-limited user access permissions for resources, receiving at least one request from a user to access at least one resource at a specified time and determining access permissions to the at least one resource for the user based on the time-limited user access permissions.
  • Providing time-limited user access permissions may enable the resources in the system to be allocated to different users or groups of users at different times, preferably at the times when they are most likely to be required. This may allow the system to use resources more efficiently.
  • the user has an associated user group and the time-limited user access permissions are determined based on the user group of the user.
  • the workstation of the user has an associated workstation group and the time-limited user access permissions are determined based on the workstation group of the user.
  • the or each resource has an associated resource group and the time-limited user access permissions are determined based on the resource group of the resource.
  • a method of allowing the use and control of resources in a media editing system comprising selectively providing a control panel for a resource reserved at a specified time by a user at a workstation of the user and enabling a user to control the resource remotely via the control panel at the specified time.
  • a method of editing media data comprising: inputting a request for performance of a task on the media data by a plurality of resources in a media editing system at a specified time; at the specified time, inputting a request for instigation of the task by the media editing system.
  • apparatus for controlling access to resources in a media editing system by at least one user using at least one workstation, the system comprising a plurality of resources, each resource having an associated resource group, a plurality of users, each user having an associated user group and a plurality of workstations, each workstation having at least one associated workstation group, the apparatus comprising: means for allocating attributes to the resource groups, the user groups and the workstation groups (for example, an attribute allocation system, such as a computer terminal or interface); means for receiving a request for permission to access at least one resource from a user using a workstation at a specified time (for example an input interface); and means for determining an access permission to the at least one resource for the user at the workstation based on the attributes allocated to the user group of the user, the resource group of the resource and the workstation group of the workstation (for example a processor and an associated memory).
  • attributes for example, an attribute allocation system, such as a computer terminal or interface
  • Apparatus for managing resources in a media data editing system having a plurality of resources comprising: means for receiving an input from a user (for example an input interface) requesting performance of a task by the system at a specified time; means for determining the resources required to perform the task and the time at which each resource is required (for example a processor and associated memory means); means for determining the availability of each resource at each determined time (for example a processor); means for reserving the resources for the user at each determined time (for example a booking system, which may comprise a processor and an associated memory means).
  • apparatus for controlling access to resources in a media editing system comprising means for defining time-limited user access permissions for resources (for example an input interface and an associated processor), means for receiving at least one request from a user to access at least one resource at a specified time (for example, an input interface) and means for determining access permissions to the at least one resource for the user based on the time-limited user access permissions (for example, a processor and an associated memory).
  • apparatus for allowing the use and control of resources in a media editing system comprising means for selectively providing a control panel for a resource reserved at a specified time by a user at a workstation of the user (for example a processor and an output interface for transmitting the control panel to the user) and means for enabling a user to control the resource remotely via the control panel at the specified time (for example, a computer terminal or interface associated with the user).
  • apparatus for editing media data comprising: means for inputting a request for performance of a task on the media data by a plurality of resources in a media editing system at a specified time (for example an input interface on a user terminal); means for inputting, at the specified time, a request for instigation of the task by the media editing system (for example an input interface).
  • a computer program or computer program product comprising steps for carrying out a method for controlling access to resources in a media editing system by at least one user using at least one workstation, the system comprising a plurality of resources, each resource having an associated resource group, a plurality of users, each user having an associated user group and a plurality of workstations, each workstation having at least one associated workstation group, the method comprising: allocating attributes to the resource groups, the user groups and the workstation groups; receiving a request for permission to access at least one resource from a user using a workstation at a specified time; and determining an access permission to the at least one resource for the user at the workstation based on the attributes allocated to the user group of the user, the resource group of the resource and the workstation group of the workstation.
  • a computer program or computer program product comprising steps for carrying out a method of managing resources in a media data editing system having a plurality of resources, the method comprising: receiving an input from a user requesting performance of a task by the system at a specified time; determining the resources required to perform the task and the time at which each resource is required; determining the availability of each resource at each determined time; reserving the resources for the user at each determined time.
  • a computer program or computer program product comprising steps for carrying out a method of controlling access to resources in a media editing system, the method comprising defining time-limited user access permissions for resources, receiving at least one request from a user to access at least one resource at a specified time and determining access permissions to the at least one resource for the user based on the time-limited user access permissions.
  • a computer program or computer program product comprising steps for carrying out a method of allowing the use and control of resources in a media editing system, the method comprising selectively providing a control panel for a resource reserved at a specified time by a user at a workstation of the user and enabling a user to control the resource remotely via the control panel at the specified time.
  • a computer program or computer program product comprising steps for carrying out a method of editing media data, the method comprising: inputting a request for performance of a task on the media data by a plurality of resources in a media editing system at a specified time; at the specified time, inputting a request for instigation of the task by the media editing system.
  • the invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
  • the invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
  • the methods and apparatus described herein may be implemented in conjunction with media input, editing and transmission systems, aspects of which are described in the applicant's co-pending patent applications.
  • aspects of a system for managing data for transmission are described in the applicant's co-pending patent application entitled “System and Method for Media Management”, Attorney Reference No. IK/26522WO, filed on 5 April 2004, the disclosure of which is hereby incorporated by reference in its entirety.
  • aspects of a system and method for media data storage and retrieval are described in the applicant's co-pending patent application entitled “Data Storage and Retrieval System and Method", Attorney Reference No. IK/26523WO, filed on 5 April 2004, the disclosure of which is hereby incorporated by reference in its entirety.
  • Fig. 1 is a schematic diagram of a media editing system in which the systems and methods described herein may operate
  • Fig. 2 is a schematic diagram of routing between ports on a Switching Matrix and an
  • Fig. 3 is a schematic diagram of a resource reservation table according to one embodiment
  • Fig. 4 is a schematic diagram of a simplified static class relationship for the objects required for resource allocation according to one embodiment
  • Fig. 5 is a schematic diagram of a playout and recording system according to one embodiment
  • Fig. 6 illustrates a grouping of resources in the system of Fig. 5 according to one embodiment
  • Fig. 7 is a schematic diagram of the system according to Fig. 5 with an additional VTR provided in the system;
  • Fig. 8a illustrates schematically the bookings shown in the interface 'of Fig. 8b;
  • Fig. 8b illustrates one embodiment of a 'bookings view' interface
  • Fig. 9 illustrates schematically a further booking scenario as shown on a 'bookings view' interface
  • Fig. 10a illustrates one embodiment of a system wherein resource permissions are dependent on the allocated position
  • Fig. 10b illustrates schematically the process of bookings using allocated positions
  • Fig. 11 illustrates one embodiment of a client-server system interface
  • Fig. 12 is a schematic diagram of a high-level generalised media management system according to one embodiment
  • Fig. 13 is a further schematic example of a media management system according to one embodiment
  • Fig. 14 is a schematic diagram of an example structure of a media item. Detailed Description
  • the methods and systems for allocation of resources described herein may be implemented in conjunction with a bookings process. There are also described below methods for users of the system to share resources and gain access to resources and methods and systems for managing location specific resources are further described. Also described below is one embodiment of the design of a Resource Allocation Service and details of algorithms that may be used to perform resource allocation are provided.
  • One embodiment of a resource allocation system may provide some or all of the following features: the system can warn users if the number of resources available for use at a certain time is insufficient to perform the number of bookings requested, the system may be designed to prevent certain groups of user from "hogging" system resources and the system may allow temporal allocation of resources within the system for specific purposes. The system may perform these functions by restricting access to resources according to predetermined rules, attempting to reserve resources and, therefore, prevent usage of the same resources at the same time in advance (clash detection) and by preventing usage of the same resources at the same time at the time of the booking (port locking).
  • the resource allocation system may further hold an internal model ofthe physical resources required for an editing system to perform its function of recording and playout of bookings.
  • the system may detail devices in the system and connections between them and may further set up the relevant routes across the system at the time of the bookings as described in more detail below.
  • Resources in one embodiment of the system may comprise any object that needs to be reserved for a booking. This may include, for example, a Router Port, a VTR Input/Output or a Media Server Port.
  • a ResourcePort is the unit of allocation of resources and each device can have any number of ResourcePorts. Each device and port may also have a number of attributes regarding its "physical" information.
  • a resource group comprises a collection of resources. Resource Groups are preferably normalized by the system, e.g. if a resource is added to a group that is connected to another, this second resource may also be added to the group automatically by the system. A resource group should contain both ends of a connection.
  • FIG. 1 One embodiment of a media editing system is illustrated schematically in Fig. 1.
  • media may be input into the News Media Core (NMC) via one or more of a plurality of routes and there are media entry points to the system shown in Fig. 1 at different positions.
  • NMC News Media Core
  • a user may wish to ingest from a Video Tape Recorder (VTR) 110 connected directly to a media store 112, a VTR 114 connected to the Edit Matrix 116 or a source routed from a Central Switching Facility or Switching Matrix 118.
  • VTR Video Tape Recorder
  • the Edit Matrix 116 may be used to switch media data between elements in the editing system.
  • the system may be designed to 'route' the media data in a variety of ways, for example, it may allow an input on the Switching Matrix 118, for example input News Package 1 (NP1), to be routed via a physical connection, such as a cable, e.g. a TieLine, into the Edit Matrix 116, for example via Physical Connection 4 (JOS4), to a port on an editing system, for example Editing Port 5 (JP5) and hence into the media store 112.
  • NP1 input News Package 1
  • NP5 input News Package 1
  • NP5 input News Package 1
  • JP5 Editing Port 5
  • the media data may be input via a Physical Connection, for example Physical Connection 3 (JOS3), directly into the Edit Matrix 116, and may be routed to an Editing System Port, for example Editing Port 2 (JP2) and hence into the media store 112.
  • a Physical Connection for example Physical Connection 3 (JOS3)
  • JP2 Editing Port 2
  • a third input method for the media data may be directly via an Editing System Port, for example Editing Port 1 (JP1) into the media store and such a routing action may be represented as:
  • the News Packages for example NP1 , actually contain a set of routing nodes, which generally map to video nodes and several audio nodes.
  • the system may not control the allocation of NP packages.
  • a range of output packages may be available on the Switching Matrix 118 and these may be denoted by JOSsource. So for example, the first news package JOS route described above may be written as:
  • JOS4 SMdest ⁇ V230,A105,A211 ⁇ to EMsource ⁇ V122,A76,A67 ⁇
  • This package uses the Switching Matrix destination (SMdest) resources V230 (port 230 on the Video matrix), and A105 and A211 (ports 105 and 211 on the audio matrix).
  • SMDest Switching Matrix destination
  • the Switching Matrix will generally be hard wired to the Edit Matrix, although this may not be the case when ports are being added or port maintenance is being undertaken.
  • the individual connection in JOSsource will be wired to the corresponding individual connections in JOSdest.
  • JOSdest corresponds to: EMsource ⁇ V122,A76,A67 ⁇
  • SMdest. V230 will be hard wired to an Edit Matrix source (EMsource) Video port - in this case EMsource.V122.
  • EMsource.V122 and SMdest.V230 identify the same physical wire i.e. each is an alias for the other. This is illustrated schematically in Fig. 2 which shows the connection 210 between the video ports V230 and V122 and the connections 212, 214 between the audio ports A105 & A76 and A211 & A67.
  • Edit Matrix Destination Port identifiers may be aliased to ports of an editing system.
  • this route may also be expressed as: NP1 , JOS4, JP5
  • a package may simply be a wrapper around (and a convenient label for) a set of resources.
  • a route can typically be described for a feed into the system.
  • media may be input from a VTR hard-wired into the Edit Matrix.
  • the VTR may be wired into an edit matrix source, and a Craft Editor server may be wired to an edit matrix destination. This can be viewed as:
  • elements within a route link element may vary depending on the nature of the link.
  • any point on the route may be considered to be a contentious resource i.e. when trying to set-up a route, if any one link is unavailable, the route will fail.
  • resources may be allocated against resource port packages that map onto the resources described above i.e. Switching Matrix resources, Edit Matrix resources and News Media Core resources.
  • this may be performed by managing a resource reservation table and such a table is illustrated schematically in Fig. 3 by way of example.
  • the resource reservation table may be managed using resource allocation routines, as described in more detail below.
  • two routes 310, 312 have been allocated against resources, at times t1 and t2, with durations n and m respectively.
  • the routes may be written as: NP ⁇ V.212 ⁇ , EM ⁇ V.116 ⁇ , JP ⁇ V.1035 ⁇ NPIV.212 ⁇ , EMIV.118 ⁇ , JP ⁇ V.1026 ⁇
  • both routes share a resource, namely NP ⁇ V.212 ⁇ . This is possible since they are temporally separated.
  • the present embodiment of the allocation routine will not allow overlapped allocations on a single resource. If an allocation request cannot be satisfied then the process requesting the allocation may raise an event that may be handled by a media port manager, which may be an automated system or may require manual intervention by a system supervisor. Alternatively, such a conflict of resources may be notified to a user or a system manager who may allocate the resources manually.
  • the resource allocation method may also be employed to compact the allocation table to free up resource at a particular time, for example for crash recordings, which are described in more detail below.
  • the system preferably includes a feature that allows it to re-allocate any allocations on that resource. Any allocations that cannot be re-allocated may be handled as an allocation error as discussed in more detail below.
  • the system illustrated in Fig. 13 comprises a metacore 1702, including a client side applications group 1704, a media service 1706 including a media store, an applications server 1708 and a metadata store 1710.
  • client applications are written in C++ and communicate using J2EE (Java 2 Platform Enterprise Edition) component level communications (JNI-RMI invocations), J2EE messaging and queuing, (JMS via Active JMS).
  • Server applications including system management applications could be written, for example in Java or C++.
  • Media storage, transfer and editing may be provided by a third party media system and associated protocol running'on an IP network, for example gigabit Ethernet.
  • the components of the metacore of the present embodiment all run off a media gigabit Ethernet.
  • the metacore may be linked to the transmissions domain 1712 by a transmission gateway 1714.
  • the transmission gateway will communicate with the Transmission domains using the appropriate Media Object Server (MOS) communication protocol.
  • MOS Media Object Server
  • Input feeds may be routed through a Switching Matrix 1714 to the Edit Matrix 1716, for ingest into the metacore.
  • the edit matrix features a filter comprising a dual redundant pair of PCs managing, filtering and auditing control requests from the system and transmission domains.
  • Both the Switching and Edit Matrix may be controlled by a central control system, for example Broadcast Network Control System (BNCS) Routers which may, in turn, be controlled by the metacore, for example using Fabian.
  • BNCS Broadcast Network Control System
  • a bookings and information service which may be implemented in conjunction with the present system, may replicate to the Metadata Core on a regular basis (typically ⁇ 1 min).
  • the Metadata Core may then update any application screens reliant on data that has changed.
  • the bookings and information service may comprise, in one embodiment, CBIS (Central Bookings and Information Service), which is a prior art organization and software application that manages and coordinates resources and bookings.
  • CBIS Central Bookings and Information Service
  • FIG. 12 is a schematic diagram of a system similar to that shown in Fig. 1 , but with additional media editing, output and editing functionality provided.
  • Features of the system shown in Fig. 12 may be provided in conjunction with features of the system of Fig. 1.
  • the various features shown will be described in more detail below, in relation to specific examples.
  • a metacore 1200 is at the centre of the system shown, and comprises a metadata store 1201 and a media store 1202.
  • Media intake for example from video feeds, agency wires, newsgathering teams, video footage etc. can be received via an edit matrix 1206 which is controlled by a network control system 1208.
  • the media may be assigned metadata values and description, which may be stored in the metadata store.
  • Media intake can also be received from viewing and editing services 1210 and Archive service
  • the metadata values may be imported with the incoming media, may be assigned values by a system operator or may be assigned default values.
  • the associated media is then stored in the media store 1202.
  • Users of the system can use viewing and editing services 1210 to view and edit media managed by the system, and can search the system by metadata attributes to find relevant media. Once the relevant metadata describing the desired media has been found, the system can retrieve the associated media from the media store (if it exists there) for use by the user. Users can create new media items from existing essence, but with new metadata (which may be derived from existing metadata as will be explained below) to be input into the metacore.
  • the media store is an online store, and media held within it can be accessed and manipulated directly via devices networked to the metacore.
  • the practical constraints of media storage dictate that only a certain volume of media can be maintained online in this way, and as new media is constantly fed into the system, existing media must be removed. This is particularly true of the media essence, and less so of the metadata. If it is determined that the media is important and cannot simply be deleted, it must be stored offline, or archived. Both the process of selecting material to be archived, and the process of archiving it requires substantial resources.
  • An archive service 1212 is therefore linked to the metacore.
  • the archive service is in turn linked to one or more VTRs 1214.
  • the archive service identifies media, via its metadata, to be taken from the media store and recorded to tape (offline).
  • the archive service can also act to re-ingest into the (online) media store tape based media.
  • the metacore is connected to transmission servers 1216. These transmission servers can accept media items, which are ready to be broadcast on transmission system 1218.
  • the system also supports web-based output, and the metacore, is further linked to a post processor 1220, which in turn feeds a web hosting 1222.
  • the routing of video, audio, and communication signals between various media systems and facilities, both internal and external, can be referred to in terms of 'Bookings' or 'Reservations'.
  • a Booking may simply specify a media feed from one location that is to be routed to another location, internal or external to the media management system. Bookings may also include recording of the media being routed. For example, a booking may be made to enable an on-air news presenter to interview someone live at a remote location. Bookings can also be communications-only bookings, enabling staff from various locations to communicate via a dedicated communication link.
  • Bookings may be of several types: Arrival bookings that are scheduled recordings, Departure bookings for media items that are to be played out from the system to another destination, and Archive bookings that represent requests for media to be moved to or from offline storage. Any tasks that require recording or playout of media can be tracked as a booking.
  • a user makes a booking, this results in a resource reservation or allocation.
  • the system finds at least one, and preferably all, available routes through the system that can be used to perform the booking.
  • the system may then select a route from available resources (for example the shortest route or the first available route) using the Allocated Position to restrict usage as required- Required information about the route may then be created and stored. These may include the resources that will be used and when the resources will be required.
  • the system may then create a Resource Reservation that will allow recording or playout to be performed at a later date.
  • the system may assign the resources exclusively to the booking for the times of the booking. This reduces the number of resources available to other bookings at the times of the booking.
  • the system may lock the resource ports involved "Port Locking".
  • a 'resource reservation' may occur each time a booking is updated.
  • a user may ensure the reservation is in place by checking a resource allocation status against the booking.
  • the system may fail to produce a resource reservation when the Allocated Position that is selected has run out of resources (at the time of the booking) or when there is no possible route for the booking. If the booking fails, the Resource Allocation Status may indicate the problem.
  • a resource reservation attempt is preferably made for every update of the booking.
  • a "Resource Allocation Status" (RAS) value may be assigned to indicate the success or failure of the allocation and each allocation can result in one of several statuses, as set out in more detail below.
  • the booking may not proceed until the resource allocation status has reached a successful state.
  • the resource allocation status will indicate the cause of any failure.
  • Resource allocation statuses that may be used by the system may include:
  • the allocation status for a booking may be obtained through a ResourceList workflow, for example by calling: ResourceAllocationStatus getResourceAllocationStatus (String bookinglD)
  • This may return a ResourceAllocationStatus object, which contains the status.
  • the status should be ALLOCATED or ALLOCATED ALSO TO FAIL.
  • a user can remove one of the required fields or change the booking decision code to not to be allocated and update the booking.
  • the user can manually remove it from the database or set the booking decision code NO or Y without resources and update the booking.
  • the system will spot that a required field has changed and remove the reservation for the booking and set RAS to NOT TO BE ALLOCATED.
  • Mbeans management beans'
  • Mbeans may comprise elements or objects of code which may control, implement or derive information from elements of the system.
  • the behaviour of the resource allocation service can be altered by setting the flags of its service MBean. Currently 9 flags are defined;
  • ResourceAllocEnabled - Enables or disables resource allocation completely. If this flag is set to false then all bookings submitted to the notify method will not be allocated. A Resource Allocation Status will still be created for this booking and the status value will be NOT_ALLOCATED.
  • ClashDetect - Enables or disables clash detection If clash detection is disabled then bookings can be made for the same resources at the same time. If this flag is enabled and bookings are attempted to be made for conflicting resources then the booking in question will be given a status of NOT_ENOUGH_RESOURCES. (Note: Resource Allocation will of course attempt to find an alternate set of resources from the allocated position before finally failing if there is not enough resources available).
  • an exception will only occur if no resource reservation can be found for a booking during an attempt to route the booking.
  • MaxResourceChecking Sets whether or not resource allocation should attempt to restrict the allocation of resources using the max-resources value for each dynamic allocation rule. If this flag is set then resource allocation will set a status of
  • ReAllocateResources Sets whether or not resource allocation should attempt to re-allocate resources following a configuration change or port/device disable. If this flag is not set and a change occurs affecting a booking then the reservation will be removed for that booking.
  • RouterExceptionTh rowing - Sets whether or not the resource allocation service is to throw exceptions for router call failures. If this flag is disabled then failure to setup a route on a router will only result in logging to the log file. This hides any router control errors from clients.
  • DeviceStatusListening Sets whether or not the resource allocation service is to listen for status changes on devices or not. If this flag is set to true the sen/ice will automatically enable and disable devices as they go up or down.
  • ReservationLocking Indicates that the resource allocation service should lock tables when performing allocation and reconfiguring resources setup.
  • LockRetries Indicates the number of attempts the service should try before giving up on trying to obtain a lock.
  • Retrylnterval Indicates the interval in milliseconds that the service should use between lock retry events.
  • lockResourcePort (String portld) Manually adds a resource lock to a resource port in the system
  • the system may maintain a record of which resources are allocated by means of an allocated position. Resource allocations within the system may each be allocated against an allocated position. This is the unit of work/resource share within the present embodiment of the system. Each allocated position may be implemented with a number of rules defining how it is able to reserve resources in the system. For example, this may define which resources or groups of resources are accessible by a particular group of users from a particular group of workstations at a given time. The rules are preferably of two types: dynamic and fixed. Each allocated position may have a number of dynamic allocation rules and a number of fixed rules.
  • the allocated positions will be related to/restricted by: Workstations/Workstation groups, Users/Roles (aka User groups)
  • the system will use the set information outlined above, to determine the allocated positions that the user has access to. Therefore, a user who is member of a given role or user group can only access certain allocated positions from certain locations (i.e. certain workstation groups). For instance a 'news editor' user may only be able to access an allocated position which gives access to his local VTR when he is sat at his desk next to it and logged in as a 'news editor' user.
  • Workstation attributes in the current location or workstation group The system will then return a modified set of allocated positions based on this information set. That is, the system will determine which resources or resource groups that user group has available from that workstation group at a particular time.
  • users can also apply to have more resources temporarily available to them by requesting them from the system manager. This may be done via an automated interface directly to the system or by means of a manual process, for example via a systems administrator, or using a combination of both.
  • a system manager may be able to assign new resources to the booking temporarily until the required action is completed, since some resources are preferably kept as free, unallocated resources within the system.
  • Those resources that are connected to a router may be considered as dynamic resources i.e. a set of resources that will be allocated to users in the most efficient manner.
  • the number of physical ports may be strictly limited, therefore it may be necessary to impose some form of sharing of between users such that, for example: a.
  • a user or group of users cannot 'hog' resources outside of their allocated position b.
  • An allocated position may be assigned guaranteed resources c.
  • An allocated position may share resources with other groups d.
  • An allocated position's access to resources may be temporally limited.
  • Using dynamic resources can allow the system to select resources from a set or group. These resource groups are preferably be set up to allow the rule to select resources dynamically but will also provide some element of control over which resources allocated positions have access to.
  • the dynamic resource allocation rules may vary over time, for example throughout a day.
  • Dynamic port rules may be provided with some or all of the following attributes: Maximum Number: limit on the number of resources this allocated position can
  • Weighting A relative weight used to resolve contention.
  • Guaranteed Nbr Resources The number of resources set aside for this position (This can be provided by fixed resource allocation as discussed below).
  • sumGR The sum of guaranteed resources across all Allocated Positions (sumGR) must be less than or equal fo the minimum of the total number of resources at any switching point.
  • the number of resources left for dynamic allocation purposes is given by (nbr resources - sumGR).
  • the number of guaranteed resources in the system should be significantly lower than the smallest resource allocation at any switch point, to allow the dynamic allocation algorithm to work (the number of guaranteed resources may vary depending on the overall surplus of resources for the work anticipated to be done).
  • the system As the system exhausts its resources, users will be in contention for the last resources. For example, if two users are vying for a port resource, the system must have a mechanism for deciding between usages. In one embodiment, the arbitration may be performed manually by a systems administrator but the system may use a weighting figure to arbitrate between users automatically, as described in more detail below.
  • some ports on the Clip Boxes or the media store may be fixed i.e. they will be permanently connected to other equipment. Hence, they may be considered as an end node, not requiring routing.
  • fixed ports must still be allocated i.e. multiple users may wish to use a fixed port.
  • Fixed resource allocations may have a similar set of attributes to the dynamic allocations but may be arranged to provide direct access to resources rather than via resource groups.
  • time limits With the additional feature of including time limits with the allocation rules, it is possible to add further control to the allocation of resources.
  • runtime checks may be made on allocation requests and users may be prevented from using resources outside of their timeframe. For example, user group N24 might be assigned specific resources from 12:00 through 14:00 and another user group may be assigned the same resources but between 14:00 and 15:00.
  • RG RG2, RG4 // Resource groups this rule can pick from DefaultRule
  • allocation failures may be handled in one of a number of ways. There is described below a method for handling resource allocation failures automatically, but manual systems may also be provided. For example, an allocation failure notice may be generated and sent to a systems administrator who may review the allocation failure and may manually allocate resources to the operation.
  • a resource has been "reserved" by an allocated position using a lower priority at that time, it will be cancelled and the resource will be reassigned (or "reserved") to the new booking.
  • the user who placed the booking, the media port administrators and, optionally, users who currently assume the allocated position of the cancelled booking will be informed of the resource re-allocation.
  • the booking preferably still exists within the system but will no longer have any resources allocated to it.
  • a resource that is "reserved" with a lower priority does not exist at that time, then the booking request will be denied due to lack of resources. The requestor will be informed of the booking failure.
  • the user may contact a mediaport administrator to request more resources, who may use a manual over-ride function to allocate resources. The mediaport administrator then has two options: o Refuse the request
  • bookings that are already in progress regardless of allocation weighting factor, take priority over bookings requesting to use the same resources. In other words if a booking has begun record/playout the system will not be able to automatically reassign the resources to any other booking (Other than by manual intervention by a system manager).
  • a further feature of the present embodiment is "crash recording” or “crash playout”.
  • a crash recording or playout is essentially a booking with an immediate allocation for time 'now'.
  • the user will indicate a 'rough' duration for the booking i.e. 10 mins, 1 hour, 10 hours. This could default to 1 hour or the minima of slots available on the resource groups.
  • the allocation of resources to this "crash" booking will follow the same algorithm as described above. Again, this will allow the system to predict a contention on any resources the booking uses before the contention occurs.
  • Crash record/playouts that require longer than the time available on the resource group will also be handled as above. Note that it may be possible to start recording with a two hour slot on a resource group which has a limit of 1 hour and then get the "Manager" (a user with suitable privileges) to clear the appropriate resources so that the crash record/playout can be extended.
  • bookings may be used to estimate the resource usage prior to the actual booking event taking place.
  • the system should be able to warn users or a systems administrator if the number of resources available at a certain time is not sufficient.
  • bookings are created they may either be internal bookings created by users of the system, or external bookings created, for example by an automated extraction process from a central bookings and information service.
  • the user can update the booking details, for example the requested start time of the booking or the input format of the media data. Updates may also come from the system itself, for example the central bookings and information service, which can change many fields of the booking. For instance, the source/destination details may change resulting in a requirement to use different resources.
  • the central bookings and information service may also affect the timing of the booking and will therefore have an effect on resource allocation.
  • the system maintains resource allocation based on booking information in the system. Every time the booking information is updated the system recalculates resource allocation for the period of time for that booking.
  • the system requires that the source, destination and allocated position be defined for new internal bookings. This may allow the routing information and resource reservation to be calculated immediately. Alternatively, and for external or system bookings, the routing information can be assigned at any point before the booking is due to take place depending on when the source and destination(s) are set.
  • the relevant resource groups may be "reserved" according to the bookings allocated position dynamic resource rules.
  • external bookings from the system may create an unallocated booking i.e. Booking decision code "Undecided”.
  • a media port manager (user with correct privileges) may then make a decision on whether or not the external booking is to be handled by the NMC i.e. change the booking decision code to "ToBeRecorded”.
  • the manager may also assign the booking to an Allocated Position or to the system.
  • the system may attempt to "reserve" resources for the booking using the given Allocated Positions' resource allocation rules.
  • the central bookings and information service may update the booking with the news package name at some point later and the system will then request to "reserve” the resources at this time. That is, the resources will preferably only be reserved when the booking is to be recorded by the NMC and the source and destination (s) are known.
  • the booking may require manual intervention (e.g. VTR operation required, or quality check or some other reason).
  • the booking may also include a freeform text field to allow the Manager to annotate the booking. In one embodiment, this may be referred to as the booking note field and each booking may require a booking owner.
  • a graphical user interface is preferably supplied to each user to allow users to view and control bookings.
  • the GUI may enable users handling bookings fo access the booking from a list by allocated position. This may be the result of a booking search performed by the user or automatically by the system. Users may also typically filter by this list further by a text filter. Users will then 'pick' items from the result list and expedite the booking, for example by taking ownership of the booking and running the operation of the booking.
  • the list will preferably be shown in timed order, most urgent first, although alternative views of the booking list may be generated.
  • the booking status is preferably updated and tagged with the user(s) currently handling the item. This field may be called the BookingOwner.
  • the system preferably does not stop more than one user from 'getting' (taking ownership of) the booking i.e. more than one user might grab the item and handle jointly. To this end, updates to booking status may be propagated back to clients.
  • the resources associated with the Booking will continue to be associated with the original allocated position's resource pool. That is, if the user changes the allocated position of a booking after resources have been allocated then the resource allocation remains unchanged. If a user subsequently changes another field in the booking that effects the resource allocation, the system may be designed either to re-allocate resources from the current allocated position or the previous allocated position.
  • AP Resource Owner the original AP. Resources remain associated with this AP, however ownership of the booking is subsequently transferred. Preferably, this AP may claim back the booking from the current owner at any time i.e. return the allocation back to its default setting.
  • AP Booking Owner the new booking owner. This user may be able perform the booking without changing allocated position and their AP's resource pool is not utilised for the booking. If they transfer the booking onwards to another AP it will simply alter the APBookingOwner field.
  • This differentiation allows bookings to be transferred whilst ensuring that resources remain available for that booking once allocated.
  • the system may re-allocate the resources when the booking is transferred to use the resources of the new allocated position's resource pool.
  • this could result in resources not being available given the allocation rules of the new AP.
  • Users may also be able to disassociate the allocated resources from a booking. This will return the allocated resources to the pool.
  • System Bookings may be assigned resources from a System Allocated Position.
  • This AP will contain the same rules as a standard AP and will function in much the same way.
  • the users may use the above system to edit and manage media data, which may be known as Media Items or Media Item Objects, which will now be described in more detail.
  • FIG 14 illustrates an exemplary structure for a media item which might be handled in a media management system in accordance with an embodiment of the present invention.
  • the media item 1100 is represented along a time axis extending horizontally across the page.
  • the media item comprises three separate media objects or tracks, 1102, 1104 and 1106.
  • track 1102 is video
  • tracks 1104 and 1106 are audio.
  • the tracks can be referred to as media essence.
  • Each media object or track can be divided in time into segments or portions. It should be noted that segments may have boundaries aligned across all tracks, such as segment 1108, however a single segment in one track may span two or more segments in another track, such as segments 1110 and 1112.
  • Media items additionally comprise metadata, which describe attributes associated with a media item, and which is used to assist in processing of the media essence within the system eg. storing, tracking, editing, archiving etc. These attributes may apply to the whole media item eg. item duration, or may be specific to segments within the media item eg. copyright holder (this will be discussed in greater detail below) A media item can therefore be said to be made up of media essence (tracks), and associated metadata (attributes).
  • Table 1 describes a number of metadata attributes which can be associated with a media item:
  • Fig. 4 shows a simplified static class relationship diagram for the objects required for resource allocation according to one embodiment.
  • the objects shown in grey, whilst important to resource allocation, are shown only for reference and are described herein.
  • the AllocatedPosition (AP) 410 object maintains the allocated position details.
  • a user can select the AllocatedPosition 410 as his/her current allocated position.
  • the actual selection of which allocated position(s) can be selected is restricted by the users current role/group and the workstation that he/she is current situated at. Therefore, if a user sits at a certain desk they may not see the same list of AllocatedPositions that they can see at another desk/workstation.
  • the AllocatedPosition may be the current one for any number of users but the user may only be in one allocated position at any one time. The user can move from one AP to another at any time. If the user attempts to perform a booking that has been allocated to an AP then this will become his/her current AP.
  • Selecting a particular AP preferably does not prevent users from looking at/searching for bookings in other allocated positions but may allow them to easily select the current bookings for their current AP.
  • An EndDevice object 412 may be used to describe all devices that can be used for resource allocation within the system. Each EndDevice object 412 will have a corresponding definition for the actual device properties that may be maintained via a NodeManager. The NodeManager has the ability to return the actual device details from an EndDevice object 412. However, most resource allocation tasks will only require the use of the EndDevice 412. Each EndDevice 412 maintains a list of the ResourcePorts that are contained within if.
  • a ResourcePort 414 refers to a physical port or set of ports (or a package of ports) on an EndDevice 412. There are many types of ResourcePort 414 in the present editing system. For simplification purposes in resource allocation the actual port information may be maintained separately. For instance a ResourcePort 414 may physically consist of a video port and two audio ports but for resource allocation purposes this may be treated as one ResourcePort 414. ResourcePorts 414 preferably include a disabled flag function so that they may be individually disabled for maintenance purposes.
  • the ResourceGroup object 416 is a logical collection of ResourcePorts 414.
  • a ResourceGroup 416 is a set of ports that allows (preferably via a DynamicResourceAllocationRule) the allocated positions to select which ResourcePorts 414 to use for a given booking.
  • the DynamicResourceAllocationRule 418 of the present embodiment holds all the dynamic resource allocation information including the weight at which resources can be allocated using it.
  • Each allocated position 410 will have a number of dynamic allocation rules that will provide them with access to certain resource groups at certain times of the day. Therefore, each rule contains a reference to a resource group 416 and the number of allocations that can be made within it. The rule also defines the maximum number of resources that can be reserved from the resource group the rule can allocate from.
  • the FixedResourceAllocationRule object 420 maintains a list of ResourcePorts 414 that the allocated position 410 can attempt to reserve. These rules may be used to allow an allocated position to have more guaranteed access to specific ResourcePorts 414. Again the rule preferably contains temporal information and a weight at which the ResourcePorts 414 can be reserved.
  • a system administrator can provide guaranteed access to certain ports in the system. For example the system administrator could create a fixed allocation rule that is the only object in the system that has the ability to reserve a certain set of ResourcePorts thereby preventing any other allocated position gaining access to them. (Of course the administrator could then create other similar rules for other APs with a higher weighting factor that could potentially obtain the resources.) In one embodiment, these rules could be replaced by dynamic rules that use ResourceGroups that contain only the
  • the resource reservation 422 will preferably be updated with the actual start date time.
  • the RouteDeviceLookup object 424 will maintain all possible routes through devices within the editing system.
  • the table will return a list of devices in order that must be passed through for a given source and destination e.g. getRoute("Switching Matrix", "Media Server 1") may return Switching Matrix->Edit Matrix, Edit Matrix->Media Server 1.
  • This list can then be used to allocate actual ResourcePorts 414 along the route for allocation.
  • the system will initially derive this table from the devices and connected ports within the system. However, it may also have to be modifiable by hand. This table may avoid routes through the system having to be calculated by hand each time a resource allocation is performed. The system may also use this list to perform the actual routing in the router devices as required.
  • the main type of resource allocation within the system may be resource allocation from a booking. This may allow the system to estimate resource usage in advance (given that the user may be able to change the booking length at any time even while it is being performed). This calculation may be performed to warn users of any potential shortfall in resources, distribute resources to media servers evenly and prevent certain groups of users hogging resources. All resource allocation is performed on a temporal basis so that users may have access to the same resources but at different times in the day.
  • the entry points to these algorithms are from the creation of a new booking and also updates to any booking. However only certain booking field updates will trigger the calculation.
  • the fields monitored for update changes may include: • PlannedStartDateTime PlannedEndDateTime DestinationName or DestinationlD SourceName or SourcelD IsDeleted • AllocatedPositionld
  • booking details calculate projected used disk space details for each of the media servers that can be routed to.
  • the system may be required to access details of all future bookings before the end current one which are being recorded to a given media server e.g. Booking[] getAllocatedBookingsByMediaServer(String mediaServerld, Date endDateTime) this may come from resource reservation details.
  • This calculation may result in the optimum media server for the booking.
  • the calculation may also produce a warning that by performing the booking the media server will become full, therefore, the media management service must redistribute media across the servers.
  • the system may be configured so that multiple routes do not exist within the lookup table so that this situation does not occur. 7. Attempt to reserve route by first picking an available port from the media server selected in step 5. Then by traversing the route list obtained in step 6 from the media server to the source attempt to obtain free ports/connections (within the same resource group) and add them to the resource reservation.
  • the system may be allowed to reserve ports from more than one resource group for a single booking. To perform this step, the system may obtain lists of free connections to/from all devices to/from other devices in a given resource group between a given date time range e.g. ResourcePortf] getAvailablePorts(ResourceGroup resourceGroup,
  • the system may obtain the number of bookings that an allocated position is performing at a given time e.g. getBookingsByAllocatedPosition(String positionld, Date startDateTime, Date endDateTime). In some embodiments, this may mean that the allocated position must have enough free resources for the whole duration of the booking.
  • RoufeDeviceLookup object This will return a list of devices in order that the route passes through e.g. media serverl ->edit matrix, edit matrix->vtr1. May also return more than one route, if so the shortest may be used first,
  • Route calculation moves along the route list obtai ni ed in step 3 attempting to reserve resources until the whole route is reserved. 5. If the system cannot find free resources for the whole route the system may check the existing resource reservations for resources that are on the route and have been allocated by an allocated position with a lower weighting. If allocated resources with a lower weighting are found the system may allocate the resources to this booking and send a notification informing other users of the change. 6. Inform media server service of intended playout passing list of media server clip ids that have been set-up in booking playlist. Media server service may then choose to begin cloning of clips to playout server.
  • the record/playout of booking may actually be performed at any time prior to the booking and may also finish before or after the planned end date and time. Therefore although the resource allocation will give an indication of which resources will be used for a booking the actual resources used may differ. Resource allocation allows the system to attempt to inform users of the system that resources may not be available for a given booking.
  • the system informs the Resource Allocation Service (via RPT) which retrieves the resource reservation details. This will return a list of ResourcePorts that have been reserved for the booking. This list is then used to find all routing devices on the list. Once the routing device(s) have been identified the service will obtain the control interface for the routing device from the NodeManager. This can then be used to set-up the relevant routing. If resource reservations do not exist for the booking (for example, if the booking is a crash recording) the system may use the algorithms described above to attempt to reserve resources immediately for the booking.
  • This booking set-up procedure takes a finite period of time therefore there may be a pause before the booking.
  • the pause is likely fo be shorter if resources have been allocated prior to the booking being performed and, if a booking is time-critical, the booking set-up procedure may be started before the scheduled time for the booking. If resources have not been allocated prior to the booking being performed the length of the pause may vary depending on the complexity of the system and the nature of the booking.
  • a booking may be started before the planned start date and, in this case, the system first checks the availability of the resources that have been allocated to the booking. If the resources are available then the recording/playout can commence without any changes. The system will mark the resources as being currently allocated. If the resources are not available then the system may attempt to reallocate the booking to other resources using the above algorithm, changing the planned start date time of the booking to the current time. If this fails then the system may raise a resource allocation exception and the user will be informed that their booking cannot begin until resources can be allocated for it. Alternatively, the system manager can choose to allocate more resources to the booking manually.
  • An extension period may be defined by the user or may be determined automatically by the system.
  • the system checks the booking's current resources for allocations within the extension period. If the resources are unallocated for the given extension period the booking may be extended and the current resource allocations are updated to reflect the changes. If the resources are allocated, the system may inform the user that the booking cannot be extended. As an additional feature, the system may check the resource allocation weight that is assigned to the conflicting reservation. If the resources were allocated with a lower weight the system may un-allocate the resources from the conflicting booking and allocate the resources to the current booking.
  • a notification may be sent regarding the booking that has been un-allocated and it will no longer have resources associated with it and the system attempt to re-allocate resources for the booking that has just been unallocated. If the resources were allocated with a higher weight than the current booking the system may inform the user that the booking cannot be extended and must end at the planned end date time.
  • the system is preferably designed to provide continuous 24x7 operation. Therefore resource allocation must be able to cope with scheduled and unscheduled disabling of resources within it. For instance a media server device may be shut down for maintenance or even fail. Therefore, removing a number of media server ports from the system. To this end the resource allocation service should be able to monitor the status of (or be informed of the status of) all devices and resource ports within the system so that the appropriate resource re-allocation can be performed.
  • the system manager may also be able to remove devices and ports from the system for given periods of time. If the system is informed of this downtime in advance then the resource allocation routines will be able to take account of this and not allocate resources on those devices. Therefore the system preferably provides a mechanism for system managers to allocate resources to downtime. This may be achieved in the system by creating a resource reservation to the resources for the required period with the maximum weight possible. Once created the system manager may also then be able to extend the reservation in a similar way to the booking extension process.
  • the resource allocation service may be notified of device/port failures via a NodeManager.
  • the NodeManager publishes messages to certain topics providing the status of all system devices. The resource allocation service will be subscribed to all these topics and will become activate when a failure has occurred.
  • the system may perform the following steps in the event of port failure:
  • step 3 For the list of bookings obtained in step 1 attempt to reallocate the resources for them. This procedure may follow the algorithm defined above and could therefore result in a number of bookings allocated resources at a lower weight becoming un-allocated. If resources cannot be found then the system will mark the bookings as un-allocated. Unallocated bookings due to this failure may be stored so that the system can attempt to re-allocate when the device is restored.
  • Device failures may be handled in a similar way as above for each port on the device.
  • reserved ports may be provided in the system for use as failover ports.
  • resource allocation will be managed by the system. However, it will of course be necessary for certain system managers to manually allocate resources as well as maintaining the current set up of resources within a system e.g. Add/Remove/Update/Set-up of end device and resource port information.
  • the system managers should be able to define the actual physical details of the devices and ports that comprise the system and systems and methods for manual set-up and resource allocation will now be described in more detail.
  • the system manager may be able to manually assign and remove resource ports for bookings (this may allow the manager to allocate a route through the system for a booking).
  • a System Resources Set-up service may provide the system manager with the ability to create/update and remove all resource objects within the system.
  • User screens may be provided to allow the user to view the current configuration of devices and ports within the system and the set-up functions may provide the ability to perform one or more of the following tasks: • Add/Remove/Update EndDevice - removing will remove all resource ports associated with this device, which will of course remove the ports from any resource groups they have been assigned to. o Add/Remove/Update ResourcePort o Add/Remove/Update ResourceGroup - can only be removed when not referred to by any dynamic or fixed allocation rules.
  • system may enable a system manager to add resources to a booking manually as well as being able to see the resources that have currently been allocated to a booking. This may be performed directly from a "view booking" screen and a tab or button only seen by users of correct privileges may give access to the booking resources.
  • routers 510, 512 illustrated in Fig. 5 two media servers 514, 516 (one for play; one for record), one VTR 518 for play and record to/from the system and one transmission server 520.
  • the two routers of the embodiment illustrated provide routing to from all devices in the system.
  • Router 1 further provides the system with external sources 522 to record from and playout to.
  • the system administrator can now group the system resources into groups for the purposes of resource allocation. This is shown in Fig. 6 where the administrator has defined 4 resource groups RG1 , RG2, RG3, RG4. (NB: This diagram is not intended to depict exactly how the client GUI screens may choose to represent resource groups but merely provides an illustrative example.)
  • the resource groups selected broadly correlate to functions that are required to be perform in this system. For example: o RG1 defines a set of resources that can be used to record media into the system. o RG2 defines a set of resources that can be used to record media from the VTR
  • ⁇ RG3 defined a set of resources that can be used to playout media from the system
  • RG4 defines a set of resources that can be used to playout media to the transmission server 520.
  • resources within the system may be contained in more than one resource group.
  • the diagram also shows why the set up of resource groups must be performed with great care.
  • the resource groups defined above actually prevent the system from allocating any route from VTR1 to the external destinations because VTR1 is in RG2, which has no access to the external ports.
  • the administrator can now assign the resource groups to allocated positions (which may comprise user groups at particular workstation groups) using dynamic and fixed resource allocation rules so that they can be used for record/playout.
  • allocated positions which may comprise user groups at particular workstation groups
  • the administrator may then define the following set of dynamic rules for the APs;
  • the temporally-limited access feature described above may be provided independently of the priority-weighting feature.
  • the rules may also provide the system with the ability to choose which resources within the resource groups to use at a given time, thereby potentially optimising the usage of the resources.
  • the administrator specifies the actual resource ports and not resource groups for the rule. Also, in the present system, the rule would have exactly the same effect if the port defined in the rule was the one on VTR2.
  • the APS users may be permitted to access the resource during the 12:00 to 13:00 time slot, but may be allocated a lower weighting than the AP1 users during that time, so any bookings from AP1 at that time would fake priority over a booking from an APS user.
  • a user of the system may be provided with an interface which displays the bookings and reservations in the system. This may be called the 'bookings view' or the 'arrivals board' and different interfaces may be provided for different aspects of the system.
  • One embodiment of a 'bookings view' interface is illustrated in Fig. 8b.
  • Fig. 8b illustrates schematically the bookings shown in Fig. 8b.
  • the interface may provide information regarding the movement of media essence through the system and may further provide an entry point for users to "Book" system resources.
  • the interface may also contain and provide details about sources or destinations involved as well as timing information.
  • the interface may further allow the user to actually bring in and send out media essence to/from the system and may provide the basic entry point for access to resources in the system.
  • the interface may allow users to see what is being brought into the system and when and may provide confidence for the users that recordings/playouts will happen
  • Fig. 9 illustrates schematically a further booking scenario as shown on a 'bookings view' interface.
  • the system can display on the interface which resources in the system are allocated to which bookings and when.
  • booking 4 cannot be performed as no resources are available at the time of the booking. If booking 4 is more important (for example, if it has a higher priority weighting), the system may perform booking 4 in place of bookings 1 and 2.
  • booking 3 takes up more resources as it has 2 destinations: System and VTR.
  • Figs. 10a and 10b illustrate the process of bookings using allocated positions.
  • the user's allocated position can only access the resources shown in box 1010. If the user attempts to make bookings 2 and 4, the bookings will fail to be allocated as the user only has access to limited set of resources, which does not include the resources required for bookings 2 and 4. Booking 3 will succeed but the 'Also To' part of the booking will fail.
  • the configuration of a system according to one embodiment will now be described. Aspects of the configuration described may be used in other systems or a different configuration may be used to provide the system.
  • the Resource Configuration may be used to hold the Model of the system devices, ports, connections etc.
  • Resource Allocation system may use the resource configuration to provide a picture of what resources are available to it so that it can perform bookings.
  • resources can be configured either through the resource management screens or via a configuration file.
  • Each configuration may contain information about devices, ports, connections, information about device and port status (enabled/disabled) and information about Allocated Positions, Dynamic Allocation Rules and Resource Groups.
  • Changing the resource configuration may force the system to perform all reconfiguration tasks and make attempts to re-allocate all bookings affected or currently un-allocated bookings. This may be a very intensive/expensive task for the mid-tier of the system.
  • a configuration file of the present system may comprise an XML file containing an entire resource configuration.
  • Using configuration files may allow a default configuration to be quickly setup or restored and the files can be used as a backup if configuration is lost.
  • the files are preferably loaded into the system via an MBean interface (or programmatically).
  • the resource configuration files described below may provide a simple mechanism to pre-load a database with a resources setup for resource allocation. This may allow a known setup to be installed into any system and then (potentially) adjusted by a system administrator at a later date through the resource management screens.
  • the configuration file may allow the system to be restored to a known configuration as well as potentially providing a mechanism to set up resource configurations quickly.
  • the resource configuration files of the present system may be written in a markup language, such as XML, and may contain several configurations in one file.
  • the XML format may allow for the specification of all resources that resource allocation is concerned with. This includes Routers, Media Servers, VTRs as well as any other devices that the service must be aware of.
  • the file may provide the ability to define the ports available on them and then subsequently define how these ports are connected. This definition can optionally include the physical information for each device and port.
  • the configuration file preferably contains at least one configuration that is defined using the resource-configuration element.
  • the example below shows an entry for a configuration called 1244Config.
  • each file may contain multiple resource-config entries:
  • Inside the resource-config element may be defined any number of end-device elements, for example:
  • These entries are the devices of the system, which can be of several types.
  • the types supported may include:
  • the devices may include both devices that are controllable by the resource allocation system and devices that are not controllable.
  • Each device entry may also (optionally) contain the physical information related to the device. This will differ depending on the type of device you are defining. For example for a Router device the physical information that may be added is as follows:
  • Each device defined may also have a number of port entries. These may be defined using the resource-port tag. So to complete the router example the entire device definition may look something like the following:
  • Each resource port entry preferably contains all the information required about that port in terms that resource allocation understands.
  • each resource-port tag contains 6 attributes to configure:
  • Each port can then also contain physical information for each port as seen in the example above.
  • Connections may be used to define which ports are joined to which other ports in the system.
  • An example connections entry is shown below: ⁇ connections>
  • the example section above defines a number of connect entries that define which resource ports are connected to which. Care must be taken when defining these entries that the names are valid.
  • the 'from' and 'to' attributes must match the corresponding resource port name attribute defined earlier in the configuration file. Also the 'from' and 'to' attributes must be defined correctly according to the direction required. For example if you wish to connect from "port A" to "port B" then the correct entry would be:
  • Resource group definitions may be used to define the resource groups you wish to set up for the configuration.
  • Each resource group entry may consist of a number of resource ports to add to the group.
  • Allocated position definitions may be used to define the allocated positions you wish to define in the system. Each entry defines one allocated position with a number of dynamic rules that provide the allocated position with access to resource groups. An example definition is given below.
  • This definition describes an allocated position called "AP1 ". This is the name that will appear on any drop downs for selecting allocated positions.
  • This allocated position also has two rules defined for it, which will provide it access to resources from resource group RG1 for all time. Although this entry includes the year, month and date in it this is simply to provide consistency of date formatting. In the present embodiment, only the time entries are used by resource allocation.
  • the first rule also says that the allocated position has access to any number of resources from the RG1 group by setting the max-number-resources attribute to "-1 ".
  • the second rule defined for this allocated position will give it access to resource group RG2 between 12:00 and 14:00 and allow 4 resources to be used from the group.
  • resource group RG2 between 12:00 and 14:00 and allow 4 resources to be used from the group.
  • physical device and port information can also be contained in resource configuration files for the purpose of setting a system up with this information.
  • model-number The manufacturers model number • tape-format - The tape type the machine uses
  • router-port-id The physical device assigned id of the port (for a combiner this is synonymous with the package name)
  • the resource configurations can be loaded into the system either programmatically or via an interface such as the JMX (Java Management Extension) MBean interface.
  • the MBean interface can be accessed via a standard web browser, which may enable a user to remove and reload resource configurations. Removal of a configuration can be performed in a straightforward operation, for example by clicking the button underneath the heading removeAIIResources().
  • Loading of a resource configuration can be performed by using the form underneath the setupResourcesO heading. This form takes two parameters the first is the name of the file to use the second is the name of the configuration from within that file. For example:
  • 1244Config is the name of the configuration within the file 1244ResourcesConf ig.
  • the system may further comprise user interfaces or GUIs to enable users to perform tasks such as searching for particular booked tasks or for particular items, such as media items in the archive.
  • media items and media essence contained in the system may be the result of recording from the edit matrix, or from the archive service, or may be imported from the editing services.
  • a variety of recording methods are supported by the system, including methods for media sources that must be recorded live from within the news facility, from a tape source, or an Agency feed. These are managed by a centralized facility, which may be referred to as the 'Mediaport'. The Mediaport is also responsible for managing the subsequent accessing of recordings.
  • All of the media items recorded into the system are assigned metadata.
  • the different types of metadata assigned to media items may vary according to the particular item. This metadata is assigned by the Mediaport or by Mediaport staff.
  • the metadata may be automatically imported from an external source, assigned by the Mediaport, or automatically assigned a default value.
  • Metadata added automatically (or manually) when a media item is created as a part of recording includes:
  • the system may usefully define 3 levels of restriction for metadata fields:
  • a further "None” category may be defined to indicate a “Not Ever” setting.
  • the system For each data value entered or altered, the system records the following information:
  • Crash Recording Many recordings, such as news events, are unanticipated and require very rapid response by the news staff. In such instances a recording method known as Crash Recording and described above is employed. The goal of Crash Recording is to provide a very rapid method for recording important breaking news. The steps required to initiate the Crash Recording must be kept minimal. All required metadata fields are preferably filled with default values. Clip name will be simplified to a default value of ⁇ CRASH RECORD/User Name/Date and Time> where 'user name' is derived from user login, and 'date and time' represents the time recording is started. Media Status will be set as 'Raw'.
  • 'Item Identifier' will be set by default using a counter algorithm, with PR (production item) or MP (non product item) as a suffix. Start timecode for the media item shall begin at 00:00:00:00. Recorded/Created By will be derived from the users login, and outlet will default to the last outlet the user had selected. The default usage traffic light value is green, default usage restrictions are set to 'restricted to 24 hours without additional modification', story name and description are defaulted to 'Crash Record'. It will be apparent that different applications will use different metadata values and that, even in a given application, default item values may vary. All values set at the initiation of recording can, and most should, be modified later. In this way a crash recorded media item can be recorded and utilized short term with minimal effort, and the metadata details that are required for medium and long term utilization can be assigned as soon as practical.
  • crash record scenario can also be used where a system user has a tape that needs to be ingested into the system. This creates a fast and simple way to get media into the Mediaport, while minimizing the time required on the recording station. All required metadata can be updated afterwards at a viewing/editing/logging station.
  • a metadata field may have restriceted access or not be visible to certain users or user groups.
  • a specific metadata field may be 'Mandatory' for a Media Coordinator, but 'Not Visible' for a general lower-privilage user.
  • Data transfers can be received via a push process from a variety of external sources.
  • Data transfer may have Mediaport bookings representing anticipated data transfers. Mediaport bookings should be used for anticipated data transfers so that users may track data transfers, and so that collection and dissemination of related metadata can begin prior to arrival.
  • the metacore is intended to serve as a short-term repository of currently relevant media. As time goes on, more and more media items contained in the metacore will represent archived assets. When users need access to archived media items, they will request them to be transferred back into online storage. This initiates a chain of events that result in the simple recording of tape-based media from the archive into the Mediaport, or retrieval from a digital archive. In a news application many recordings will be from agency feeds and will be recorded at regular times. The system therefore supports automatic recording. There are three types of automated recordings:
  • the type of automated recording is specified when the booking is created and may allow large media items to be split into sections or "chunks" for easier handling.
  • the complexities of automated bookings lie primarily in the creating automated booking functionality. The initiation itself will simply proceed in an automated fashion, without user interaction or intervention. Mediaport staff will monitor the recordings for errors or failures as a part of their normal duties
  • the media system may be integrated into an existing or legacy system. It may be desired to use two systems cooperatively or for one system to replace another.
  • CBIS the Central Bookings and Information Service
  • the Mediaport is adapted to import bookings from CBIS.
  • Imported information should include:
  • the system can differentiate between Internal and External bookings.
  • External bookings are any bookings with a CBIS reference number, inferring that the bookings have been or will be imported to the system from CBIS.
  • Internal bookings are not imported from CBIS and will not have a CBIS reference number.
  • the typical Mediaport booking scenario is that an item is automatically imported from CBIS, and then reviewed by a Mediaport Manager who has assigned the booking to a Media Coordinator for recording.
  • the Mediaport Manager and the Media Coordinator may be manual system operators or controllers or may be part of an automated system.
  • transcoding capabilities are provided within the system to enable the system to create additional media essence instances at different (typically lower) resolutions.
  • This supports multiformat editing, and makes efficient use of available storage facilities and archiving capabilities, whilst maintaining searching and viewing functionality.
  • the system will be able to create new media essence instances when these media resolutions needed. It is most preferable to encode and store multiple resolutions concurrently while recording. Alternatively multiple resolution instances can be encoded from the primary media input, as an automated process, during ingest. It is also desirable to be able to re-encode media for long-term media maintenance reasons. While encoding of media is happening, a list of items to be transcoded can be viewed by Mediaport staff to monitor progress. An example of the different resolutions used in one embodiment of the system is shown in table 2:
  • audio tracks may also often need to be supported. It is preferable that at least two audio tracks be provided for each video track, preferably four.
  • a particularly suitable application of the systems described herein is news production, and the development of news stories for broadcast.
  • News stories are the reporting of details and background for regional and world events.
  • News stories are very dynamic.
  • News staff often have a large number of stories that are actively being reported, covering a range of categories.
  • the relative importance of a story changes continuously. Depending on other current events, a single story can rise or fall in relative importance. This is reflected in the amount of broadcast coverage the story receives.
  • the story is an item of metadata; an attribute of bookings, media items, and grouped stories.
  • the story also has attributes including Story Description, Story Valid From Date/Time, Story Expiry Date/Time, Created By, Creation Date, Story Status Code, Top Story Indicator, Dominant Story, Indicator, Story Group, and Outlet.
  • the story represents a news event that is being covered.
  • the story name is a short-hand name or handle (e.g. news room jargon) for the broadcast coverage that a news event is receiving.
  • Bookings, media items and production media items are all assigned a story name so that they can easily be identified as relating to a specific news event.
  • stories can be grouped into collections of story names that are related.
  • Story groups are a collection of stories and have a set of stories as attributes.
  • Story names are intended to be short-term identifiers. Media items that are to be archived should have more substantive descriptive metadata to facilitate better search results and improved utilization. Story names provide a simple way to reference media items that have short-term value, may not receive much additional descriptive metadata, and will not be archived. Stories may have a variety of production items related to them.
  • Bookings can exist without a story association, however users should be encouraged to add story associates whenever possible to maximise the usefulness of the system.
  • media items and component media items also can exist without a story association, but again they will not be as recognizable to users.
  • Story associations can be added and changed for both bookings and media items at anytime after a media item is created.
  • stories can exist without any associated bookings or media items.
  • stories can be created within the editing system simply to serve as the dominant story in a story group to organize the story picklist.
  • a complex event may be covered though a series of related stories, with no production media items ever being created for the dominant story itself.
  • stories remain in the system until they are manually deleted.
  • Story deletion and data housekeeping may be a Mediaport user responsibility.
  • Dominant (e.g. current or live) stories must have their dominant status removed before they can be deleted.
  • all stories will have 'Valid from Date' and an 'Expiry Date' metadata attributes. This allows recognition of stories that are current. From this information Mediaport users can maintain current 'picklists' containing only stories that are current. This functionality also enables users to be able to create and identify stories that will receive coverage at some time in the future. The system will also store stories that received coverage in the past. All story metadata including description, as well as 'Top Story' and 'Dominant Story' indicators for future, current and expired stories. This facility will enable a variety of options that will be discussed further in the description of search facilities and capabilities below.
  • Story names play a very important role in enabling users to identify relevant bookings and media items. They can also form a valuable bridge between the system and legacy systems.
  • the first characters of the legacy booking identify the story name, and this will automatically import into the Mediaport.
  • the clip naming convention will enable the users to recognize the same names across new and old systems.
  • An example of a clip naming convention is: Story Name / Details / Arrival or Transmission Date and Time
  • the story picklist would quickly become unmanageable without the ability to group and associate stories.
  • related stories can be grouped.
  • An evolving story can be associated with other related or sub-stories and new story names.
  • a new story name may eclipse or complement the original.
  • Associating stories creates a story hierarchy. However, the hierarchy may only have one sub level.
  • a story name can act as parent to a group of related stories.
  • one story name of the group can be selected as dominant representing the parent of the group. It is also possible to ungroup or disassociate stories as necessary. It is preferred that only one story can be the dominant story for a group.
  • Each story should have a 'description' to help prevent stories that are different, but have similar subjects, from being accidentally selected or grouped.
  • the Story description is optional, and can be updated by other system users. Table 3 shows examples of metadata attributes of a story that can be added:
  • Metadata will be specified as mandatory, some as optional. Default values can be assigned so that some of these fields can be automatically populated. Also users may be restricted from adding, modifying or even viewing some metadata.
  • stories must have an 'Expiry Date'. This defines how the duration of time the story will be valid within the system. Only current stories appear in the story picklist. stories that have past their 'Expiry Date' are considered expired. If an 'Expiry Date' is not assigned at story creation, a default value will be assigned. Expiring stories is a way to remove the story from the pick list without losing the related metadata from the system. This can be done by chang ing the 'Expiry Dale' metadata. The most common reasons for modifying a story wi ill be to extend or expire story coverage. It may be useful to add user interface fund ions such as 'expire story' or 'extend 24 hours' to simplify these common tasks.
  • Deleting a story not only removes it from the pick list, it totally removes it from the system. Before a story can be deleted, the system may require that any associated media items be associated with a different story.
  • Another metadata item attributed to stories is the 'Top Story Indicator'. This enables all users fo easily identify the day's major news.
  • the top story indicator is either set to 'yes' or 'no', with 'no' the default value.
  • a client-server system interface is illustrated in Fig. 11.
  • system clients will be implemented as Win32 native clients 1802.
  • Such a mechanism may be provided to allow the clients to communicate with the J2EE application server 1804.
  • the client server communications will be facilitated via use of a Java-C++ bridge 1806.
  • the C++-Java Bridge allows C++ proxy stubs to be generated from Java classes. This allows any C++ client to behave as a standard Java client.
  • a thin C++ wrapper may be provided (generated) around the required J2EE client API's (Application Program Interface) to allow the client to access components on the application server.
  • the C++-Java Bridge will be used to generate C++ proxy stubs for the EJB (Enterprise Java Bean) remote and home interfaces, thereby, allowing the client to perform interaction with the application server in the same way as any Java client would.
  • Certain client views may be required to receive events from the application server (e.g. notification on booking status changes). These may be sent to the clients in the form of JMS messages via JMS Service 1808 from the application server.
  • the C++-Java Bridge may convert the message into an event and the appropriate action can then be taken by the client application.
  • the client may register interest with any number of event topics. This will allow the client to receive events that represent actions performed by various metacore services.
  • the payload of the message will vary depending on the type of event generated by the editing system and preferably includes all the information required by the client to perform the required action.
  • Users of the system can perform various different types of searches by querying metadata stored online in the metacore, for various types of user activity. Different search facilities will be appropriate for different user groups. Users may be able to search the system both for online media items, and also offline media items, which have associated metadata in the metacore. This will preferably be items that were online in the system at some point in time. If desired, users can request that offline media items be moved online.
  • Users may also be able to use system search facilities to search for stories.
  • users will be concerned with searching/viewing stories by expiry date (so to extend as necessary), searching/viewing stories by status (so as to check 'unchecked' stories), and searching/viewing in the current pick list order (so as to review and if necessary change story associations).
  • Users may additionally be able to use the search facilities of the system to search for Bookings. This enables users to create and save views for all bookings, internal and external, departures and arrivals using a simple search interface.
  • the search spans a predefined set of metadata fields
  • Simple search enables users to search for media (via on-line metadata) using a simple user interface similar to common Web search engines.
  • the user specifies a single word or phrase but does not specify the metadata fields to search across.
  • the system may search a predefined set of metadata fields.
  • Intermediate search is similar to the Simple Search but has additional control over the scope and filtering of the search criteria.
  • the user may select to search for online media or to perform an archive search, which would present a different set of search criteria depending on the search type.
  • search for current media items might include:
  • the Intermediate Search capabilities will enable the user to Search for expired, current and future stories by all story metadata.
  • Advanced Search may enable a user to search for media by all available metadata.
  • Each search may consist of one or more search terms.
  • Each term consists of a metadata field name (e.g. Story Name), operator (e.g. equal to) and search value (e.g. "War"). Search terms are joined together by Boolean operators (e.g. AND) that in turn make complex search criteria with the capability of spanning multiple metadata fields.
  • Predefined searches can be accessed using either shortcuts or selections from a longer preset list of searches.
  • Mediaport users will typically have specific search requirements including, searching/viewing bookings for CBIS clean-up, record/playout decision, traffic light/copyright/usage restriction settings, search by status.
  • the results of these predefined searches will be geared towards the role of the logged in user's workflow and interoperability with other applications and tools.
  • Searches and search results lists are preferably persistent and roving. That is to say they travel with the user from machine to machine. Users can save searches and share saved searches, allowing team members to share collections of media items.
  • the results of the future search which may not yet have entered the system are notified to the user when such bookings or media items that meet the users criteria are found (enter the system).
  • the future search may be for bookings, media items or both.
  • the user must enter an expiration date when saving a future search, after which results are no longer returned.
  • the system may further provide an interface to allow users to view media items or aspects of media items.
  • the system may advantageously allow users to view media items on-line from any enabled system terminal.
  • this will preferably be any PC configured to use a news production system, for example the ENPS system (Electronic News Production Service).
  • ENPS Electronic News Production Service
  • the viewing and logging tools may be available integrated within ENPS or as a stand-alone tool.
  • Media can be played out and viewed from the system at any time, even as it is being captured. Users will also be able to view the media item's essence data file as it is being written. This differs from watching the feed or package because playback is 'on demand' from the system. Whenever the user selects the item for playback, they can start play from the beginning of the clip, regardless of what time the recording began.
  • the system provides users with the ability to use the full set of media viewing functions such as fast forward, reverse, jog, shuttle and scrub.
  • Viewing will preferably use desktop resolution media instances, however in certain applications it may be desirable or even essential to use instances of higher or lower resolution. It is therefore not relevant for viewing purposes whether or where a broadcast quality equivalent of the viewed media essence is also available on-line. In this way, archive media can be viewed quickly and easily to allow a user to make decisions based on a desktop representation of that media.
  • the system may further provide desktop editing of data by users.
  • Two main editing facilities may be provided by the media system.
  • the first is a desktop editor.
  • the majority of editorial work on media will be done using the desktop editor application, running on any ENPS capable desktop PC.
  • ENPS capable desktop PC.
  • users will be able to complete editorial tasks from simple 'Tops and Tails' editing - the process of selecting the beginning and end of a single shot for broadcast, fo the creation of EDLs that will be automatically conformed by the system for broadcast.
  • the Desktop editing work will begin by searching and selecting media items in system as described above. Selected media items are moved into the Desktop editor application from the system by adding the items to a Desktop Edit Clip List. Each user has an individual Desktop Edit Clip List, which makes the media item essence and metadata available to the user in the Desktop Editor. Likewise, the user is able to delete media from the Desktop Edit Clip-list. Deleting from the Desktop Edit Clip-List does not delete the media item from the system. In addition to the Desktop Edit Clip-List, users can also view the last 10 media items that they have logged or viewed.
  • the package can be shared in two ways.
  • the system preferably enables the viewing of the edit as an EDL, a simple tab delimited list of events representing the edit.
  • the EDL can also be shared with other applications or systems as a Private Text Document.
  • media may need to be moved to the local workstation.
  • Production media items that are produced using the Desktop Editor are published to the system.
  • the system does not have any version control capabilities, so each revision of a production media item published to the system will be new and unique. There will be no association between revisions other than that manually implied when choosing the media item name.
  • the Desktop Editor only publishes media item EDLs, and at this stage, no media essence.
  • the EDL is automatically conformed by the system.
  • the publish process initiates the creation of a new media item, an automatic EDL conform process, creates a broadcast quality media instance, as well desktop and Web resolutions.
  • an automatic EDL conform process creates a broadcast quality media instance, as well desktop and Web resolutions.
  • the production media item is published, the user will be notified of the estimated time of completion.
  • the queue list of expected conforms can also be viewed.
  • Once the automatic conform is complete the media item will work just as any other media item in the system. All searching/logging/viewing capabilities apply.
  • a journalist In a news application, a journalist often begins work on a news story, focusing on story content, producing a draft edit. This draft edit will be further refined for broadcast by an editor who addresses the more stylistic elements creating a polished production item. This process requires the decisions made by the journalist, referencing desktop resolution media, to be communicated to the Craft Editor, and media references redirected to broadcast resolution media instances within the system. The user will then use the Craft Editor application to take the draft edit and complete the refinement process.
  • the process of publishing from the Desktop Editor will create new media items within the system. These new media items can be used as source media for a Craft Edit.
  • the Desktop Editor can be used to do a first pass edit of source materials that can selected for longer feeds and clips, creating very usable new media items that may be very appropriate for Best Media and Archive Recommendation designation. Such items may be given a status of 'Rough cut'. No EDL metadata is necessary for the sharing of these assets. They will be available through normal search and view capabilities.
  • a second type of editing that may be provided is "craft editing".
  • the Craft Editor uses broadcast quality media ingested to the system. However it will be necessary to export media items to the Craft Editor for working. The export process will enable the Craft Editor to access media items available from the system. All the viewing / logging / searching capabilities are available to users while using the Craft Editor. The user will also be able to use the History Clip-List to simplify the moving of media items to the Craft Editor.
  • Production media item EDLs are published to the system and then conformed.
  • the queue of Production Media Items to be conformed can be viewed to monitor status. Users are notified of the expected duration of the conform process.
  • Production media items will be exported by the Craft Editor using the Advanced Authoring Format (AAF)
  • users may view online media items, identify and request that offline media items be moved online, view media items, annotate and add to metadata, modify or delete information for media items, copy annotation between media items, create component media items, add bookmarks within media, create and add simple EDLs and production media items into " the stories, develop scripts and write captions all in a very flexible, easy to use environment.
  • the system may further provide one or more Graphical User Interfaces (GUIs).
  • GUIs Graphical User Interfaces
  • system application views screens
  • Screens are presented as non-overlapping, sizeable windows as selected by the user. It will provide the necessary menus to select and display views. Shortcuts will feature heavily so users can quickly and easily access the views they need for their day-to-day work - their role will dictate how each view is presented. Where necessary to aid workflow, combinations of views will be arranged suitably.
  • the definition of the view presentation and combination will be configurable and stored as scenes. Each view will have a required set of permissions that have to be satisfied in order for the view to be displayed. Each view in itself will have various menus/buttons etc that are also subject to the users permissions and will be disabled and enabled as appropriate.
  • each of the views will support cut, paste, drag and drop between themselves, other views and ENPS.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Television Signal Processing For Recording (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Selective Calling Equipment (AREA)
  • Multi Processors (AREA)

Abstract

L'invention a trait à un procédé et à un appareil permettant à au moins un utilisateur utilisant au moins un poste de travail de réguler l'accès à des ressources dans un système d'édition de contenu multimédia. Le système selon l'invention comprend une pluralité de ressources, un groupe de ressources étant associé à chacune des ressources, une pluralité d'utilisateurs, un groupe d'utilisateurs étant associé à chaque utilisateur, et une pluralité de postes de travail, au moins un groupe de postes de travail étant associé à chaque poste de travail. Des attributs sont assignés aux groupes de ressources, aux groupes d'utilisateurs et aux groupes de postes de travail. Une demande d'autorisation à accéder à au moins une ressource est reçue d'un utilisateur utilisant un poste de travail à un moment spécifié, et une autorisation à accéder à ladite ressource est déterminée pour l'utilisateur au niveau du poste de travail sur la base des attributs assignés au groupe d'utilisateurs de l'utilisateur, du groupe de ressources de la ressource et du groupe de postes de travail du poste de travail.
PCT/GB2004/001505 2003-04-04 2004-04-05 Procede et appareil permettant de commander dynamiquement un systeme de production de contenu multimedia diffuse WO2004088553A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US46064903P 2003-04-04 2003-04-04
US60/460,649 2003-04-04

Publications (2)

Publication Number Publication Date
WO2004088553A2 true WO2004088553A2 (fr) 2004-10-14
WO2004088553A3 WO2004088553A3 (fr) 2004-12-09

Family

ID=33131929

Family Applications (7)

Application Number Title Priority Date Filing Date
PCT/GB2004/001506 WO2004088990A2 (fr) 2003-04-04 2004-04-05 Commande de stockage de contenu multimedia
PCT/GB2004/001493 WO2004088664A2 (fr) 2003-04-04 2004-04-05 Systeme et procede de gestion de multimedia
PCT/GB2004/001468 WO2004088663A2 (fr) 2003-04-04 2004-04-05 Processeur de media
PCT/GB2004/001505 WO2004088553A2 (fr) 2003-04-04 2004-04-05 Procede et appareil permettant de commander dynamiquement un systeme de production de contenu multimedia diffuse
PCT/US2004/010766 WO2004090677A2 (fr) 2003-04-04 2004-04-05 Systeme et procede de traitement de contenu multimedia
PCT/GB2004/001481 WO2004088887A2 (fr) 2003-04-04 2004-04-05 Systeme et procede de gestion multimedia
PCT/GB2004/001492 WO2004088984A1 (fr) 2003-04-04 2004-04-05 Systeme et procede de stockage et de recherche de donnees video avec conversion de la resolution

Family Applications Before (3)

Application Number Title Priority Date Filing Date
PCT/GB2004/001506 WO2004088990A2 (fr) 2003-04-04 2004-04-05 Commande de stockage de contenu multimedia
PCT/GB2004/001493 WO2004088664A2 (fr) 2003-04-04 2004-04-05 Systeme et procede de gestion de multimedia
PCT/GB2004/001468 WO2004088663A2 (fr) 2003-04-04 2004-04-05 Processeur de media

Family Applications After (3)

Application Number Title Priority Date Filing Date
PCT/US2004/010766 WO2004090677A2 (fr) 2003-04-04 2004-04-05 Systeme et procede de traitement de contenu multimedia
PCT/GB2004/001481 WO2004088887A2 (fr) 2003-04-04 2004-04-05 Systeme et procede de gestion multimedia
PCT/GB2004/001492 WO2004088984A1 (fr) 2003-04-04 2004-04-05 Systeme et procede de stockage et de recherche de donnees video avec conversion de la resolution

Country Status (1)

Country Link
WO (7) WO2004088990A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7493350B2 (en) 2004-10-25 2009-02-17 International Business Machines Corporation Entity based configurable data management system and method
US7587507B2 (en) 2005-07-22 2009-09-08 Microsoft Corporation Media recording functions in a streaming media server
EP1758398A1 (fr) 2005-08-23 2007-02-28 Syneola SA Moyens d'interface pour metadata et utilisateur basés sur une semiotique à plusieurs niveaux et une logique floue pour un système interactif multimédia ayant une capacité d'adaptation par acquisition de connaissances
US8019155B2 (en) 2007-03-26 2011-09-13 Eastman Kodak Company Digital object information via category-based histograms
US8903842B2 (en) * 2007-10-26 2014-12-02 Microsoft Corporation Metadata driven reporting and editing of databases
GB2522296B (en) * 2014-10-08 2016-11-02 Deluxe Broadcast Services Ltd Broadcasting Apparatus
US11693827B2 (en) 2016-12-29 2023-07-04 Microsoft Technology Licensing, Llc Syncing and propagation of metadata changes across multiple endpoints
CN111508468B (zh) * 2020-04-17 2021-01-01 北京灵伴即时智能科技有限公司 录音编辑管理方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4989191A (en) * 1989-01-03 1991-01-29 Frank Sheafen Kuo Data processing system with mixed media memory packs
US5964849A (en) * 1997-04-01 1999-10-12 Sony Corporation Controlling video devices
WO2000072574A2 (fr) * 1999-05-21 2000-11-30 Quokka Sports, Inc. Architecture de commande du flux et de la transformation de donnees multimedia
US20010037379A1 (en) * 2000-03-31 2001-11-01 Noam Livnat System and method for secure storage of information and grant of controlled access to same

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1322422C (fr) * 1988-07-18 1993-09-21 James P. Emmond Fichier indexe a cle unique pour gisements de file d'attente de traitement transactionnel
US5428737A (en) * 1991-10-16 1995-06-27 International Business Machines Corporation Comprehensive bilateral translation between SQL and graphically depicted queries
JP3248380B2 (ja) * 1994-12-15 2002-01-21 ソニー株式会社 データ復号化装置およびデータ復号化方法
JPH0981497A (ja) * 1995-09-12 1997-03-28 Toshiba Corp 実時間ストリームサーバ並びに実時間ストリームデータの格納方法および転送方法
JP3883579B2 (ja) * 1996-04-12 2007-02-21 アビッド テクノロジー インコーポレイテッド データ管理機構を改善したマルチメディア・システム
US5826081A (en) * 1996-05-06 1998-10-20 Sun Microsystems, Inc. Real time thread dispatcher for multiprocessor applications
JP3741299B2 (ja) * 1997-04-06 2006-02-01 ソニー株式会社 映像信号処理装置及び映像信号処理方法
WO1999016196A1 (fr) * 1997-09-25 1999-04-01 Sony Corporation Dispositif et procede de generation d'un train de donnees codees, systeme et procede de transmission de donnees et systeme et procede d'edition
US6070228A (en) * 1997-09-30 2000-05-30 International Business Machines Corp. Multimedia data storage system and method for operating a media server as a cache device and controlling a volume of data in the media server based on user-defined parameters
US6215485B1 (en) * 1998-04-03 2001-04-10 Avid Technology, Inc. Storing effects descriptions from a nonlinear editor using field chart and/or pixel coordinate data for use by a compositor
US20030001880A1 (en) * 2001-04-18 2003-01-02 Parkervision, Inc. Method, system, and computer program product for producing and distributing enhanced media
US6766357B1 (en) * 1999-04-15 2004-07-20 Avid Technology, Inc. Apparatus and method for efficient transfer of multimedia data for playback
US6539163B1 (en) * 1999-04-16 2003-03-25 Avid Technology, Inc. Non-linear editing system and method employing reference clips in edit sequences
US6792615B1 (en) * 1999-05-19 2004-09-14 New Horizons Telecasting, Inc. Encapsulated, streaming media automation and distribution system
WO2001028238A2 (fr) * 1999-10-08 2001-04-19 Sarnoff Corporation Procede et appareil permettant d'ameliorer et d'indexer des signaux video et audio
US20020056119A1 (en) * 1999-12-23 2002-05-09 Moynihan Michael W. Personal video channel system
US6954795B2 (en) * 2000-04-05 2005-10-11 Matsushita Electric Industrial Co., Ltd. Transmission/reception system and method for data broadcast, and transmission apparatus for data broadcast
US6882793B1 (en) * 2000-06-16 2005-04-19 Yesvideo, Inc. Video processing system
US20020089602A1 (en) * 2000-10-18 2002-07-11 Sullivan Gary J. Compressed timing indicators for media samples
AU2002350949A1 (en) * 2001-06-25 2003-01-08 Redhawk Vision Inc. Video event capture, storage and processing method and apparatus
US7856055B2 (en) * 2002-03-13 2010-12-21 Imax Corporation Systems and methods for digitally re-mastering or otherwise modifying motion pictures or other image sequences data

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4989191A (en) * 1989-01-03 1991-01-29 Frank Sheafen Kuo Data processing system with mixed media memory packs
US5964849A (en) * 1997-04-01 1999-10-12 Sony Corporation Controlling video devices
WO2000072574A2 (fr) * 1999-05-21 2000-11-30 Quokka Sports, Inc. Architecture de commande du flux et de la transformation de donnees multimedia
US20010037379A1 (en) * 2000-03-31 2001-11-01 Noam Livnat System and method for secure storage of information and grant of controlled access to same

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
U.S.ROBOTICS: "PalmPilot Handbuch, part number 423-0210-01" 1997, U.S.ROBOTICS GMBH,UNTERF\HRING,GERMANY , GERMANY , XP002297179 page 47 pages 58-60 *

Also Published As

Publication number Publication date
WO2004088887A3 (fr) 2005-06-30
WO2004090677A9 (fr) 2005-03-31
WO2004088664A2 (fr) 2004-10-14
WO2004088984A1 (fr) 2004-10-14
WO2004088663A2 (fr) 2004-10-14
WO2004088887A2 (fr) 2004-10-14
WO2004090677A2 (fr) 2004-10-21
WO2004088553A3 (fr) 2004-12-09
WO2004090677A3 (fr) 2007-05-10
WO2004088990A3 (fr) 2004-11-18
WO2004088990A2 (fr) 2004-10-14
WO2004088663A3 (fr) 2004-12-02
WO2004088664A3 (fr) 2005-03-17

Similar Documents

Publication Publication Date Title
US20230325445A1 (en) Methods and apparatuses for assisting the production of media works and the like
US8670651B2 (en) Editing device, editing method, and program
US9781486B2 (en) RS-DVR systems and methods for unavailable bitrate signaling and edge recording
JP5112287B2 (ja) ネットワーク上でデジタルメディアの分散編集及び記憶を提供するための方法及びシステム
US6704489B1 (en) Resource management system and digital video reproducing/recording apparatus
CA2369493C (fr) Appareil et procede de transfert efficace de donnees multimedia destinees a etre lues
US20070127667A1 (en) Method and apparatus for providing remote workflow management
KR20080107308A (ko) 컨텐트 디렉토리 서비스와 제어 포인트간의 컨텐트를동기화하는 방법
US20150264448A1 (en) Interactive personal/internet protocol television reservation system, reservation plan management method and device
JP2010524125A (ja) メディアの生成及び分配のための動作管理ソリューション
KR101210114B1 (ko) 정보 처리 시스템, 정보 처리 방법, 및 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록 매체
WO2007134918A1 (fr) Mémoire distribuée
JPH04217038A (ja) 資源オブジェクトの関係する活動のレコードを維持する方法及びそのためのデータ処理システム
WO2004088553A2 (fr) Procede et appareil permettant de commander dynamiquement un systeme de production de contenu multimedia diffuse
CN115955581A (zh) 一种实时视频处理方法、装置、设备及存储介质
US7693846B2 (en) Data management system and method for data synchronization
EP1860846A1 (fr) Stockage distribué
Volckaert et al. Gridification of collaborative audiovisual organizations through the MediaGrid framework
US20220191264A1 (en) System and method for moving media content over a network
US20240340470A1 (en) System and method for optimizing the distribution of available media production resources
JP2001014159A (ja) データ蓄積運用システム及びそのソフトウェアライセンス管理方法並びにソフトウェアライセンス管理方法のプログラムを格納した記憶媒体
JP2001077776A (ja) 番組制作送出装置および記録媒体
JP4461875B2 (ja) 映像配信システム及び方法
CA3202617A1 (fr) Systeme et procede pour deplacer un contenu multimedia dans un reseau
WO2022263665A1 (fr) Système et procédé d'optimisation de la distribution de ressources de production de support disponibles

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase