I forget the specific motivation behind this API change (which occurred back in
2011), but I suspect it had to do with wanting to make sure that open files are
never left lying around once the “ByteStreamFileSource” object is closed.
I can understand that, but that could have been achieved with
Hi Ross,
I have an RTSP server application that uses a woefully out-of-date version of
live555. I'm in the process of updating to the latest version of live555 and
have come across an API change that puzzles me.
Basically, I have a thread that generates H.264 video and feeds it through a
pipe
- The absolute timestamp I ask for doesn't match what I receive, Many hours
off, but at least it's consistent.
For what it's worth, this sounds like it could potentially be a time zone
issue. I've run into issues in the past where some of the routines I used
interpreted my UTC timestamp as a t
More seriously we need to seek in absolute mode because we would like to query
video according to the time we recorded it (and not a relative time relative to
begin of RTSP session).
This is the first time I've ever heard of someone doing this (or even wanting
to do this). Because it's allow
Ross,
Thank you very much for your response. Removing MPEG2TransportStreamFramer
from the chain seemed to do the trick. Thanks for your great work.
Tyson
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, December 10
This is kind of a shot in the dark, but I have been puzzling over a problem for
several days and I am hoping someone here can either rule out Live555 or
confirm that it could be contributing.
I am running an RTSP server application based on Live555 that receives live
H.264 encoded video from a
>> >Hmm, reads from the input file (in this case, a pipe) are supposed to
>>>be non-blocking, returning only as many bytes as are currently
>>>available (which will always be >0, because the read is happening
>>>only in response to a return from "select()" on the input file's
>>>socket). Perhaps
Ross,
Thanks for the reply. Please see my comments inline below.
Tyson
>>I am using the live555 library in a Linux application that receives
>>a low frame rate MPEG2-TS from a live source one frame at a time.
>>The source is not represented as a file by the OS. To make the
>>interface to th
I am using the live555 library in a Linux application that receives a low frame
rate MPEG2-TS from a live source one frame at a time. The source is not
represented as a file by the OS. To make the interface to the live555 library
easier, I opened a pipe and write each frame to it as I receive
After a little more investigation, it turned out to be a stupid error on my
part. Sorry to have wasted your time.
-Original Message-
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Friday, December 17, 2010 1:03 PM
To:
Hi Ross,
Thanks for the reply.
Yes, if I omit the "-m" option the single large file looks the same. I've
tried using a debugger to trace it back. I'm not at my work computer right
now, so this is all from memory and may not be entirely correct. As I recall,
however, the FileSink had a Simpl
I have created an RTSP server using your library that streams video frames in a
custom format, using the M bit to indicate the end of the frame. Each frame is
roughly 400KB. I have been trying to use openRTSP to receive the stream and
output each frame to a file using the following command lin
Ross,
Thanks for the help. After doing a quick test it appears that making the
suggested modifications to my subclass of "OnDemandServerMediaSubsession" does
work as expected. I appreciate your great work on this library.
Tyson
-Original Message-
From: live-devel-boun...@ns.live555.c
I am trying to use the live555 library in a project of mine, but I am running
into some issues I haven't been able to figure out despite reading the FAQ and
searching the mailing list archives.
Basically, I need a server that streams data on demand from a live source to a
client. The stream ne
14 matches
Mail list logo
