Matt & I went though this issue a while back for live streams. It's probably
similar if you're trying to shut down a file-based stream before it gets to
its end...
To force a session to end before the client requests a teardown, we ended up
deleting the RTSPClientSession instance out from und
On Thursday 25 June 2009 10:35 pm, Muhammad Bilal wrote:
> Hi Everyone!
>
> I'm writing Xvideo streamer. I've written my own Video source file derived
> from FramedSource and I'm using MPEG4VideoStreamDiscreteFramer and
> MPEG4ESVideoRTPSink. I'm using VLC player to receive stream. The problem is
>
I don't know everythign about RTP nor JPEG, but since nobody else has offered
an answer...
What's a "normal jpeg image" to you? Many programs put out JFIF images when
they write them to files, so I'd consider JFIFs to be "normal".
Maybe you could crack open the JEPGs that work and the ones tha
On Wednesday 27 May 2009 11:21 am, Jeremy Noring wrote:
> If I have time, I may try to do this today, since I need this sort of
> functionality for debugging symbols, debug/release builds, x64 support,
> integration into our project, etc. I'll let you know if I have any
> success.
We needed the s
RTSPClient doesn't support the client timeout directly, so you have to wrap it
(eg. subclass it) and schedule/reschedule your own task to do that. I can't
remember what we use as the stimulus to reschedule, and don't have time to
look right now.
later,
patbob
On Thursday 23 April 2009 5:58
This will work, but time() only has resolution of 1 second, so your times
reported by gettimeofday() will be consistently off by up to 1 full second
from what they should really be. If you do the same thing with ftime(),
you'll be consistenly off by somewhere in the 10s of milliseconds.
It do
Over in GroupSockHelper.cpp is a windows implementation of gettimeofday().
There are three implementations for it -- one for CE (?), one that uses
ftime() and another that uses QueryPerformanceCounter().
The version that uses QueryPerformanceCounter() is broken. With that
implementation, the
It's been a while since I looked into these sorts of issues, but green is
significant on YUV-encoded imagery, such as Jpegs, Mpeg4 and (I believe)
H.264. It often means the deocding failed and the max amount of blue & red
are being subtracted from the resulting image, making it green (i.e. sic
On Tuesday 31 March 2009 6:16 am, Ross Finlayson wrote:
> >What is the correct way to initiate the shutdown of a specific
> >RTSP client session from the server side?
>
> Right now there isn't a clean way to do this, unfortunately. If you
> know the "RTSPServer::RTSPClientSession" object, then you
> >A secondary and not so urgent issue; I'm testing on a multihomed server
> > and attempting to restrict multicast output to a specific subnet.
>
> That's something that you have to do in your OS (usually by changing
> routing tables). It has nothing to do with our software (which, of
> course,
I just fixed this issue in our code last night -- the I-frame from the H.264
encoder was getting truncated because it was too big to fit into the stock
OutPacketBuffer buffer (only ~6 bytes).
The short answer is that the entire outgoing packet must fit into a buffer --
there's no way for
Is there any consistent way for a client to know that authentication has
failed? It needs to know this so it can prompt the user for their
login/password. I've been looking at the RTSPClient.cpp code, but I can't
see any consistent way that it reports an authentication failure.
thanks,
patbo
Could you be running into sleep quantitization issues? 60 fps is down in
sleep quantitization issueland. The buffering on the receiver should take
care of things, but maybe it isn't, or the timestamps are not getting
generated correctly?
patbob
On Tuesday 10 March 2009 4:57 pm, Gbzbz Gbzbz
ly related logic
threads at once and wires got crossed in the 'ol noggin.
later,
patbob
On Tuesday 24 February 2009 8:32 am, Patrick White wrote:
> > >I'm trying to use ReceivingInterfaceAddr & SendingInterfaceAddr to
> > > control which interface RTSP/R
> >I'm trying to use ReceivingInterfaceAddr & SendingInterfaceAddr to control
> >which interface RTSP/RTP traffic is going in and out on.
> >In setupDatagramSocket(), there is the line:
> > if (port.num() == 0) addr = ReceivingInterfaceAddr;
> >This line is just prior to the bind() call. So..
I'm trying to use ReceivingInterfaceAddr & SendingInterfaceAddr to control
which interface RTSP/RTP traffic is going in and out on.
In setupDatagramSocket(), there is the line:
if (port.num() == 0) addr = ReceivingInterfaceAddr;
This line is just prior to the bind() call. So.. UDP ports a
This is probably a stupid question, but...
In RTSPServer::RTSPClientSession::livenessTimeoutTask(), the RTSP client
session is deleted only if it is not a mutlicast session. The comment claims
this is to avoid closing all client sessions, not just the one that has timed
out. The only thing t
On Saturday 07 February 2009 2:00 pm, Morgan Tørvolt wrote:
> The calculations are easy. A disk with 100MB/s read speed and 10ms
> access time will give you 1MB per 10ms read time. If you read 1MB at a
> time on random spots on the disk, you will use 10ms per read, and 10ms
> on average for moving
Why not just use a scheduled task? It can either poll to check for characters
on the serial port or get them from a queue.
later,
patbob
On Monday 02 February 2009 6:16 am, Yedidia Amit wrote:
> Hi all,
>
> I know this not exactly the right place to ask this so feel free to
> ignore me.
>
> I
We've been making changes to the library support the needs of the software
we're writing. We'd like to submit those changes back to the project.
I've looked but can't find any info on how to do that. Can someone point me
in the right direction?
thanks.
20 matches
Mail list logo
