Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 158: JavaTM Stream Assembly

Stage Access Start Finish
Withdrawn   14 Dec, 2011  
Public Review Download page 11 Apr, 2005 10 Jul, 2005
Community Draft Ballot View results 21 Jan, 2003 27 Jan, 2003
Community Review Login page 26 Nov, 2002 27 Jan, 2003
Expert Group Formation   11 Dec, 2001  
JSR Review Ballot View results 27 Nov, 2001 10 Dec, 2001
Status: Withdrawn
Reason: Withdrawn at the request of the Spec Lead.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

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)

Specification Leads
  Gerard Fernando Sun Microsystems, Inc.
Expert Group
  Kasenna, Inc. Sun Microsystems, Inc. VideoPropulsion, Inc.

This JSR has been Withdrawn
Reason: Withdrawn at the request of the Spec Lead.

Original Java Specification Request (JSR)

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:

Strategy & Technology
Sun Microsystems
Video Propulsion

Supporting this JSR:

Strategy & Technology
Sun Microsystems
Video Propulsion

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.)


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.)


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?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

2001-11-15 Submit JSR application.
2001-11-26 JSR approval by the EC committee.
2001-12-14 Expert group established.
2002-02-04 Draft of specification completed and approved by expert group.
2002-02-11 Submit Draft for community review.
2002-04-19 Draft revised by the community review and ready for review by EC.
2001-05-06 Submit draft for public review.
2002-07-03 Complete the final draft, the RI and the TCK.
2002-07-17 Submit the final draft.
2002-07-31 EC approval of final release.

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
MPEG-2 specifications (ISO/IEC JTC1 WG11 13818-*)
DVB specifications (TS 101812 , EN 300 468)
ATSC specifications (T3-5[28,29,30,31]R2 DASE-1 Part I-IV, T3-5[33,34,35,36]R0 DASE-1 Part VI-IX)

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

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
  - 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
        * 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.