JMF Players and Processors provide the presentation, capture, and data conversion mechanisms for RTP streams.
JMF播放器與處理機提供了畫面呈現、擷取與RTP串流的資料轉換裝置。
A separate player is used for each stream received by the session manager.
You construct a Player for an RTP stream through the standard Manager createPlayer mechanism.
You can either:
每個被接收的串流使用個別的播放器都要靠session manager
你要建構一個透過標準Manager createPlayer轉換的RTP串流播放器，可以試著：
• Use a MediaLocator that has the parameters of the RTP session and construct a Player by calling Manager.
createPlayer(MediaLocator)
• Construct a Player for a particular ReceiveStream by retrieving the DataSource from the stream and passing it to Manager.
createPlayer(DataSource).
使用一個有RTP session的MediaLocator參數且藉著呼叫Manager建構一個播放器
給特定的ReceiveStream建構一個藉由重新取得資料來源串流且通過Manager的播放器
If you use a MediaLocator to construct a Player, you can only present the first RTP stream that’s detected in the session.
If you want to play back multiple RTP streams in a session, you need to use the SessionManager directly and construct a Player for each ReceiveStream.
如果你用MediaLocator去建構一個播放器，你可以只呈現第一個在session偵測到的RTP串流。
如果你要錄音再重放多個session裡的RTP串流，你需要立即用到SessionManager且為每個ReceiveStream建構播放器。
Creating a Player for an RTP Session
為RTP Session創造一個播放器
When you use a MediaLocator to construct a Player for an RTP session, the Manager creates a Player for the first stream detected in the session.
This Player posts a RealizeCompleteEvent once data has been detected in the session.
當你用MediaLocator去建構一個RTP session播放器的時候，Manager會為第一個偵測到的串流創造一個播放器。
這個播放器公佈了在session裡頭曾被偵測過的RealizeCompleteEvent資料。
By listening for the RealizeCompleteEvent, you can determine whether or not any data has arrived and if the Player is capable of presenting any data.
Once the Player posts this event, you can retrieve its visual and control components.
藉由RealizeCompleteEvent的傾聽，你可以決定否有任何資料抵達並且當此播放器是可以呈現任何資料的。
當播放器發佈一次本事件時，你可以重新取回他的可見與控制元件。
Note: Because a Player for an RTP media stream doesn’t finish realizing until data is detected in the session, you shouldn’t try to use Manager.
createRealizedPlayer to construct a Player for an RTP media stream. No Player would be returned until data arrives and if no data is detected, attempting to create a Realized Player would block indefinitely.
注意：因為RTP媒體串流格式的播放器無法完成實體化，除非在此session裡頭資料是已經被偵測到的，你應該試著去用Manager.createRealizedPlayer來建構一個RTP媒體串流的播放器。
沒有播放器會被傳回除非資料抵達時沒有資料被偵測到，而試圖去創一個實體播放器的話應該會碰到非預期的阻礙。
A Player can export one RTP-specific control, RTPControl , which provides overall session statistics and can be used for registering dynamic payloads with the SessionManager.
播放器可以輸出一個RTP指定的控制碼（RTPControl），那個提供整體的session統計資料就可以被用來當作是SessionManager的動態暫存承載。
Listening for Format Changes
格式改變的傾聽
When a Player posts a FormatChangeEvent, it might indicate that a payload change has occurred.
Players constructed with a MediaLocator automatically process payload changes.
In most cases, this processing involves constructing a new Player to handle the new format.
Applications that present RTP media streams need to listen for FormatChangeEvents so that they can respond if a new Player is created.
當播放器發佈FormatChangeEvent時，他可能會指示那個承載產生改變。
播放器自動的建構了一個MediaLocator來處理承載的改變。
在主要的案子中，這個處理過程包含了建構一個新的播放器去操作那新的格式。
應用那個呈現RTP媒體串流需要去傾聽FormatChangeEvents為了他們那些當一個新的播放器被創時以至於可以回應。
When a FormatChangeEvent is posted, check whether or not the Player object’s control and visual components have changed.
If they have, a new Player has been constructed and you need to remove references to the old Player object’s components and get the new Player object’s components.
當一個FormatChangeEvent被發佈時，無論播放器物件的控制或可見元件都要檢查是否有被改過
有的話，一個新的播放器將會被建構且還需要去移除參照到舊的播放器物件的元件然後得到新的播放器物件的元件。
Creating an RTP Player for Each New Receive Stream
創造一個RTP播放器給每個新的接收串流
To play all of the ReceiveStreams in a session, you need to create a separate Player for each stream. When a new stream is created, the session manager posts a NewReceiveStreamEvent. Generally, you register as a ReceiveStreamListener and construct a Player for each new ReceiveStream. To construct the Player, you retrieve the DataSource from the ReceiveStream and pass it to Manager.createPlayer.
為了在一個session裡面播放全部的ReceiveStreams，你需要一一去開播放器給每個串流。
當一個新的串流被開啟時，session manager會公佈NewReceiveStreamEvent。
通常，你暫存成一個ReceiveStreamListener且一一建構播放器給每個新的ReceiveStream。
為了建構播放器，你從ReceiveStream存取DataSource而且把他傳到Manager.createPlayer。
To create a Player for each new receive stream in a session:
在session裡頭一一開播放器給每個新的接收串流
1. Set up the RTP session:
設立RTP session
a. Create a SessionManager. For example, construct an instance of com.sun.media.rtp.RTPSessionMgr.
(RTPSessionMgr is an implementation of SessionManager provided with the JMF reference implementation.)
開一個SessionManager。就像是建構一個com.sun.media.rtp.RTPSessionMgr的實例。
（RTPSessionMgr工具是SessionManager提供來參考JMF的工具）
b. Call RTPSessionMgr addReceiveStreamListener to register as a listener.
呼叫RTPSessionMgr addReceiveStreamListener到暫存當傾聽者。
c. Initialize the RTP session by calling RTPSessionMgr initSession.
藉著呼叫RTPSessionMgr initSession來初始化RTP session
d. Start the RTP session by calling RTPSessionMgr startSession.
藉著呼叫RTPSessionMgr startSession來啟動RTP session
2. In your ReceiveStreamListener update method, watch for NewReceiveStreamEvent, which indicates that a new data stream has been detected.
在你的ReceiveStreamListener更新方法裡面，等待NewReceiveStreamEvent，表示新的資料串流有要被偵測
3. When a NewReceiveStreamEvent is detected, retrieve the ReceiveStream from the NewReceiveStreamEvent by calling getReceiveStream.
當NewReceiveStreamEvent被偵測到了，藉由呼叫getReceiveStream從NewReceiveStreamEvent重新取得ReceiveStream。
4. Retrieve the RTP DataSource from the ReceiveStream by calling getDataSource. This is a PushBufferDataSource with an RTP-specific Format. For example, the encoding for a DVI audio player will be DVI_RTP.
藉由呼叫getDataSource從ReceiveStream重新取得RTP DataSource。這是一個PushBufferDataSource跟RTP特定的格式。就像是編譯過的DVI聲音播放器會成為DVI_RTP。
5. Pass the DataSource to Manager.createPlayer to construct a Player. For the Player to be successfully constructed, the necessary plug-ins for decoding and depacketizing the RTP-formatted data must be available.
經過DataSource到Manager.createPlayer而建構一個播放器。為了成功的建構播放器，必要用外掛來為了編譯與有效的包裝RTP格式的資料。
Handling RTP Payload Changes
處理RTP承載的改變
If the payload of a stream in the RTP session changes, the ReceiveStream posts a RemotePayloadChangeEvent. Generally, when the payload changes, the existing Player will not be able to handle the new format and JMF will throw an error if you attempt to present the new payload. To avoid this, your ReceiveStreamListener needs to watch for RemotePayloadChangeEvents. When a RemotePayloadChangeEvent is detected, you need to:
如果串流在RTP session的承載裡改變了，ReceiveStream會公佈一個RemotePayloadChangeEvent。
通常呢，當承載起了變化，現行的播放器將不能去處理新的格式且JMF將會在你試圖去呈現那新的承載時丟出錯誤訊息。
1. Close the existing Player.
2. Remove all listeners for the removed Player.
3. Create a new Player with the same RTP DataSource.
4. Get the visual and control Components for the new Player.
5. Add the necessary listeners to the new Player.
關閉使用中的播放器
為那被移除的播放器移除全部的傾聽者
給相同的RTP DataSource開一個新的播放器
給新的播放器取得可視及控制元件
增加必要的傾聽者去給新的播放器
Controlling Buffering of Incoming RTP Streams
控制進來的RTP串流緩衝區
You can control the RTP receiver buffer through the BufferControl exported by the SessionManager. This control enables you to set two parameters, buffer length and threshold.
你可以控制RTP接收者的緩衝經由BufferControl藉著SessionManager輸出。這項控制使你要去設立兩個參數，緩衝區的長度跟門檻。
The buffer length is the size of the buffer maintained by the receiver.
The threshold is the minimum amount of data that is to be buffered by the control before pushing data out or allowing data to be pulled out (jitter buffer).
Data will only be available from this object when this minimum threshold has been reached. If the amount of data buffered falls below this threshold, data will again be buffered until the threshold is reached.
緩衝區的長度大小是依據保持在接收者的緩衝區大小。
門檻的最低限度相當於是資料在藉著控制之前的推進資料或允取資料被拉出的緩衝區
資料只能在這個物件的極小值門檻有達到的話才可以用。
如果資料的緩衝大小降到門檻以下，資料將再次的被緩衝直到抵達門檻。
The buffer length and threshold values are specified in milliseconds. The number of audio packets or video frames buffered depends on the format of the incoming stream. Each receive stream maintains its own default and maximum values for both the buffer length and minimum threshold. (The default and maximum buffer lengths are implementation dependent.)
緩衝區的長度跟門檻值是定在毫秒為單位。聲音或影像訊框的緩衝值依靠進入串流的格式。每個接收串流維持他自己的預設值而且最大值給定為長度跟門檻的總和。（預設值與緩衝長度的最大值是工具的依靠）
To get the BufferControl for a session, you call getControl on the SessionManager. You can retrieve a GUI Component for the BufferControl by calling getControlComponent.
把BufferControl給session，你在SessionManager呼叫getControl。你可以藉由呼叫getControlComponent來給BufferControl重新取得一個GUI的元件。
Presenting RTP Streams with RTPSocket
呈現RTP串流與RTPSocket
RTP is transport-protocol independent. By using RTPSocket, you can stream RTP from any underlying network.
The format of the RTP socket is designed to have both a data and a control channel.
Each channel has an input and output stream to stream data into and out of the underlying network.
RTP是個獨立的傳輸協定。藉由使用RTPSocket，你可以串流RTP從任何的基層網路。
RTPSocket的格式是設計成有資料和控制通道。
每個通道有一個輸入和輸出的串流用來去串流資料進入與離開基層網路。
SessionManager expects to receive individual RTP packets from the RTPSocket. Users are responsible for streaming individual RTP packets to the RTPSocket.
SessionManager期望從RTPSocket去接收特別的RTP封包。使用者負責去串流獨特的RTP封包給RTPSocket
To play an RTP stream from the RTPSocket, you pass the socket to Manager.createPlayer to construct the Player. Alternatively, you could construct a Player by calling createPlayer(MediaLocator) and passing in a MediaLocator with a new protocol that is a variant of RTP, “rtpraw”. For example:
從RTPSocket播放一個RTP串流，你透過socker到Manager.createPlayer來建構播放者。
二選一的話，你可以呼叫createPlayer(MediaLocator)來建構一個播放者且透過MediaLocator與一個新的跟RTP有差異的協定，『rtpraw』，就像是：
Manager.createPlayer(new MediaLocator("rtpraw://"));
沒有留言:
張貼留言