 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 158: JavaTM Stream Assembly
Reason: Withdrawn at the request of the Spec Lead. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: TheJavaTM Stream Assembly API specifies classes and interfaces for the creation, management, and processing of broadcast and interactive stream multiplexes. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Gerard Fernando E-Mail Address: Gerard.Fernando@Sun.COM Telephone Number: & +1 650 786 6373 Fax Number: Specification Lead: Viswanathan Swaminathan & Gerard Fernando E-Mail Address: Viswanathan.Swaminathan@Sun.COM & Gerard.Fernando@Sun.COM Telephone Number: +1 650 786 4258 & +1 650 786 6373 Fax Number: +1 650 786 6445 Initial Expert Group Membership: Alticast Supporting this JSR: Alticast Section 2: Request
2.1 Please describe the proposed Specification:The proposed Stream Assembly API is an interface to support real time assembling of audio, video, and generic data streams. This API would provide a unified vendor neutral interface for (typically) server applications to create and modify multiplexed real time media streams over broadcast or IP networks. The goal of this API is to provide a multiplexing application a unified interface irrespective of whether the multiplexing functionality is implemented in hardware or software and irrespective of the type of data transport (broadcast, IP, etc.). This API will enable discovery, setup, monitoring, and start/stop control of the multiplexer components. Discovery, selection, and manipulation of inputs and outputs of the multiplexer components will be supported by this API. A multi program or a single program multiplexed MPEG-2 Transport Stream is usually the output of a multiplexer. This API would allow adding, dropping, and changing the components that make the multiplexed stream. Tables are inserted in broadcast streams which carry the information about the programs and components. The API would also allow table retrieval, modification and insertion. The API would also support system monitoring, exception, and event handling. Consideration would be given to see if it is appropriate to support redundancy and fault tolerance. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE 2.3 What need of the Java community will be addressed by the proposed specification?This API will accelerate the ability to develop open applications for real time delivery of audio, video, and data in broadcast and broadband networks. 2.4 Why isn't this need met by existing specifications?There are currently no open APIs for supporting stream assembly and data insertion. Companies rely on proprietary APIs. Java Media Framework, JavaSound, Java3D, Java Advanced Imaging are some of the other existing media related Java APIs. There is no overlap in the scope of these APIs and the proposed APIs. 2.5 Please give a short description of the underlying technology or technologies:Stream multiplexes combine multiple synchronized streams of video, audio, and/or data and are a foundation for digital and interactive television, interactive media streaming, and MPEG-2 transport streams. These streams may be built off-line or in realtime either through software application or in dedicated hardware accelerators. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.mediastream 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No, although realtime production systems often use dedicated hardware processing and DVB-ASI physical interfaces. 2.8 Are there any security issues that cannot be addressed by the current security model?No. 2.9 Are there any internationalization or localization issues?No. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. 2.11 Please describe the anticipated schedule for the development of this specification.2001-11-15 Submit JSR application. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Weekly conference calls will be held, and a formal mailing list will be set up for more frequent communication. Members of the expert group can initiate additional conference calls to resolve issues. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Sun StorEdge Media Central Multiplexing API 3.2 Explanation of how these items might be used as a starting point for the work.Sun StorEdge Media Central product contains an internal multiplexing architecture and API that is to be used as a starting point for this work. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
Detailed Requirements:
Title: Generalized stream assemby interface
1.0 Life cycle
- Resource discovery (i.e. broadcast equipment discovery)
- Resource locking
etc.
2.0 Stream composition management
- The API shall support basic stream session control, including
2.1 Structural management
- discovery of inputs
- selection of inputs
- selection, manipulation and exclusion elements
from inputs
- set-up
- add/drop service
2.2 Temporal management
- start/stop
- stream splicing.
3.0 Generality of I/O
3.1 Generality of input formats
The API shall allow the input to the system in a number of encodings
including:
- MPTS
- SPTS
- PES/ES
- MPEG privates sections
- raw data to be placed in TS packets
- IP for multi protocol encapsulation
3.2 Generality of input sources
The API shall allow input from various input sources including:
- Standard streaming broadcast interfaces (ASI, LVDS etc.)
- Standard data network interfaces (TCP/IP over ethernet etc.)
Provision shall be made to allow specialist data encoders to inject data.
For example, these might allow subtitle encoders or object carousel
encoders to inject data.
3.3 Generality of output formats
The API shall allow output in various formats including:
- MPTS
- PES/ES
3.4 Generality of output media
The API shall allow output over various media including:
- Standard streaming broadcast interfaces (ASI, LVDS etc.)
- Standard data network interfaces (TCP/IP over ethernet etc.)
4.0 Multiplex management
The APIs shall:
* be abstract to be used for both hardware and software
multiplexers.
* Present interfaces which
- enable control of the multiplexer
- enable inspection of status covering at least:
- data routing
- analysis of data traffic (e.g. PSI & SI information)
- enable discovery of the capabilities of the multiplexer
- enable discovery and configuration of the inputs
- enable management of quotas
- enable discovery and configuration of the outputs
- enable allow the muxer to work with other components like:
1. Format Encapsulators (Teletext, MPE, Private Data etc.)
2. Data/Object Carousels
5.0 Table Retrieval and Insertion
* The APIs shall, if possible, be generic across different signalling
schemes (e.g. DVB SI and ATSC PSIP).
* The APIs shall allow retrieval of incoming tables.
* The APIs shall allow generation and insertion of outgoing tables.
* Table access and update - get/set as Sections, TS or raw tables through
API calls.
* Format of representing the table: structural representation of the tables
would be supported if possible
6.0 Push/Pull capability
The APIs will be generic enough to support both Data being pushed to the
Muxer or Pulled from sources by the Muxer.
Similarly the APIs shall allow the output of the Muxer can be either
Pushed or Pulled by
another component.
7.0 Remote Invocation
* Remote invocation of the APIs shall be supported.
8.0 Support for Redundancy
APIs shall support:
* setup of multiple pieces of hardware for redundancy and fail-over.
* the same operation on more than piece of hardware simultaneously.
* proactive signalling during failure.
9.0 System Monitoring
- The APIs shall support providing system status information which
can be used for System monitoring.
- The APIs shall enable redundant equipment configuration and operation.
10.0 Framework Interoperability
The design of the API shall consider potential requirements and usage
scenarios of content services frameworks such as ISA and web services
interfaces and networked broadcast delivery environments.
|
||||||||||||||||||||||||||||||||||||||||||||||||
