[Live-devel] Creating live tsx file or Updating existing TSX file

[Jeff Shanab]

Rtsp with trick play should have no difficulty it is the container chosen.
A lot of containers need to close to create an index.
Every system I have ever worked with that needed this type of functionality
has two files, One for the index and one for the video. You can read and
write in parallel, easy peasy.
It is why I did not tie myself to a container until it was an "export"
operation. Then I could export any subset of the video since the index can
then be created for the specific container and clip length on demand. be it
AVI or whatever.

On Tue, Nov 18, 2014 at 3:52 PM, Marcin <marcin at speed666.info> wrote:

>  Hi,
> I think that Michael wants to have somekind of DVR functionality in RTSP
> which is not supported i think.
> Marcin
>
> W dniu 2014-11-18 16:42, Chapman, Michael J pisze:
>
>  Sorry I didn’t clarify this in an earlier post, but one of the goals we
> were hoping to achieve is the ability to have any rtsp client able to
> connect to our Media Server and perform these commands. So, we were hoping
> to not have to develop and use a custom client if possible. For instance,
> having VLC player (merely as an example) connect to our Media Server and
> perform the near-real time trick play. I hope that makes sense and better
> clarifies our goal. That is why we are looking into the tsx file generation
> possibilities.
>
>
>
> Thank you,
>
>
>
> Michael Chapman
>
>
>
> *From:* live-devel [mailto:live-devel-bounces at ns.live555.com
> <live-devel-bounces at ns.live555.com>] *On Behalf Of *Jeff Shanab
> *Sent:* Monday, November 17, 2014 9:09 AM
> *To:* LIVE555 Streaming Media - development & use
> *Subject:* Re: [Live-devel] EXTERNAL: Re: Creating live tsx file or
> Updating existing TSX file
>
>
>
> That seems similar to security video and if it is really just the recent
> past, can be done entirely in the client. It may be preferred for the
> smooth transition from now to recent-past and back to realtime.
>
> Note: You would only cache uncompressed video. I maintained 2 gops worth
> decoded and the rest however many seconds configured.
>  ( I had my own http based server that served out gops of video so I could
> play both directions and have random access to the video. I only put things
> in containers on "export" I streamed to a player of my own design so I was
> not streaming rtsp, I streamed multiple protocols including my own http one
> from the same rtsp input. A bit odd, but it worked)
>
>
>
> On Mon, Nov 17, 2014 at 10:44 AM, Chapman, Michael J <
> michael.j.chapman at lmco.com> wrote:
>
> Ross,
>
>
>
> The video streams we are dealing with for our project mainly involve
> Unmanned Aerial Vehicle (UAV) video footage which comes to us as a video
> stream over the network. Due to the nature of the video, we need to be able
> to view it as soon as possible. We have an option to view it live from the
> source (non-rtsp approach with no trick play features) and we also want to
> be able to view the video footage in near-real time via rtsp. The benefit
> of the rtsp approach is that each user can have a unique rtsp session of
> the video with the intent of near-real time trick play. If an analyst sees
> something of interest in the video, they need to ability to rewind (or at
> least seek backwards) a few seconds before the video segment of interest to
> verify the footage. The ability to re-verify a video segment in the recent
> past, while watching the near-real time video, is why we would like to have
> this Live555 Indexing feature.
>
>
>
> Also, these videos will remain archived and available via rtsp for future
> analysis, so we will be using the rtsp and trick play options after the
> video is completely received. We are just hoping that we could use a live
> indexing rtsp feature for the near-real time analysis use case instead of
> creating a custom caching of the video until the video is fully received
> and indexed. As the video stream we are receiving may be very long (may be
> up to or more than an hour is some cases), we cannot realistically index
> the file as we are receiving it without the requested feature.
>
>
>
> Thank you,
>
>
>
> Michael Chapman
>
>
>
>
>
> *From:* live-devel [mailto:live-devel-bounces at ns.live555.com] *On Behalf
> Of *Ross Finlayson
> *Sent:* Sunday, November 16, 2014 1:07 PM
> *To:* LIVE555 Streaming Media - development & use
> *Subject:* EXTERNAL: Re: [Live-devel] Creating live tsx file or Updating
> existing TSX file
>
>
>
>  I am recording a transport stream file that needs to support rtsp trick
> play as it is being recorded
>
>
>
> People often ask for this feature, and I'm a bit puzzled by it.  What
> specific 'trick play' operations do you want the server to be able to
> perform on the Transport Stream file while it is still growing?  (I'm
> trying to understand whether/when this actually makes sense.)
>
>
>
>
>
>  Is it possible to create the tsx file as I am recording and continue
> indexing as new data if received (so having the indexer block and wait for
> new data) while also having that partially complete tsx file be used with
> the Live555MediaServer for trick play?
>
>
>
> I may well end up adding this feature - but first, I'd need to get a feel
> for how much it makes sense (thus my question above).
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
>
>
> _______________________________________________
> live-devel mailing listlive-devel at lists.live555.comhttp://lists.live555.com/mailman/listinfo/live-devel
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20141118/07011302/attachment.html>