opencore开发文档3

OpenCORE 2.0, rev. 3

Jun 25, 2010

© 2010 PacketVideo CorporationThis document licensed under the Apache License, Version 2.0 PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Table of Contents

1. Introduction ....................................................................................................... 5 2. Architecture ....................................................................................................... 5 2.1. Static Design ................................................................................................ 5 2.2. SDK State Machine Design ......................................................................... 6 2.3. Command Processing ................................................................................ 8 2.4. Sources and Sinks ....................................................................................... 8 2.4.1. Defining Media Capability .................................................................... 8 2.4.2. Media IO Components ......................................................................... 9 2.4.3. Track Indications .................................................................................. 9 2.4.4. Removing sources and sinks ............................................................. 10 2.4.5. Channel re-negotiation ....................................................................... 10 2.5. Comm Interface ......................................................................................... 10 2.6. Lip Synchronization ................................................................................... 10 2.7. Extension Interfaces .................................................................................. 11 3. Usage Scenarios ............................................................................................. 11 3.1. Initializing ................................................................................................... 11 3.2. Connecting ................................................................................................. 12 3.3. Adding Data Sources ................................................................................. 14 3.4. Removing Data Sources ............................................................................ 15 3.5. Adding Data Sinks ..................................................................................... 17 3.6. Removing Data Sinks ................................................................................ 19 3.7. Data Sink Removed ................................................................................... 19 3.8. Disconnecting ............................................................................................ 23 3.9. Resetting .................................................................................................... 24 3.10. Complete Call Sequence ........................................................................ 25 4. Proxy Adapter ................................................................................................. 25 5. Logging ............................................................................................................ 26 5.1. Logging incoming/outgoing audio/video data ............................................ 26 6. Feature List ...................................................................................................... 28 6.1. Specification Versions ............................................................................... 28 6.1.1. Normative ........................................................................................... 28 6.1.2. Informative .......................................................................................... 28 7. Supported Features ........................................................................................ 29 7.1. Feature Group 1: H.223 ............................................................................. 29 7.2. Feature Group 2: H.245 ............................................................................. 29 7.3. Feature Group 3: H.324/3G-324M ............................................................ 30 7.4. Feature Group 4: Audio ............................................................................. 31 7.5. Feature Group 5: Video ............................................................................. 31 - Page 2 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

8. References ....................................................................................................... 32 - Page 3 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

List of Figures

Figure 1: High Level Class Diagram...............................................................................................5Figure 2: State Transition Diagram.................................................................................................6Figure 3: Sequence Diagram - Initializing.....................................................................................10Figure 4: Sequence Diagram - Connecting...................................................................................11Figure 5: Sequence Diagram - Adding a Data Source.................................................................13Figure 6: Sequence Diagram – Removing a Data Source............................................................14Figure 7: Sequence Diagram - Adding a Data Sink......................................................................16Figure 8: Sequence Diagram - Removing a Data Sink................................................................17Figure 9: Sequence Diagram - Data Sink Removed.....................................................................18Figure 10: Sequence Diagram - Disconnecting.............................................................................19Figure 11: Sequence Diagram - Resetting....................................................................................20Figure 12: Sequence Diagram - Complete Call Sequence............................................................21

- Page 4 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

1. Introduction

This document is a guide for developers writing clients to the PV2Way SDK. A client of PV2Way can be an application or an adapter layer to adapt PV2Way interface to a higher-level interface used by the application. This document describes how to use PV2Way interface and its extensions to create, configure and control a video telephony session.

PV2Way is a platform-agnostic SDK that provides video telephony capabilities for its clients. The SDK is capable of executing 3G-324M standard video telephony calls. The input media data are typically provided by live source(s) such as camera and microphone. Output media data is forwarded to presentation sinks such as display and speaker. The sources and sinks are provided by the client application.

2. Architecture2.1. Static Design

