I saw this thread from 2014 and was wondering if this functionality was ever implemented. We have a similar need:
> As some people noted, it would be possible to implement the mechanism that Michael Chapman’s asking for (rewind/seek backwards) in the client - but it
> shouldn’t be necessary, because the RTSP protocol already has a mechanism for this - and, as Michael noted, RTSP is already used for ‘off line’
> playback, so it makes sense to try to use the same RTSP client for both mechanisms.
> So yes, it should be possible for me to update the “MPEG2TransportStreamIndexer” application to continually extend the index file if the underlying
> Transport Stream file keeps growing. (This will also require a small change to the RTSP server’s Transport Stream 'trick play' code to allow for the
> possibility of the index file growing after it was first read.)
> I have only limited Internet access over the next few weeks, but I’ll see if I can make this change sometime before mid-December. (If you are
> interested in paying money to expedite this, let me know by separate email.)
> Ross Finlayson
> Live Networks, Inc.
Unfortunately, I looked through the release notes and didn’t see an entry that looked similar to this.
If it is not possible to update the tsx file as the stream is being recorded, are there strategies you have found that allow you do it?
One thing that comes to mind is to have one process save the original stream to a .ts file. Also have another process save off 1 minute chunks of the stream into smaller .ts files. Then index the 1 minute .ts files (creating small .tsx
files) and append the small .tsx files into one master .tsx file.
I don’t know if the format of the final .tsx file would be valid or not and I don’t know if the Live555 Media Server would pick up the updated .tsx data as it streams the video.
Any help would be appreciated.