Transcoded Live TV support

[emveepee]

Play backend transcoded m3u8 files using the GetChannelStreamProperties() interface

[emveepee]

@phunkyfish could you please review the GetChannelStreamProperties() code https://github.com/emveepee/pvr.nextpvr/blob/live-transcoding/src/pvrclient-nextpvr.cpp#L997 Is this is the proper way to open an m3u8 URL with your recent changes? Also do you know if is there a way to have a seekable m3u8 file for LiveTV? I mark it real time for know but perhaps this can be improved.

Thanks

[phunkyfish]

You'll need to more specific on recent changes? Sorry a little jet lagged ;)

Do you mean:

1. Passing an m3u8 to kodi's internal libavformat?
2. Playing LiveTv from an EPG tag?
3. Or the (very) new inputstream?

Maybe just describe what it is you want to do.

For the new inputstream the hope is to extend it down the line to support timeshift. Right now it can only support pseudo-timeshift on streams that support catchup.

[emveepee]

You'll need to more specific on recent changes? Sorry a little jet lagged ;)

The NextPVR backend uses HLS m3u8 as the format for server-side transcoded streaming. Direct play is working fine with mpegts format but I wanted the addon to support both methods and I don't want to incorporate a full m3u8 reader.

I original hoped to open an inputstream to the m3u8 file in OpenLiveStream() in real time play but I could not figure out how I could tell Kodi to reload the m3u8 file as it grew and read the new ts streams

What I have done and is working, with limitations, is switching modes to use GetChannelStreamProperties() to stream m3u8 files. The link I pointed to is the link I provided is the code for creating the real time link. My question was whether or not it would be possible to tell the video player through GetChannelStreamProperties() that the m3u8 file was seekable?

Regarding limitations, it looks like GetChannelStreamProperties() blocks the UI thread so I can't display any messages to the user during the preparation time that is required for the m3u8 to be ready. Not only that the mouse and key board are unresponsive.

The other limitation is on a channel switch without stop Kodi continues to request the original m3u8 file after the switch is requested and since the addon needs to prepare the same URL for the new channel, the backend gets confused on the request.

[phunkyfish]

Got you. Then what you have now is the best that can be done currently.

Once I get around to extending the new inputstream addon to support timeshift (if it’s possible) you could potentially use that down the line.

[emveepee]

Once I get around to extending the new inputstream addon to support timeshift (if it’s possible) you could potentially use that down the line.

OK great I will be happy to help you test that, this PR code is really best using OpenLiveStream() and it would probably fix both issues too.

[emveepee]

@phunkyfish if we move to inputstream.ffmpegdirect can an m3u8 file be called from OpenLiveStream() or still from GetChannelStreamProperties? Also NextPVR m3u8 files are seekable but the time base is the beginning of the m3u8 file which is not the same as any start time. How do we mark these URL's seekable? Thanks for the work on this.

[phunkyfish]

Everything with an inputstream addon is via GetChannelStreamProperties and GetEPGTagStreamProperties. There is no notion of OpenLiveStream but I would like to add callbacks so the PVR addons can be notified if a stream is opened successfully and when it's closed. Moving away from OpenLiveStream() and PVR addons internal demuxers is important as that limits PVR to one stream at a time meaning concepts like Picture in Picture etc. are not a possibility.

Right now if you just hook up the new addon as is and just pass a stream URL you should get the same as what kodi gives you, playback with no ability to seek. If you use catchup mode then you can tell the addon about the beginning of the catchup window, end etc. and then the URL is modified to support seeking (essentially a SEEK_SET from video player). The format of the catchup URL is entirely up to you.

For example: http://mysite.com/streamX?cutv={Y}-{m}-{d}T{H}:{M}:{S} Just lets you set the Year, Month, Day, Hour, Minute and seconds where to play from.

Similarly: http://mysite.com/streamX?cutv={utv} Just lets you set the utc timestamp where to start playback from.

Similarly: http://mysite.com/streamX?cutv={S} Just lets you set the seconds where to start playback from.

It's pretty flexible and should work for almost any backend I think. Does this fit you use case?

BTW, there is a good chance you will find some issues with the new addon, it could use some field testing ;)

[emveepee]

Our current use case is seekable m3u8 files. Live TV needs to handle long playback time, perhaps all day, with transitions from show to show, I am not sure if that is in the catchup use case. As a result, after a client determined buffer time when new ts files are queued to the playlist the earlier ts files will be dequeued so our start "time" is not fixed. Hopefully that is not an issue.

I do like the idea of Open and Close callback. I see Open more than a simple notification, GetChannelStreamProperties() is blocking and stalls Kodi quite hard so I would like to see the Open call fix that Open could signal back to you that the backend is ready for streaming. I takes time for the backend to generate that first ts file in the playlist, which is different then the IPTV model.

Also currently when a user requests a channel change, GetChannelStreamProperties is called but at the same time Kodi continues to try and stream the "dead" m3u8 file. Hopefully Close and Open can fix that.

What would be nice is a callback telling us that the inputstream is streaming which we need send for keepalives. I use SignalStatus for that but it is not PIP aware either and it would not be my first choice. Something like IsRealtime and the (removed) IsTimeshifting callback would make sense.

I will make the changes to use your new method and certainly the small number of users using the new feature can help test this for both of us.

[phunkyfish]

Cool, so currently catch up uses a moving window for Live TV. I.e it's 3 days and moves as time progresses. What you are saying is that you start and then the end time increases but start time can stay the same? If so this is a reasonable extension of the addon that makes sense.

We also plan to extend the the inputstream so you can send updated stream properties as well as the callbacks. That should solve for the dead M3U8 file problem I think.

Really where we want to get to is that any logic related to seeking the stream is generic and in the inputstream addon and then occasionally we send the inputstream addon some extra information for any actions it needs to take (such as keep alives or new programme information, durations etc). But really the end goal is to be able to move any complex inputstream mgmt to the new addon and make the PVR addons simpler (hopefully!).

[emveepee]

For start time it depends on which time you are meaning. In the PVR world we have ptsStart and also ptsBegin and ptsBegin is the important one because it limits the scroll back and they can diverge.

In an m3u8 using EXTINF,1 as an example the m3u8 file might start off 1.ts, 2.ts etc but eventually the first file of m3u8 will be 2.ts then 3.ts etc so the earliest point a user could seek does change.

I have reservations of channel changes being property changes but I will wait and see how that works.

[phunkyfish]

So all the ptsStart, ptsEnd etc move to the inputstream addon. You simply construct a start URL and a URL with placeholders (used for seeking) to the addon. These time based placeholders get updated on each seek. The logic we would be missing would be on how the seek window logic gets updated, I.e. the equivalent of GetStreamTimes().

Channel changes on property updates would be optional. You can leverage them or not depending on your use case.

[emveepee]

It's a fairly minor thing, but I do wonder if it should have used "profile" instead of "resolution" for the wording, since it'd more closely match the meaning and naming used in the NextPVR backend? If it says 'resolution' some users will probably wonder 'where do I control the bitrate?'.

Makes sense I will change it to match the backend and I maybe it can be expanded upon if we move to v19 style xml setting. The mix and match of v4 and v5 settings is already a bit confusing and I'd like to rework it.