> In general, you cannot expect RTSP/RTP to work over a NAT. However,
> because your server is really on the Internet, then you might be
> able to get RTP-over-TCP streaming to work, even though your client
> is not really on the Internet.
Is the IP address the only problem with NAT? Couldn't
> The problem is, deliverFrame returns the very first frame OK, then
> doGetNextFrame is called again before a new frame is captured, and I
> return immediately. Then, I don't know why, liveMedia never calls
> doGetNextFrame again. It just stays stuck and apparently does nothing.
>
> Why? What
> It wasn?t immediately obvious to me: Is there a receiver
> counterpart to the testMPEG2TransportStreamer.exe test program that
> I can play with?
use openRTSP program.
~xo___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live5
> I'm trying to use the openrtsp program in order to connect to an
> Axis camera ( axis 207 ) unsuccesful!!!
> All seems to go well, I sand to camera all the right commands (
> DESCRIBE, PLAY, and so on..) but when i can see in the shell
> "Receiving streamed data", I cant save the data in a fil
> How can I add several "RTPSink" or "UDPSink" objects to
> testMPEG2TransportStreamer?
testMPEG2TransportStreamer delivers a multicast stream, so you can already
have multiple clients connect and watch this stream. is it your intent to
have a stream received by several clients or to make sev
Is it OK to daemonize the live555MediaServer? I do not really know about
daemonize, but my team is trying to do this and they are having trouble.
So I wonder if there are known reasons why this could not be done? Thanks!___
live-devel mailing list
live
In RTSPServer::incomingRequestHandler1() conditional "if (bytesRead <= 0
|| (unsigned)bytesRead >= fRequestSpaceRemaining)"
Q: Is it really a failure if the number of bytes read == the amount of
space available?
I was thinking that it would be because we wouldn't know if there was more
to read
Why do all the 'incomingRequestHandler()' functions take an integer
parameter which has no name?
In RTSPServer.hh:
static void incomingRequestHandler(void * clientData, int /* mask */);
Thanks!
??
Xochitl Smith
GS Software Engineer; Computer-E
A couple of general design questions, if you please:
1. Is there specific reasoning that LIVE555 does not use STL? I have not
worked with the STL before, so I can't really answer this question when it
comes up.
2. I saw in the online "todo" list that there was an item to change
certain data
These are probably not too important, but while updating to LIVE555
2007.08.03a, I've so far noticed a couple things which I thought were
curious:
* GroupsockHelper.cpp: line 101 - Is there now an extra semicolon at the
end of this line?
* groupsock: New File: GroupsockHelper.cpp.save
* RTSPOve
In FramedFilter.cpp FramedFilter::~FramedFilter()
fInputSource is not set to NULL after Medium::close(fInputSource);
Any reason?
Thx.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Have you reviewed earlier mail-list inqueries regarding Amino STB and
trick play? This mail list does not support Amino, specifically. As I
recall, Live Networks just happens to have 1 Amino STB sitting around the
lab. Your troubles with Amino STB might need to be directed to the
manufacturer
> Q: What is ByteStreamFileSource::fPlayTimePerFrame for?
>
> It's used to implement the (optional) "playTimePerFrame" parameter
> in "ByteStreamFileSource::createNew()".
> --
Yes, I did look at the code for this, but I don't understand what
"playTimePerFrame" actually does. Does it request t
Q: What is ByteStreamFileSource::fPlayTimePerFrame for?
xochitl___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Ross,
1. I hope it is not unbecoming for me to inquire, but are you expecting
to release any significant trick mode changes in the next 2 weeks?
I ask because I must now specify the version of LIVE555 which will be
delivered with our baseline product. I should not like to miss out on
importa
Ross and Community,
I am hoping to implement a bandwidth limitation on trick mode streams
only, such that the bitrate of the trick mode stream would not exceed the
average bitrate of the original stream. For the particular 5 Mbps streams
that I have, I cannot get above 4x speed-up without sig
Actually, you won't need to insert a "MPEG2TransportStreamFramer", because
its main purpose is to extract presentation times from the transport
stream, and you won't need those if you're just outputting to a
"FileSink".
Re: Doesn't MPEG2TransportStreamFramer also check for sync bytes in the
da
Do you have a specific reason to not use openRTSP to receive transport
streams? testMPEG2TransportStreamer has an optional RTSP server in it.
I think instead of making MPEG2TransportStreamRTPSource, you should set up
the chain like this:
SimpleRTPSource -> MPEG2TransportStreamFramer -> FileSin
I am working with mediaServer and the trick mode code now, and I have the
following problem:
When I setup a session and send the very first PLAY request with a scale
of 2.0, I get a regular 1x stream. I ran the debugger for awhile and
noticed that in ClientTrickPlayState, fScale is initialized
I notice that my trick mode streams seem to have the same average data
rate regardless of the specified scale factor. Does the trick mode
implementation send an I-frame at a rate of 30 fps, but repeat I-frames to
fill in the gaps since there are only 2 I-frames / second in my stream?
So for ex
In order to support mutlicast, 'testMPEG1or2VideoStreamer' would have to
be integrated/started to allow the running RTSP Server to perform
mutlicast playback. Is this correct or has multicast support been
incorporated into an RTSP Server?
As you will see in the mailing list, I already tried ad
I notice in the class headers like RTSPClient the function description
appears after the function. is it prefered to put the function explanation
after or before the function?___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.
Ross and Community:
I am trying to clean up my code in preparation for release. Would there
be any interest in having the following items granted back to the library?
Thanks for your consideration!
Xochitl
Class NPTClock:
A class used by RTSPClient child class which receives the
RTP-ti
When commenting LIVE555 code, is it prefered to have the comment blocks
appear after the code block or function definition the comment block
pertains to? I can't tell which is the prefered location. Are larger
comment blocks using // prefered over /* */ ? What about Doxygen
comments? ( /**
I am looking at the source testProgs/playCommon.cpp, in particular the
shutdown() and afterPlaying() functions.
Does calling Medium::close(subsession->sink) call the subsession
destructor also? This is what the comment says in
subsessionAfterPlaying().
I set a breakpoint on MediaSubsession::~Me
In any case, the current code ("bind()"ing to "ReceivingInterfaceAddr") is
necessary for unicast streams to work properly (if
"ReceivingInterfaceAddr" was set to something other than INADDR_ANY).
Re: So when you make this change, you are not able to receive unicast
data? My Fedora Core 5 syste
We *do* allow "ReceivingInterfaceAddr" to be something besides INADDR_ANY.
That's the whole point of the existing code.
Re: But my change does not disable the ability to change the interface
from the default. The address parameter on the "bind" call specifies what
destination addresses the s
Sorry, but I can't make this change. The existing code is the whole
reason why we allow "ReceivingInterfaceAddr" to be something other
than INADDR_ANY.
Re: Do you have a different suggestion of what to try? Why would you not
allow ReceivingInterfaceAddr to be something besides INADDR_ANY? I
Forgive my extra post, but maybe it would be easier to understand if you
change the line to this:
MAKE_SOCKADDR_IN(name, INADDR_ANY, port.num());
Xochitl___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/
Thanks for your response, but I don't think this fixes the problem. Why
bother setting the Sending- and ReceivingInterfaceAddr at all if you are
going to get the address using multicast loopback first? When I try this
in my system with multicast enabled on eth1 and eth0, the multicast
loopback
Try to get your loopback address before setting your listening interfaces,
this fixed my problem
David,
Thanks for your response, but I don't think this fixes the problem. Why
bother setting the Sending- and ReceivingInterfaceAddr at all if you are
going to get the address using multicast loo
I have an issue where if I set the Sending- and ReceivingInterfaceAddr to
eth1, I cannot receive multicast data. I set them as the first 2 lines of
my main() function like this:
SendingInterfaceAddr = our_inet_addr("10.145.223.24");
ReceivingInterfaceAddr = our_inet_addr("10.145.223.24");
I have
In any case, to use your example, it's bad design for the RTSP
*clients* to be deciding which multicast address each server should
be using, not merely because it relies upon the server having this
ability enabled. It makes far more sense for each *server* to choose
(or be assigned) its multic
33 matches
Mail list logo
