Skip to main content

PAT and PMT filtering in HN player

  6 posts   Feedicon  
Replies: 5 - Last Post: June 28, 2012 22:43
by: mkorzen
showing 1 - 6 of 6
Posted: May 07, 2012 06:58 by sifysify
Is it mandatory for the native HN player implementation to send PAT and PMT updates to RI Java? If so, will RI JAVA start the playback only after receiving PAT and PMT. Can the player start the playback without sending PAT and PMT updates?

In which format is RI Java expecting PAT and PMT data from the native HN player implementation. Any pointers are appreciated.

Thanks
SR
Posted: May 08, 2012 01:34 by mkorzen
> Is it mandatory for the native HN player implementation to send PAT and PMT updates to RI Java?
Yes.

> If so, will RI JAVA start the playback only after receiving PAT and PMT.
RI Java iniatiates playback in 2 steps:
1. First streaming request sent to the server is used for PAT/PMT acquisition to find the A/V pids of the incoming stream.
2. Second streaming request is used for actual video decoding with the PID settings obtained in (1). However, if the streaming request is for an in-progress recording or live streaming (as determined via s0 increasing DLNA protocol info flags), RI Java will not stop first session/start second session. Instead, it will call mpeos_hnPlayerPlaybackChangePIDs() on the existing HN playback session.
The answer to the question is therefore: Yes.

> Can the player start the playback without sending PAT and PMT updates?
No.

> In which format is RI Java expecting PAT and PMT data from the native HN player implementation. Any pointers are appreciated.
Standard secion filtering format as defined/spec'd in mpeos_filter.h. See mpe_FilterSourceType: MPE_FILTER_SOURCE_HN_STREAM.

Hope this helps -
Marcin
Posted: May 08, 2012 18:14 by vgseac
Hi Marcin,

Is MPEOS HN expected to setup the filters using mpeos_filterSetFilter(), or will the filter setup be invoked from Java as part of HN playback?

Can you please point to the reference MPEOS HN implementation that does the above, or describe in more detail how the PAT/PMT filtering is setup during HN playback including the applicable API calls and sequence?

Posted: May 08, 2012 21:22 by mkorzen
The filter set-up is performed by the SI Manager here:
https://community.cablelabs.com/svn/OCAPRI/trunk/ri/RI_Stack/mpe/mgr/simgr/

It is NOT a responsibility of MPEOS implementation to perform HN section filter set-up.

Slide 138 from the following, recent training presentation shows a sequence diagram for HN DMP RemoteService selection:
https://community.cablelabs.com/svn/OCAPRI/support_files/opensource_documents/Project%20Documentation/RI%20Training%20March-2012.ppt

Hope this helps -
Marcin
Posted: June 12, 2012 16:39 by nshahsc
Hi Marcin,

Slide 138 of the training presentation has API flow little different than what you described above in Post#2.

Let me understand the behavior again from this thread. Please correct me if it's not accurate:

1. RI Java calls "mpeos_hnStreamOpen" first to open the stream. --> This will only allocate resources and it will not initiate any stream request to the server.
2. RI Java calls "mpeos_hnPlaybackStart" to start the playback with "avStreamParameters=NULL". --> mpeos_hn should now start reqesting a stream from the server but should not start any Decoding and Presentation yet.
3. SI Manager calls "mpeos_filterSetFilter" with "mpe_FilterSourceType: MPE_FILTER_SOURCE_HN_STREAM" and source:mpe_FilterSource_HN_STREAM as "hn_stream_session" provided by mpeos_hn in step 1. --> mpeos_filter should now initiate a section filtering from that "uri" source and return all the sections matched.

For Completed recordings:
4a. RI Java calls "mpeos_hnPlaybackStop". --> mpeos_hn should stop the playback started in step 2.
5a. RI Java calls "mpeos_hnPlaybackStart" again to start the actual playback with the correct A/V pids. --> mpeos_hn should now start the Decoding and Presentation.

For In-Progress recordings or live-streaming:
4b. RI Java calls "mpeos_hnPlayerPlaybackChangePIDs". --> mpeos_hn should restart Decoding and Presentation with the new A/V pids.

Questions:

1. I read the following comment in API description:
stack to communicate to the underlying HN player implementation
* a set of A/V PIDs which have been either:
* - Extracted from the incoming MPEG-2 transport stream via SI HN PAT/PMT
* discovery process, or
* - Sent by the remote HN server using the optional AVStreamParameters HTTP
* header. Refer to OC-SP-HNP2.0, section 5.6.1.9 for more details.

Question: --> If that's the case, RI Java may not call this API with "avStreamParameters" NULL ? OR does RI Java call "mpeos_hnPlaybackStart" first time with NULL "avStreamParameters" and call ""mpeos_filterSetFilter" always ? Is above comment true ? If yes, then why does RI Java need to wait for the actual playback to start ? Playback can start as soon as Pids are received from http response and parallel it can setup the filter for a dynamic pid changes. Please confirm the behaviour.

2. I read the following comment in API descrption:
the platform can determine components when none are specified (e.g. via AVStreamParameters), it may use those components to perform presentation until a call to mpeos_hnPlaybackChangePIDs() is made which specified component PIDs.
--> Is that true ?

3. Just curious. Do you know what is the reason to keep behaviors different for "complete recordings" and in-progress or live-streaming ? Meaning former case, it stops/restarts the playback and in latter case, it calls "mpeos_hnPlayerPlaybackChangePIDs". Why not always Stop/restart ? This way, platform can have a lesser complexity.

Appreciate your help.
Posted: June 28, 2012 22:43 by mkorzen
1. Technically speaking mpe_HnHttpHeaderAVStreamParameters can never be NULL since the structure is embedded inside the mpe_HnPlaybackParamsMediaPlayerHttp structure, and it is not referenced as a pointer. So the proper way to indicate NULL/default audio/video PIDs is to use 0xFFFF values - which is documented in the structure comment:
 * To specify default video and audio PIDs, a value of 0xFFFF will be used.


The RI needs playback to start in order to get the transport stream bits flowing through the demux/decoder. Only then the section filters can be enabled to produce matching results. If you set filters without starting the playback then you have no data flowing through the hardware and no matches could ever be produced.

You are correct in that the playback can start as soon as PIDs are received from HTTP response. The following API description clarifies it:
 * If
 * the platform can determine components when none are specified (e.g. via
 * AVStreamParameters), it may use those components to perform presentation
 * until a call to mpeos_hnPlaybackChangePIDs() is made which specifies
 * component PIDs.


2. Yes.

3. This is mostly to make the user experience as best as possible for each type of content.
In-progress recordings and live streaming have dynamic content so loosing a few seconds of viewing time after initial time is probably not that crucial since the content is changing/shifting anyway. Hence the changing of PIDs on the fly without a restart.
However, when you have a completed recording, the RI makes an effort to show it from the beginning (content is not dynamic) - that's why it will call stop/start - to assure that the playback starts from the absolute beginning.

Hope this helps -
Marcin
showing 1 - 6 of 6
Replies: 5 - Last Post: June 28, 2012 22:43
by: mkorzen
 
 
Close
loading
Please Confirm
Close