hi,
As a RTSP server, I try to use RtpOverTcp which has the same socket
as "RTSPClientSession" objet.
When start playing, RTCPInstance socket read handler will replace
RTSPClientSession's handler.
If there is any other sequent RTSP Request, such as "PAUSE,
TEARDOWN", RTSPClientSession will not
It seems that the code on MediaSubsession::initiate will cause the effect
I'am reporting when the OS offers the same odd port number for both the
video and the audio stream.
Yes, you're right. This bug got introduced in version 2008.12.20
when I changed the port number selection code in respon
hi,
As a RTSP server, I try to use RtpOverTcp which has the same socket as
"RTSPClientSession" objet.
When start playing, RTCPInstance socket read handler will replace
RTSPClientSession's handler.
If there is any other sequent RTSP Request, such as "PAUSE, TEARDOWN",
RTSPClientSession will no
Hi,
I'm agraid I have to desagree with you.
It seems that the code on MediaSubsession::initiate will cause the effect
I'am reporting when the OS offers the same odd port number for both the
video and the audio stream.
The method looks like this:
While (1) {
unsigned short rtpPortNum = fClien
Hi,
I tried an experiment running 2 openRTSP processes in the testProgs folder.
They connected to the same URL (an Axis Camera), and they both used the same
client_ports. The server handled the connection on different ports, but the
client_port reported in the Transport Section were the same.
Sh
Hi,
I've found that in some cases (it seems to be random) the method
mediaSubsession::initiate will use the same UDP ports for both a
video stream and an audio stream. A sample output for the openRTSP
program is the following:
Created receiver for "video/MP4V-ES" subsession (client ports 343
In general, it's hard to respond to alleged bug reports on modified
code. The best bug reports are those that apply to the original,
unmodified code, so we can (hopefully) reproduce the problem (if any)
ourselves.
PS. You also should note that the BYE handler code in OpenRTSP
causes all the
I thought the fDuration is related to the frame rate?
It is. You (as the programmer of a source object) set it (actually,
"fDurationInMicroseconds") for each frame, as appropriate. But the
'frame rate' itself is not carried as a parameter anywhere within RTP
or RTSP.
We have a hardware
I thought the fDuration is related to the frame rate? We have a hardware
encoder and we save the contents to a file before we stream them out. When play
the file locally with VLC, it looks a 720P60, but at the remote VLC RTSP client
side it is 720P30(or less) - visually it is not as smooth.
I
Ok, I added a call to RTCPInstance::sendBYE() at the very start of the
StreamState::endPlaying and that seems to get get the BYE sent to the
client. Although I'm not sure what this would do in a multiple client
scenario, I think everybody would get the BYE message which may not be
right, might
Does current live555 support 60 fps? say 720p60? any parameters in this area?
Frame rate and dimension parameters are carried within the video data
itself (and therefore is specific to the video codec, and has nothing
to do with RTSP or RTP).
--
Ross Finlayson
Live Networks, Inc.
http://www.
Ok, I'm feeling better now and I've determined that the server is
attempting to send the RTCP BYE packet in the RTCPInstance destructor
but by that time all the destinations have been removed from the
GroupSocket so no data is actually sent (I've confirmed this with
WireShark).
I had thought
Hello All,
I'm having an issue getting a live MPEG4 video source into Live555,
any help would be great.
This is how I defined my live input;
in DeviceSource.hh;
removed
//private:
//void deliverFrame(); //ags
added
public
Does current live555 support 60 fps? say 720p60? any parameters in this area?
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
14 matches
Mail list logo