The following diagram illustrates the major participants in a video telephony session using the PV2Way SDK. A client obtains a reference to the 2way engine (CPV2WayInterface) using either of the factory classes CPV2WayEngineFactory or CPV2WayProxyFactory. The client must also implement PV2Way’s observer interfaces in order to receive command completion, status information and error information. PV2Way is dependent on its client to provide media data sources and sinks for a video telephony session. These media sources and sinks should either be a Media IO Component (MIO) or implement the PVMFNodeInterface (Node) to allow PV2Way Engine to control them in a generic way. A reference to the communications end point is needed by PV2Way to communicate with a peer terminal. This interface acts as the data link to the peer terminal for the video telephony session. Just like media sources and sinks, this can be

implemented either as an MIO or a Node. The Client control of the session is performed through CPV2WayInterface. The figure below shows the relationship between PV2Way, the client, and other objects owned by the client. MIOs are described in detail later in the document.

- Page 5 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 1: High Level Class Diagram

2.2. SDK State Machine Design

PV2Way SDK has 7 states: Idle, Initializing, Setup, Connecting, Connected, Disconnecting, and Resetting. ••

Idle: The state immediately after the PV2Way instance has been successfully created or instantiated. Some optional PV2Way components must be selected in this state.

Initializing: The PV2Way is in this state when it is initializing from the Idle to the Setup state. The terminal queries the available device capabilities (encode, decode, mux),

acquires resources to make a two-way call (codecs, formats, memory etc) and transitions to the Setup state when it will be ready to accept setup parameters and Connect. If initializing fails, the PV2Way relinquishes the resources and reverts to the Idle state. Setup: The state where the PV2Way instance is in the process of receiving setup parameters from the application, for encoding, multiplexing, capturing and rendering.

Each time a new set of parameters is passed in, validation will take place and a status will be returned accordingly.

- Page 6 of 30 -

•

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

•

•

••

Connecting: The state where the PV2Way instance has received a call to start

connecting. The communications end point is also to be provided as part of this process. The PV2Way engine starts communication with the remote terminal to exchange media capabilities and channel configuration in preparation for the establishment of media channels.

Connected: The state after all mandatory control signaling is completed. PV2Way will establish media tracks based on local and remote capabilities and indicate outgoing track establishment to the client, upon which the client is required to provide media sources for these tracks. Similarly, incoming channel notifications will be passed to the client after which the client can add media sinks to associate with particular incoming channels.Disconnecting: The state where the terminal is shutting down all channels and the multiplex.

Resetting: The state where the terminal is releasing all resources and transitioning to the Idle state.

To transition from one state to another, the user will need to call the session control APIs of PV2WayInterface. The figure below illustrates state transition of PV2Way SDK.

Figure 2: State Transition Diagram

2.3. Command Processing

- Page 7 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

The PV2Way SDK exposes functionalities via commands implemented either by the

CPV2WayInterface class or by extension interfaces. The following are some common features of these APIs:

1.Most APIs to the PV2Way SDK are asynchronous. The user is expected to implement an

observer to monitor the status of issued commands.

2.The asynchronous APIs return a unique command id if the request is accepted. 3.The API will leave if there is an error queuing the request.

4.Optional opaque data can be passed in with every asynchronous call to allow the user to

associate arbitrary data/state information with the call.

5.Reference to data structures can be passed in some APIs to allow the user to specify where

the data should be written. The PV2Way SDK will have complete ownership of the reference until the call is completed

6.Once the command is processed, the user is notified via the command observer of the

command id, completion status, the opaque context data and additional opaque data which is to be interpreted based on the command type and the completion status.

7.All pending commands can be cancelled by using the CancelAllCommands API. The

CancelAllCommands command itself cannot be cancelled. Cancelled commands will still return a command completion notification with an indication that it was cancelled.

2.4. Sources and Sinks

PV2Way can handle several types of media sources and sinks and can adapt its internal

configuration based on the types of the sources and sinks, and the time when they are added to the PV2Way.

2.4.1. Defining Media Capability

The user of the SDK should define the scope of the call during initialization. The PV2WayInitInfo class allows the user to advertise the formats and capabilities of available sources and sinks for each incoming and outgoing channel of media that is to be established. The order of formats specifies the preference in decreasing order. For instance, user may define the following:Available outgoing audio formats: {AMR}Available video formats: {Mpeg4, YUV422}Available incoming audio formats: {AMR}

Available incoming video formats: {Mpeg4, YUV420}

