PROPOSAL: enhance live stream support

[jonasgrosch]

I'm interested in using this package for livestreams by bringing it closer to a player implementation:

• Changing the processing order from 1. all audio fragments 2. all video fragments to iterate by fragment id and get audio and video at the same time and process them JIT
• Not use tempfiles when the fragment save option is activated but operate on the output files
• periodically refetch the mpd file
• start at live position or select a catchup mode where we start processing in the beginning of the stream(if fragments still available) and keep processing live until stream ended or user interrupted
• allow for graceful sigint/ctrl+c interruption in general

I personally believe that these features would roundup this module, this is why I'm opening this issue rather than just going ahead reimplementing most of this logic. I think rather than a completely dedicated routine we could offer these features being backwards compatible and still fully supporting the VOD usecase that is currently covered and keeping the api pretty much the same with little additions.

I'm happy to help with the change in implementation if you find this proposal useful.

[emarsden]

Thanks for your proposal.

Can you explain what your planned use case is? Do you want to improve the ability to download "pseudo-live" streams, where all segments are in fact available at the time of download, or are you interested in viewing a "true" live stream, live, as is possible with VLC for example?

Also, I don't understand what you mean by your point concerning tempfiles and "operate on the output files".

[jonasgrosch]

My planned use case is to support true live streams where not all segments are available yet: "start at live position or select a catchup mode where we start processing in the beginning of the stream(if fragments still available) and keep processing live until stream ended or user interrupted". I successfully used this on pseudo live streams and it works flawless but I'm interested in making it work with real live streams "by bringing it closer to a player implementation".

The point of the tempfiles is somewhat off topic but I came across it when trying to analyse my usecase fit and I stumbled upon the save_fragments option. when this is selected it seems to be redundant to still use tempfiles to operate on for decoding and remuxing purposes as it uses double the disk space and keeps your saved fragments drm encrypted.

[emarsden]

OK, in principle I am in favour of better support for live streams. My current intuition is that the necessary logic would be difficult to fit in with the current VOD support, which is already rather convoluted. For example, I presume it would be necessary to add to the API a consumer function for the segments as they are downloaded, and to add timing logic to wait for segments that are not yet available. (Perhaps you can convince me that my intuition here is incorrect, though.)

I would probably be willing to merge separate code that handles live streams, if it looks good to me, and to reorganize the existing code so that it's easier to share common functionality.

[jonasgrosch]

I do think a timing mechanism is definitely necessary. I'd be happy to go about that alongside the consumer function and other topics. What would definitely help me get started is to reorganize the code a bit and potentially move the VOD download approach to a fragment by fragment approach (video+audio+text) which would leave me with a function I could reuse for live processing. Unless you see any major benefit in the current period based approach that downloads audio first and goes to video after.

[emarsden]

The current sequential Period-based approach is simpler that what you are proposing. That's not a sufficient reason to avoid reorganizing as you suggest; if your patch looks good I will probably be willing to merge it. Have fun!