APPLICATION: Support timeshift over DVR.

[mort1k]

Hi, tell please there are plans to add access to dvr via hls.
For example dvr can optionaly save segments into .ts files or it's can also operate with option hls_cleanup off; and hls generate the correct playlist m3u8 with offset or range of time something like:

   live/stream/dvr_offset_[timestamp].m3u8
   live/stream/dvr_range_[timestamp]-[length-sec].m3u8

hls_cleanup option can be set to: on, offset to clear in minutes.

it would be very useful option for distribute live content via hls/dash and in some cases, but perhaps this is at odds with your standpoint.

[winlinvip]

Please never describe how to implements the feature, instead please describe what's the use scenario. Why record to hls? What's your business? What's your use scenario?

[mort1k]

Sorry, I made a note that it may deviate from your vision. :)
I tried to read #174, but it is very difficult to translate from Chinese into Russian with the impurities of the English, I think the meaning is that things distorted. Scenario simple:
how to cache response from dvr archive if used frequently with random timestamp access?

[winlinvip]

The issue #174 is not dvr to mp4. It's http-mp4 streaming, similar to http-flv streaming, or like the rtmp stream.
I still don't understand your scenario, can you show a example please? For example, a client how to access your DVR file?

[mort1k]

Example, clients with iptv consoles looking live hls streams from cache servers, which give streams from origin. Client can request via that caches random timestamp in past (timeshift).

                                (cache .ts) 
                                     |                     +--live 
stream -rtmp>[origin]<--hls-->[cache(edge) server]<--hls---+--timeshift (?timeshift=nnnn)
                |                                          +--catchup (?start=yyyymmddhhmmss&end=yyyymmddhhmmss)
             dvr (persistent .ts)

When used in this case flv-,mp4- streaming, it difficult effectively to cache.

[mort1k]

on the basis of the translation is a similar question: #466?

[winlinvip]

Nop. The issue #466 is HLS edge server, which is also a live stream edge.

[mort1k]

Hi, advise how to differently look at my case:

Example, clients with iptv consoles looking live hls streams from cache servers, which give streams from origin. Client can request via that caches random timestamp in past (timeshift).

                                (cache .ts) 
                                     |                     +--live 
stream -rtmp>[origin]<--hls-->[cache(edge) server]<--hls---+--timeshift (?timeshift=nnnn)
                |                                          +--catchup (?start=yyyymmddhhmmss&end=yyyymmddhhmmss)
             dvr (persistent .ts)

When used in this case flv-,mp4- streaming, it difficult effectively used with cache.

[winlinvip]

So, do you want the timeshift, for example, the player can play:

1. The url rtmp://ip/app/stream is for live stream, and server will feed the latest A/V packets to it.
2. The url rtmp://ip/app/stream?start=300 for timeshift, and server will shift the start point from 300s ago?
3. The url rtmp://ip/app/stream?start=300,end=600 for timeshift, and server will feed [-600s, -300s] content?

I think this example cover your scenario, right?

[mort1k]

For rtmp right, but we used hls for deliver stream.
In the third example, specify the start timestamp and the desired length of the content or start timestamp and end timestamp, not offset from start and end.

[winlinvip]

Whatever the stream protocol, both rtmp and hls are ok for timeshift. For HLS, the timeshift maybe:

1. The url http://ip/app/stream.m3u8 is for live stream, and server will feed the latest A/V packets to it.
2. The url http://ip/app/stream.m3u8?start=300 for timeshift, and server will shift the start point from 300s ago?
3. The url http://ip/app/stream.m3u8?start=300,end=600 for timeshift, and server will feed [-600s, -300s] content?

It's timeshift.

[winlinvip]

The timeshift is not live, because the kernel use scenario is different. So, it's very bad design to use live cluster to provide timeshift service. Instead, we must use DVR or VOD system to provide timeshift. For example, the live cluster delivery live streaming and send the live A/V stream to DVR system, the DVR will record to file(whatever flv, mp4 or hls), and the VOD system can support timeshift.

[mort1k]

Option 3 used for EPG entry with fixed constaint timestamp and duration in the past:
3. http://ip/app/stream.m3u8?start_timestamp=1485502931&duration=300
3. http://ip/app/stream.m3u8?start_timestamp=1485502931&end_timestamp=1485512931

[winlinvip]

I think it's better solution to support shift by HLS. Recommend to use the on_hls callback, to notify the HLS events to the external time-shift system.

[winlinvip]

Will not support time shift function.

TRANS_BY_GPT3