These capabilities along with the capabilities of the PV2Way engine (internal codecs, stack) will be used to negotiate the session with the peer. However, it is not guaranteed that the most preferred formats will be negotiated or, that any format will be negotiated at all.

2.4.2. Media IO Components

In PV2Way SDK and PV multimedia framework architecture, the Media IO (MIO) component is a communication layer for the 2way engine to interact with the device’s capturing, rendering and network interfaces. As access to media capturing/rendering & network functionalities are different

- Page 8 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

for every platform that PV software works on, the MIO component serves as a glue layer for different PV modules. In order to act as an adapter between PV modules and underlying hardware interfaces, a MIO component has several responsibilities.

•Control the underlying hardware based on commands from other PV modules. •Exchange capabilities information of the underlying hardware with other PV

modules.

•Send/Receive media data to/from the different underlying hardware interfaces.Several PV2Way engines APIs (CPV2WayInterface) accept a reference to PVMFNodeInterface for sources and sinks (including the COMM interface). Factories that provide a node wrapper for a given MIO are provided in the PV2Way SDK so that the client does not have to adapt to the PVMFNodeInterface, but can simply provide all its adaptations using MIOs. The PVCommsIONodeFactory class creates a node wrapper for the COMM MIO. The

PvmfMediaInputNodeFactory class creates a node wrapper for media input MIOs. The PvmfMediaOutputNodeFactory class creates a node wrapper for the media output MIOs. In the rest of this document, a node is used interchangeably with an MIO in the context of sources, sinks and the comms interface.

Detailed information on Media I/O components can be found in the “Media I/O Developers Guide.”

2.4.3. Track Indications

Media sources and sinks should be added after an indication from PV2Way is received notifying establishment of the track (PVT_INDICATION_OUTGOING_TRACK/

PVT_INDICATION_INCOMING_TRACK). This can happen in the EConnecting and EConnected states. The indications convey the following:

•The port tag associated with the track. The Client is expected to pass in this tag when it calls

AddDataSource/AddDataSink.

•The media type associated with the track

•A PV2WayTrackInfoInterface extension interface, which conveys the format type as a MIME

string, Format Specific Information if any, etc.

The following are the types of sinks/sources supported:

•Raw data sources: These sources output uncompressed data – YUV, PCM etc.

•Compressed data sources: These sources output compressed data – MPEG-4, H.263, AMR.•Raw data sinks: These sinks receive uncompressed data – YUV, PCM etc. The PV2Way

Engine will establish a codec in the datapath to convert the incoming compressed bitstream to a raw type supported by the sink.

•Compressed data sinks: These sinks receive compressed data – MPEG-4, H.263, AMR.

2.4.4. Removing sources and sinks

Sources and sinks added during a call should be removed before disconnecting the call.

- Page 9 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

2.4.5. Channel re-negotiation

If the peer does not support one of our outgoing track formats or if a conflict arises, one or more of the tracks may need to be closed and replaced with tracks agreeable to both sides. As soon as the PV2Way SDK detects this condition, it passes a PVT_INDICATION_CLOSING_TRACK indication to the Client specifying the unique tag for the channel. Subsequently, it closes the track and passes a PVT_INDICATION_CLOSE_TRACK indication. This is illustrated in Section 3.8.

For outgoing channels the Client needs to wait for the PVT_INDICATION_OUTGOING_TRACK indication and then add a compatible source. For incoming channels, the user needs to wait for the PVT_INDICATION_INCOMING_TRACK indication before adding a compatible sink.

2.5. Comm Interface

The Comm Interface represents the data link to the remote video telephony terminal. It typically implements a kbps circuit-switched connection to a serial-port or the baseband of a phone. The PV2Way Engine interfaces to it using an MIO or PVMFNodeInterface. Once the Comm Interface indicates a successful start the PV2Way Engine begins sending and receiving a 3G-324M compliant bitstream with the peer terminal via the Comm Interface. More details on this can be found in Reference 4.

2.6. Lip Synchronization

The strategy for lip synchronization of incoming media is pretty similar to how its handled in the PVPlayer, so only the differences are addressed here.

