In v18 the PVR API will be refactored and decoupled from VideoPlayer. For this, it's necessary to remove all the "hacks" of the PVR system that where integrated into VP. This basically affects all playback related parts of the API. The PVR add-ons that implemented a custom demuxer will have to move over to the inputstream API. The add-ons that relied on the "streamUrl" function (which is now gone) will be provided with a new alternative. How this alternative will look like is in your hands now. Please use this thread to discuss ideas how this API could look like and which infos you need to pass to Kodi for your PVR add-on to work, so that Kodi can create a suiteable fileItem that will be forwarded to videoplayer and get handled by the according component (like inputstream.adaptive if needed).
For more details read from page 4 and up here
https://forum.kodi.tv/showthread.php?tid=259830
Happy discussion
PS: to temporarily fix your broken PVR add-on until the new API is in place,read
https://forum.kodi.tv/showthread.php?tid...pid2623844
Well I'll try a first start. To create a file item, I think the following information is required from the PVR addon (this holds for recordings, live-tv and replay):
- URL of the item
- Properties to be set on the file item
All the remaining information can be taken from the channel/recording/epg entry.
Something like this could be used:
For Live-TV:
PVR_ERROR GetLiveStreamUrl(channel, out url, out propertyMap);
For Recordings:
PVR_ERROR GetRecordingUrl(recording, out url, out propertyMap);
and in case we handle Replay separate from recordigns:
PVR_ERROR GetEpgTagUrl(epgTag, out url, out propertyMap);
@
FernetMenta If OpenLiveStream, OpenRecordedStream and their fellow calls are going to be removed from the new PVR class, is it enough to implement their counterparts from CInstanceInputStream and leave the Demux functions alone/stub/unimplemented?
For more clarity: There are at least 3 PVRs (including mine) which support local timeshifting by reading the stream on its own.
(2017-07-28, 13:07)rbuehlma Wrote: [ -> ]Something like this could be used:
For Live-TV:
PVR_ERROR GetLiveStreamUrl(channel, out url, out propertyMap);
For Recordings:
PVR_ERROR GetRecordingUrl(recording, out url, out propertyMap);
and in case we handle Replay separate from recordigns:
PVR_ERROR GetEpgTagUrl(epgTag, out url, out propertyMap);
Yeah, that basically would do the job, imo.
The function for TV should not have "Live" in its name, though, as it can also provide an url for a non-live stream (time shifting).
Not sure we need the epg tag url function. Don't want to pull this functional enhancement (replay) into this discussion, tbh. I suggest for now to concentrate on what we have before discussing new functionality.
For recordings, PVR_RECORDING.strRecordingUrl would be removed in favour of the new function, which provides more flexibility and is aligned with new tv concept, then.
Just one question regarding properties: what properties are needed and what will Kodi do with them after retrieval from the add-on? This is not clear to me.
(2017-07-28, 18:56)ksooo Wrote: [ -> ] (2017-07-28, 13:07)rbuehlma Wrote: [ -> ]Something like this could be used:
For Live-TV:
PVR_ERROR GetLiveStreamUrl(channel, out url, out propertyMap);
For Recordings:
PVR_ERROR GetRecordingUrl(recording, out url, out propertyMap);
and in case we handle Replay separate from recordigns:
PVR_ERROR GetEpgTagUrl(epgTag, out url, out propertyMap);
Yeah, that basically would do the job, imo.
The function for TV should not have "Live" in its name, though, as it can also provide an url for a non-live stream (time shifting).
Yeah, at least for zattoo that sounds interesting... opening a time-shift stream based on time instead of an epg entry. But I guess we would need there an additional parameter.
PVR_ERROR GetChannelStreamUrl(channel, timeShiftOffset, out url, out propertyMap);
(2017-07-28, 18:56)ksooo Wrote: [ -> ]Not sure we need the epg tag url function. Don't want to pull this functional enhancement (replay) into this discussion, tbh. I suggest for now to concentrate on what we have before discussing new functionality.
Agree on that.
(2017-07-28, 18:56)ksooo Wrote: [ -> ]For recordings, PVR_RECORDING.strRecordingUrl would be removed in favour of the new function, which provides more flexibility and is aligned with new tv concept, then.
Just one question regarding properties: what properties are needed and what will Kodi do with them after retrieval from the add-on? This is not clear to me.
The properties are used by some inputstream addons (at least adaptive) to determine on how to process the stream. Also the addon is selected using these properties. Maybe there are even more usecases I do not know of.
@
rbuehlma, what about
PVR_ERROR GetStreamUrl(epgTag, timeShiftOffset, out url, out propertyMap);
The EPG tag contains the channel info as welll, doesn't it? So by always using an EPGtag (a dummy one if no EPG info is available for a channel) it would allow the PVR add-on to return either a timeshift buffer URL, live stream URL a recording or replay/on demand URL.
Alternatively the return value could be an array/vector/etc which contains the available stream types and their URLs (live, recording, on demand) and in case there are several, Kodi could provide a select dialog. Just an idea from an outsider - not sure if it's feasable
When you guys mention URL will that also allow an smb path to a file which is Kodi will then open and play?
For pvr.wmc we will normally point Kodi at a file over smb (which will be WTV format mpeg2 or mp4 depending on tuner source) or a url (eg from a HDHomeRun)
Currently we use XBMC.OpenFile for the smb paths or populate the streamUrl property for the streams
(2017-07-29, 00:27)da-anda Wrote: [ -> ]@rbuehlma, what about
PVR_ERROR GetStreamUrl(epgTag, timeShiftOffset, out url, out propertyMap);
The EPG tag contains the channel info as welll, doesn't it? So by always using an EPGtag (a dummy one if no EPG info is available for a channel) it would allow the PVR add-on to return either a timeshift buffer URL, live stream URL a recording or replay/on demand URL.
Alternatively the return value could be an array/vector/etc which contains the available stream types and their URLs (live, recording, on demand) and in case there are several, Kodi could provide a select dialog. Just an idea from an outsider - not sure if it's feasable
I'm not sure if the epg tag is required. If we have the channel and the offset, it should be possible for the addon to determine the epgTag. What is your opinion @
ksooo and @
FernetMenta?
Would this API:
PVR_ERROR GetChannelStreamUrl(channel, timeShiftOffset, out url, out propertyMap);
PVR_ERROR GetRecordingUrl(recording, out url, out propertyMap);
a good way to go? If timeShiftOffset is 0, the addon would deliver a url to the live stream. Else, it would deliver the stream starting from the requested position. If the Replay button is used in Kodi (or by selecting an EPG entry), Kodi would set the corresponding offset.
If yes, could anyone of you translate them into a C-API for me? I'm not really used to C/C++ and am not sure of the proper format for this API
@
scarecrow420 yes, and URL can be anything Kodi can play.
(2017-07-29, 15:48)rbuehlma Wrote: [ -> ] (2017-07-29, 00:27)da-anda Wrote: [ -> ]@rbuehlma, what about
PVR_ERROR GetStreamUrl(epgTag, timeShiftOffset, out url, out propertyMap);
The EPG tag contains the channel info as welll, doesn't it? So by always using an EPGtag (a dummy one if no EPG info is available for a channel) it would allow the PVR add-on to return either a timeshift buffer URL, live stream URL a recording or replay/on demand URL.
Alternatively the return value could be an array/vector/etc which contains the available stream types and their URLs (live, recording, on demand) and in case there are several, Kodi could provide a select dialog. Just an idea from an outsider - not sure if it's feasable
I'm not sure if the epg tag is required. If we have the channel and the offset, it should be possible for the addon to determine the epgTag. What is your opinion @ksooo and @FernetMenta?
Would this API:
PVR_ERROR GetChannelStreamUrl(channel, timeShiftOffset, out url, out propertyMap);
PVR_ERROR GetRecordingUrl(recording, out url, out propertyMap);
a good way to go? If timeShiftOffset is 0, the addon would deliver a url to the live stream. Else, it would deliver the stream starting from the requested position. If the Replay button is used in Kodi (or by selecting an EPG entry), Kodi would set the corresponding offset.
If yes, could anyone of you translate them into a C-API for me? I'm not really used to C/C++ and am not sure of the proper format for this API
@scarecrow420 yes, and URL can be anything Kodi can play.
I don't think it makes sense to mix in the timeshift stuff here. Stream offsets imo always should be accessed via "seek" calls after "open". Putting many different aspects into one api call makes things more complex without any real need.
What do you think about this API for live stream URLs?
Code:
/*!
* Get the stream URL for a channel from the backend. Used by the MediaPortal add-on.
* @param channel The channel to get the stream URL for.
* @param[out] url The stream url
* @param[out] urlLen The length of the url buffer, out: the length of the returned url
* @param[out] properties List of properties required to play the stream
* @param[out] propertiesCount Size of properties buffer, out: the number of properties returned
* @return PVR_ERROR_NO_ERROR if the stream is available
* @remarks Optional, and only used if bHandlesInputStream is set to true. Return NULL if this add-on won't provide this function.
*/
PVR_ERROR GetLiveStreamURL(const PVR_CHANNEL& channel, char* url, int* urlLen, PVR_FILE_ITEM_PROPERTY* properties, int* propertiesCount);
Code:
/*!
* @brief Representation of a file item property
*/
typedef struct PVR_FILE_ITEM_PROPERTY {
char strName[PVR_ADDON_NAME_STRING_LENGTH]; /*!< @brief (required) name of property. */
char strValue[PVR_ADDON_NAME_STRING_LENGTH]; /*!< @brief (required) value of property */
} ATTRIBUTE_PACKED PVR_FILE_ITEM_PROPERTY;