Oops, of course, I *meant* to say: "In general, you can't expect a
RTSP *server* to work if it's behind a NAT."
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.
>The "server" doesn't have a public IP.
>It is behind a NAT (behind a consumer DSL modem) and doesn't even know
>what it is NATed to.
Yes, that's the problem. In general, you can't expect a RTSP sorry
to work if it's behind a NAT. The IETF is working on overcoming
this, but for now that's just
Ross,
Hope you don't mind if I don't bottom post. This seems to be a cardinal
sin on FFmpeg-devel and vlc-devel. Anyway thanks for your help.
> No, your NAT is making this way too complicated!
Agreed. but we're (I'm) stuck with it. Not even mine, another vendor
I'm trying to integrate with.
>I think you're making this way too complicated.
No, your NAT is making this way too complicated!
> Simple question: As
>per the RFC, should the RTCP RRs go to the IP in the original rtsp://...
>or to the IP reported as the Content-Base
The latter.
> (due to the horrible, nasty,
>abominab
Ross Finlayson wrote:
>> > They should be getting sent to whichever server IP address was
>>> specified in the "rtsp://" URL, or - if a server domain name was
>>> specified instead - whatever IP address that domain name resolved to
>>> when it was looked up (via DNS).
>>>
>>> RTSP/RTP cannot r
> > They should be getting sent to whichever server IP address was
>> specified in the "rtsp://" URL, or - if a server domain name was
>> specified instead - whatever IP address that domain name resolved to
>> when it was looked up (via DNS).
>>
>> RTSP/RTP cannot reliably be expected to work
Ross Finlayson wrote:
>> The RTCP RRs are being sent, but apparently to the un-NATed local
>> network address of the server
>
> They should be getting sent to whichever server IP address was
> specified in the "rtsp://" URL, or - if a server domain name was
> specified instead - whatever IP addr
Hi,
The Vatican CTV live stream - rtsp://212.77.7.133:80/h264lan.sdp
does not work with openRTSP.
On the vatican homepage there is a note, that VLC media player
should play them, but it does not.
Both "openRTSP" and "VLC" (and "QuickTime Player") play the stream OK for me.
Perhaps you're stuc
>The RTCP RRs are being sent, but apparently to the un-NATed local
>network address of the server
They should be getting sent to whichever server IP address was
specified in the "rtsp://" URL, or - if a server domain name was
specified instead - whatever IP address that domain name resolved to
This is a know problem with the current implementation of
"RTSPClient". It should be doing asynchronous socket reads (within
the event loop), rather than a (potentially blocking) synchronous
read.
Fixing this is on my 'to do' list.
In the meantime, your immediate priority should be to figure
I'm new to LiveMedia library and I am experimented with it under
Windows OS. I have found in the file ByteStreamFileSource.cpp the
code that synchronously read the source buffer from a file. I need
to know however when the library will have finished of using the
buffer.
Note that the buffer t
Hi,
The Vatican CTV live stream - rtsp://212.77.7.133:80/h264lan.sdp
does not work with openRTSP.
On the vatican homepage there is a note, that VLC media player
should play them, but it does not.
Is this a problem of live555? Currently, the stream should be on.
Thank you very much
Markus Doppe
Bill Dolson wrote:
> Bill Dolson wrote:
>> Hi,
>>
>> Weird one. Running wis-streamer from composite video
>>
>> wis-streaner -r 64000 -na
>>
>> Using VLC 0.8.6d Windows running on the same LAN as the server will play
>> the stream all day.
>>
>> Using the same VLC version Windows or Linux (el5) f
Bill Dolson wrote:
> Hi,
>
> Weird one. Running wis-streamer from composite video
>
> wis-streaner -r 64000 -na
>
> Using VLC 0.8.6d Windows running on the same LAN as the server will play
> the stream all day.
>
> Using the same VLC version Windows or Linux (el5) from anywhere on the
> Inte
Hi,
Weird one. Running wis-streamer from composite video
wis-streaner -r 64000 -na
Using VLC 0.8.6d Windows running on the same LAN as the server will play
the stream all day.
Using the same VLC version Windows or Linux (el5) from anywhere on the
Internet playback freezes after approx 45 sec
Hello,
I'm new to LiveMedia library and I am experimented with it under Windows OS.
I have found in the file ByteStreamFileSource.cpp the code that
synchronously read the source buffer from a file. I need to know however
when the library will have finished of using the buffer. Is there some
fee
Dear Sir:
When I try to connect AXIS IP camera several times(one to many, no regular
pattern), the RTSPClient::describeURL() never retruns. After doing some
source tracing, I find that it is blocked in readSocket() in
RTSPClient::getResponse1(). This is because the readSocket() calls
blockUntilRea
> i was wondering is it possible to extend the source code posted in
>live555 to support 3G video streaming ?
We already support streaming all of the audio and video codecs (and
protocols) used by so-called '3G' clients. (However, we don't yet
support streaming from pre-recorded MPEG-4-format
Hi,
I have mp4 video, how do i convert it to transport stream so that i can
play it on amino stb
Swapnil Jain
Indore
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
hi , I am new to this forum. i am an electronic and electrical student and
currently i am doing my final year project on 3G live video streaming from a
network camera. i was wondering is it possible to extend the source code posted
in live555 to support 3G video streaming ? the only hardware i h
20 matches
Mail list logo