The pv2way engine will provide timestamped audio and video samples to the Media I/O Components along with a clock just like the PVPlayer case. The active audio rendering MIO would adjust the clock based on the number of samples rendered and the video rendering MIO would pace itself based on the shared clock.

–The pv2way engine would attempt to smoothen the incoming timestamps especially for

audio to reduce jitter. The jitter comes from the fact that the protocol does not support bitstream timestamps. Without bitstream timestamps, the timestamps are based on arrival time and this makes them prone to a lot of jitter.

–The pv2way engine disables buffering/delaying/dropping of audio and video within 2way

datapaths for lip synchronization. Buffering/delaying/dropping decisions are left to the MIOs.

–Incoming skew indication will be forwarded to the application via the

H324MConfigInterface. This provides any inherent skew between the incoming audio and video streams that needs to be compensated for at the time of rendering. This is not very common, but applications need to be able to handle it if the skew is significant.

For outgoing media, the pv2way engine monitors the outgoing audio and video streams for significant skew and if detected, it issues a Skew Indication message to the peer.

2.7. Extension Interfaces

- Page 10 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Extended configuration of the engine for protocol-specific features and for value adds may be acheived using extension interfaces (if they are supported.) This is done using the QueryInterface mechanism.

H.324-specific configuration may be acheived using the H324MConfigInterface. More details may be found in the pv2way engine API document.

3. Usage Scenarios

The following sections illustrate the interactions that happen between the client and the PV2Way components to handle some of the typical commands.

3.1. Initializing

The Init command initializes an instance of PV2Way and acquires all the resources for a video telephony call. The Command Status Observer is notified of the outcomes.

- Page 11 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 3: Sequence Diagram - Initializing

3.2. Connecting

Commanding PV2Way to Connect begins the 3G-324M call setup procedure. The CommNode is used as the network connection to the peer 3G-324M terminal and must therefore be connected to the shared data link once the Start command is returned with a successful result.

- Page 12 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 4: Sequence Diagram - Connecting

- Page 13 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

3.3. Adding Data Sources

The PV2Way Client needs to create media i/o components for source data (audio, video) and provide them to PV2Way via the AddDataSource() method after receiving the

PVT_INDICATION_OUTGOING_TRACK for the channel. Data from these sources would be (optionally) encoded, multiplexed and transmitted to the peer. The PVMFMediaInputNode is used to encapsulate the media i/o components before passing them via the AddDataSource call.

- Page 14 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

The media i/o component is configured using the capability exchange interfaces.

Figure 5: Sequence Diagram - Adding a Data Source

3.4. Removing Data Sources

Data Sources should be removed before disconnecting the call.

- Page 15 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 6: Sequence Diagram – Removing a Data Source

- Page 16 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

3.5. Adding Data Sinks

The PV2Way Client needs to create media i/o components for sink data (audio, video) and provide them to PV2Way via the AddDataSink() method after receiving the

PVT_INDICATION_INDICATION_TRACK for the channel. Incoming media data from the peer would be de-multiplexed, (optionally) decoded and provided to these sinks. The

PVMFMediaOutputNode is used to encapsulate the media i/o components before passing them via the AddDataSink call. The media i/o component is configured using the capability exchange interfaces.

- Page 17 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 7: Sequence Diagram - Adding a Data Sink

3.6. Removing Data Sinks

- Page 18 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Data Sinks should be removed before disconnecting the call..

Figure 8: Sequence Diagram - Removing a Data Sink

3.7. Data Sink Removed

The following events happen when a track is closed by the peer during a video conferencing session.

- Page 19 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 9: Sequence Diagram - Data Sink Removed

3.8. Disconnecting

To terminate a video telephony call, a client needs to call Disconnect after all the Sources and Sinks are removed. This will cause protocol negotiations (EndSessionCommand) with the peer after which the multiplex and the Comms MIO will be stopped.

- Page 20 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 10: Sequence Diagram - Disconnecting

3.9. Resetting

Resetting the PV2Way Engine releases all resources acquired by the SDK. This command must be issued after Disconnect completes and prior to deleting the PV2Way instance.

- Page 21 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Figure 11: Sequence Diagram - Resetting

