DVDDemuxPVRClient vs timeshift
#16
@adamsutton: the dvdplayer changes are only used to prevent pausing and seeking when the PVR addon reports that it is not supported.
The situation before was that all commands to seek/pause were blocked at the application level and in the skin (which was also seen as a hack).
Your change is indeed a missing piece for the current timeshift support.

The change in the DVDPlayer is needed to support also the timeshift case were XBMC is just playing a stream like RTSP. In that case, XBMC does all the playback stuff.

In all cases FernetMenta is right about the problem around stream changes. I'm preventing rewind/fast forward across channel switches in the MediaPortal and ForTheRecord addons,
What is not covered is the possible changes in for example audio streams (2.0 to 5.1) while playing a channel (but that was also not covered before for PVR addons that don't do the demuxing).

I've seen the commit from Elupus that continuously scans for stream changes, but this only takes into account the case in which the PVR addon delivers an already demuxed stream to XBMC.

The challenge for a proper timeshift capable PVR API is to handle at least all four current Live TV playback cases (wit examples of the pvr addons):
1) Live TV playback via a fixed stream url (url is known before tuning the channel) (pvr demo addon)
2) Live TV playback via a stream url that is returned by the addon after tuning the channel (MediaPortal in ffmpeg RTSP mode)
3) Live TV playback of a raw stream delivered by the addon (MediaPortal in TSReader mode / ForTheRecord)
4) Live TV playback demuxed streams delivered by the addon (TVHeadend, VDR)

The actual way in which the backend supports timeshifting is also dependent on the backend. Some have always a timeshfit buffer while others need to start a recording and might need to switch to a different stream url/demuxer to play the delayed Live TV stream.
In all cases we would need to handle changes in streams and stream order.
Developer of the MediaPortal PVR addon and retired developer of the Argus-TV PVR-addon.
http://www.scintilla.utwente.nl/~marcelg/xbmc
Reply
#17
I am not referring to a particular "hack". What I am saying is that before an API change was done, one should lay out all use cases. Not doing so I consider as a hack.
I agree to some changes to dvdplayer as margro laid out though I don't like the grayed out buttons. I don't like e.g. the change to DVDInputStreamPVRManager. This input stream was designed and optimized for live streams which are by nature not navigable. From an OO point of view this change was not very good. Why not having implemented an additional class for input streams which support timeshift. On rewind the players are likely to stall. In this case PVR input streams would engage caching for live streams.

What we have just done to pvr demuxer is an approach of centralizing required functions. When navigating a "timeshift" stream you need to follow certain constraints. e.g. you can't seek to the very end of the stream. Those constraints are the same for every addon and I think this should done by some centralized functions, not in every single addon.

EDIT: timeshift is not only pausing a live stream. What about starting to watch a recording which is still recording. I consider this as an important use case. I program a timer and start watching 30 min later, just to have enough buffer to skip commercials.
Reply
#18
Quote:I've seen the commit from Elupus that continuously scans for stream changes, but this only takes into account the case in which the PVR addon delivers an already demuxed stream to XBMC.

This does not really scan for PMT changes. It just detects changes of stream parameters. The notification has to come from the source which is able to detect PMT changes (tvheadend, vdr).

This might be a challenge when using ffmpeg demuxer. I am not sure if ffmpeg does expose this.
Reply
#19
I was referring to some of the PVR specific mods in DVDPlayer core that da-anda mentioned. I do understand why they were done, I just think that from a purely aesthetic and idealised software design point of view they needn't have been done that way. But then I'm new to XBMC internals, so I'll try and keep quiet Wink (Not to mention I'm not all that good with media playback anyway, I'm trying to learn as I go).

@FernetMenta indeed timeshift principles can be applied to in-progress recordings the same as live tv, ultimately this will be how TVH works (when we get around to it), i.e. from a clients POV there will be no difference between an in-progress recording and a live stream the same API will exist. (Whether this will extend to complete recordings for which a complete file exists is a matter for internal debate and probably not relevant to XBMC).

With regard to the contraints about handling the end of the buffers etc... there are several ways in which this can be handled. XBMC can (and should) be provided with the relevant information (about the size/duration and cur position, etc...) but equally it might be possible for the addons to simply signal when such conditions are met. This may be harder for file based systems, as opposed to those with their own container/demuxer etc.. For example if you hit the beginning of the timeshift buffer with my (experimental) TVH code it will simply output a message indicating the stream has been paused, if you hit the other end (live point) it will switch back to live playback and indicate this in the same manner.

So I agree that better understanding of all the requirements is indeed something that needs to be done, but at the same time having at least "some" elements of the required APIs within the XBMC core will help reduce the barrier to entry for many users that want to test these features (whatever the current state is) even if they aren't able to get the full and proper experience without further XBMC improvements.

@margro with regard to the stream changes I also agree with FernetMenta that this must be taken into account. While my current timeshift code does not actually output the relevant change info, the provision for it doing so has been included, I've simply ignored it for now for reasons of simplicity (since my own streams rarely change their makeup). But ultimately it will be no different to the way the TVH addon currently works on a stream change, I will simply index the change points in the buffer and output them as and when they are crossed etc...

Adam
Reply
#20
(2012-11-06, 13:24)adamsutton Wrote: With regard to the contraints about handling the end of the buffers etc... there are several ways in which this can be handled. XBMC can (and should) be provided with the relevant information (about the size/duration and cur position, etc...) but equally it might be possible for the addons to simply signal when such conditions are met.

I support this, and further believe it should extend into the core player. I can control pretty much everything about playback handling from a python program except growing files on a file system or web-based without a Content-Length. There is dramatic difference with these streams in how various versions of XBMC navigate within the stream and react to the initial duration point and it would be nice to have a standard approach.

Martin

Reply

Logout Mark Read Team Forum Stats Members Help
DVDDemuxPVRClient vs timeshift0