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