3.10. Complete Call Sequence

The following is the complete sequence of interactions that happen during a typical video telephony call.

- Page 22 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

- Page 23 of 30 -

Figure 12: Sequence Diagram - Complete Call Sequence

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

4. Proxy Adapter

When building multimedia applications with their requisite complex timing requirements, it is often useful to allocate processing among multiple threads to get some degree of timing independence. Multithreading is a useful tool that simplifies the task of sharing CPU resources among multiple independent components. It is also possible to share processing among components within a single thread using concepts like active objects, which implement a cooperative multitasking model. Cooperative multitasking definitely has its place as another tool that should be utilized to allow complex systems to be built up from simpler components. Either tool on its own will not lead to a good solution for any reasonably complex system, so it’s important to make proper use of each.

PV2Way has an optional Proxy Adapter that may be used to separate the client thread from the PV2Way thread. This separation can be used to ensure that the UI thread can remain responsive to user events and also for protection of time-critical processing within PV2Way. All callbacks (command completion, unsolicited events) will be made in the context of the thread that PV2Way was created. Sources and sinks passed in by the application should have the mechanism and capability to operate (data passing, state change) in a different thread from which it was created. The PV2Way Engine utilizes the Source/Sink ThreadLogon routines to notify external data sources and sinks of the thread contexts for data passing and observer callbacks.

The interface to the client does not change when the Proxy Adapter is in use. This is illustrated in Figure 1.

5. Logging

The 2Way Logging APIs provide methods for the application to control the logging level at any point in the logger tree using hierarchical tags to specify the control point. This will give the

application complete control over the amount of log messages being produced by PV2Way, and by using the hierarchical tags, it provides very fine-grained control to turn up logging just where it is needed.

The application will be able to control the logging destinations by passing in Logger Appender instances that are created externally. Logger Appender classes are provided for most common simple cases such as logging to a file.

5.1. Logging incoming/outgoing audio/video data

Logging data coming in and going out of the PV2Way SDK proves to be useful at times especially in cases where there is large packet loss, data needs to be verified for timing issues, or audio & video data needs to be ascertained for their arrival times for lipsync purposes. An easy way of collecting logs for incoming and outgoing audio & video data is by the use of hierarchical logger. These tags provide the flexibility of restricting the number of log messages by categorizing them for incoming or outgoing audio, video or both kinds of data.Some examples below typify their usage.Logger tag: datapath.outgoing

This tag allows the user to log messages depicting all outgoing multiplexed data, be it audio or video at the stack level.

Following are the sample log messages printed/outputted:

- Page 24 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

PVLOG:TID(0x73c):Time=5656: Outgoing audio frames received. Stats: Entry time=2266, lcn=653, size=2

PVLOG:TID(0x73c):Time=5656: Stats of the outgoing audio SDU are: timestamp=2266, size=31 PVLOG:TID(0x73c):Time=5657: Outgoing video frames received. Stats: Entry time=2286, lcn=652, size=31

PVLOG:TID(0x73c):Time=5656: Stats of the outgoing video SDU are: timestamp=2286, size=2 Logger tag: datapath.outgoing.video.h223.lcn

This tag allows the user to only explicitly log outgoing multiplexed video data at the stack level. Following are the sample log messages printed/outputted:

PVLOG:TID(0x73c):Time=5657: Outgoing video frames received. Stats: Entry time=2286, lcn=652, size=2

PVLOG:TID(0x73c):Time=5656: Stats of the outgoing video SDU are: timestamp=2286, size=2Logger tag: datapath.outgoing.audio.h223.lcn

This tag allows the user to only explicitly log outgoing multiplexed audio data at the stack level.Following are the sample log messages printed/outputted:

PVLOG:TID(0x73c): Time=5657: Outgoing audio frames received. Stats: Entry time=2266, lcn=652, size=31

PVLOG:TID(0x73c):Time=5656: Stats of the outgoing audio SDU are: timestamp=2266, size=31 Logger tag: datapath.incoming

This tag allows the user to log all incoming de-multiplexed data be it audio or video at the stack level.

Following are the sample log messages printed/outputted:

PVLOG:TID(0xb98):Time=5016:Incoming audio SDU received. Stats: Entry time=2016, lcn=652, size=31,FmtType=X-AMR-IF2

PVLOG:TID(0x73c):Time=6141:Incoming video SDU received. Stats: Entry time=2735, lcn=653, size=2,FmtType=video/H263-2000Logger tag: datapath.incoming.video.h223.lcn

This tag allows the user to only log incoming de-multiplexed video data at the stack level. Following are the sample log messages printed/outputted:

PVLOG:TID(0x73c):Time=6062:Incoming video SDU received. Stats: Entry time=2657, lcn=653, size=2,FmtType=video/H263-2000

PVLOG:TID(0x73c):Time=6141:Incoming video SDU received. Stats: Entry time=2735, lcn=653, size=2,FmtType=video/H263-2000

PVLOG:TID(0x73c):Time=6219:Incoming video SDU received. Stats: Entry time=2782, lcn=653, size=2,FmtType=video/H263-2000

- Page 25 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

Logger tag: datapath.incoming.audio.h223.lcn

This tag allows the user to only log incoming de-multiplexed audio data at the stack level.Following are the sample log messages printed/outputted:PVLOG:TID(0xb98):Time=4969:Incoming lcn=652, size=31,FmtType=X-AMR-IF2PVLOG:TID(0xb98):Time=5016:Incoming lcn=652, size=31,FmtType=X-AMR-IF2PVLOG:TID(0xb98):Time=5063:Incoming lcn=652, size=31,FmtType=X-AMR-IF2PVLOG:TID(0xb98):Time=5094:Incoming lcn=652, size=31,FmtType=X-AMR-IF2

audio SDU received. Stats: Entry time=1969, audio SDU received. Stats: Entry time=2016, audio SDU received. Stats: Entry time=2063, audio SDU received. Stats: Entry time=2094,

6. Feature List

The specifications which define the 3G-324M standard present various mandatory and optional elements which may or may not be supported in a particular terminal implementation. The purpose of this section is to provide a feature-level summary of the elements supported by PV2Way 3G-324M solution. Features are classified by feature groups which relate to specific areas of the 3G-324M standard.

In general, features which are listed as supported may be used and/or configured through PV2Way API’s, i.e. no special build time provisions should be necessary to activate such features. For other features (either absent from the list, or listed as “Not Supported”), some customization would be needed in order to add or utilize the feature.

6.1. Specification Versions

This section lists the 3G-324M system specifications and indicates the versions employed by PV2Way.

6.1.1. Normative

••

3GPP TS 26.110 v6.0.0: \"Codec for Circuit Switched Multimedia Telephony Service; General description\".

3GPP TS 26.111 v6.1.0: “Codec for Circuit Switched Multimedia Telephony Service; Modifications to H.324”

ITU-T Recommendation H.324: \"Terminal for low bitrate multimedia communication\February 1998.

ITU-T Recommendation H.223: \"Multiplexing protocol for low bit rate multimedia communication\

••

- Page 26 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

•

ITU-T Recommendation H.223 - Annex A: \"Multiplexing protocol for low bit rate multimedia mobile communication over low error-prone channels\ITU-T Recommendation H.223 - Annex B: \"Multiplexing protocol for low bit rate

multimedia mobile communication over moderate error-prone channels\ITU-T Recommendation H.245, Version 6: \"Control protocol for multimedia communication”, February 2000.

••

6.1.2. Informative

•

3GPP TR 26.911 v6.0.0: \"Codec for circuit switched multimedia telephony service; Terminal Implementor’s Guide\".

7. Supported Features

The features supported by PacketVideo’s 3G-324M solution are broken down into logical feature groups and presented in the following tables.

7.1. Feature Group 1: H.223

GroupH.223H.223H.223H.223H.223H.223H.223H.223H.223#1234567FeatureLevel 0Level 1 (H.223 Annex A)Level 2 (H.223 Annex B)Level 3a (H.223 Annex C)Level 3b (H.223 Annex D)Control over AL1Audio over AL2Video over AL2Video over AL3Support?YesYesYesNoNoYesYesYesYesDirectionIn/OutIn/OutIn/Out----In/OutIn/OutIn/OutIn/OutFramed transfer mode, per H.324 recommendationCRC and Optional SN are both supportedCRC and Optional SN are both supportedSupport for 0, 1 or 2 control field octets. Retransmission not supported (this is in line with the recommendation in 3GPP TS 26.911)CommentSupport for Annex A in single or double flag modes.Support for Annex B with or without optional header. - Page 27 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

7.2. Feature Group 2: H.245

GroupH.245H.245H.245H.245H.245H.245H.245H.245#12345678FeatureTerminal Capability SetMaster Slave DeterminationMultiplex Entry SendRequest Multiplex EntryOpen Logical ChannelRequest Channel CloseEnd SessionRequest ModeSupported?YesYesYesYesYesYesYesNoDirectionIn/OutIn/OutIn/OutIn/OutIn/OutIn/OutIn/Out--Currently no outgoing Mode Requests are sent. Incoming Mode Requests are rejected, consistent for case with no Transmit Capabilities in outgoing TCS. For video case, both unidirectional and bidirectional are supportedCommentH.245H.245H.245H.2459101112H.245H.245H.245H.245H.245H.245H.24513141516171819User Input IndicationRound Trip DelayFlow ControlVideo Spatial/Temporal Tradeoff(Command)Video Fast UpdateMultiplex Reconfiguration(level change)H.223 Skew IndicationVendor Identification IndicationMux PDU size restriction signalingTimer/Counter configurationFast call setupYesYesYesYesIn/OutIn/OutIn/OutIn/OutH.245 signaling support onlyYesNoYesYesYesYesYesIn/Out--In/OutIn/OutIn/Out----Picture update onlyAs recommended in Section 5 of 3GPP TS 26.911.Various H.245 timer and counter values may be configured via APIOptimal standards-compliant bundling of H.245 messages - Page 28 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

to reduce setup time.7.3. Feature Group 3: H.324/3G-324M

GroupH.324H.324H.324H.324H.324H.324H.324H.324H.324#1234567FeatureH.324 Annex CSRPNSRPWNSRPCCSRLAudio ChannelsVideo ChannelsData ChannelsLoopback ModeSupported?YesYesYesYesYesYesYesNoYesDirection--In/OutIn/OutIn/OutIn/OutIn/OutIn/Out----External loopback support provided for development and testing. Multiplex bitstream looped within terminal prior to transmission. H.245 Maintenance loop not currently supported.Option to stop sending A/V data on outgoing side, or to pause rendering of data on incoming side.Standards Based Enhancement for faster Call Setup.CommentMobile annex, as required in 3G-324M specsH.324H.3241011EncryptionPause/ResumeNoYes--In/OutH.32412MONA-MPCOptionalIn/Out7.4. Feature Group 4: Audio

GroupAudioAudio#12FeatureAMR-NBG.723.1Supported?YesNoDirectionIn/Out--CommentAll modes including SIDNot required for 3G-324M7.5. Feature Group 5: Video

GroupVideo#1FeatureH.263 baselineSupported?YesDirectionIn/OutComment - Page 29 of 30 -

PV2Way Developer's Guide

OpenCORE 2.0, rev. 3

VideoVideoVideoVideoVideoVideoVideoVideo234567(Profile 0, Level 10)MPEG-4 Simple ProfileH.261H.263 additional annexesMPEG-4 Resync MarkersMPEG-4 HECMPEG-4 Data PartitioningMPEG-4 RVLC’sError concealmentYesNoNoYesYesYesYesYesIn/Out----In/OutIn/OutIn/OutIn/OutInLevel 0 is baseline support; Could support higher levels as well.Not required for 3G-324MNot required for 3G-324MAs recommended in 3GPP TS 26.911. Advanced error concealment provided by PacketVideo software decoders; this may or may not be available if a non-PV video decoder is used.8. References

1.PacketVideo Corp. PV2Way API Document

2.ITU-T H.324 Terminal For Low Bitrate Multimedia Communication

3.PacketVideo Corp. Media I/O Developers Guide

4.PacketVideo Corp. Guidelines for Developing Baseband Communications IO

Components”.

- Page 30 of 30 -