> On Oct 30, 2023, at 12:57 AM, Jörg Dommaschk via live-devel
> wrote:
>
> I think I may have found a bug: In BasicTaskScheduler0::deleteEventTrigger in
> BasicTaskScheduler0.cpp in the lines 126 and 128,
> fTriggersAwaitingHandling[fLastUsedTriggerNum] is cleared/set to False. If I
> under
--- Begin Message ---
Hello,
I think I may have found a bug: In BasicTaskScheduler0::deleteEventTrigger in
BasicTaskScheduler0.cpp in the lines 126 and 128,
fTriggersAwaitingHandling[fLastUsedTriggerNum] is cleared/set to False. If I
understand things correctly - and I might very well not - sh
Thanks for the quick and detailed reply Ross.
My apologies you're correct it is the front-end connection we are dropping with
clumsy not the back-end as I originally stated.
I had a feeling there'd have been a good reason the live555 server was working
this way, so thanks again for the clarific
Mark,
There are two huge problems with this. First,
“ClientSession::livenessTimeoutTask()” is usually called when a client happens
to go away without sending a RTSP “TEARDOWN” command. But other clients might
continue to be (concurrently) accessing the server (in this case, a proxy
server) O
Hello,
When running the ProxyServer application from the live555 testProgs on windows
I have encountered an issue where sockets are not released when a client
session is timed out.
Put some logging around the select call in BasicTaskScheduler to output the
read, write and except socket counts
Alexander,
Thanks for the report. Yes, I think that this is a bug. (If there was a
reason why the code for sending “OPTIONS” was different than for other
commands, I can no longer remember it - so I’m going to assume that this was a
mistake.)
I have just installed a new version (2020.04.24)
Hello,
I found some behavior in proxyServer that might be a bug. It can be reproduced
on latest version on live555 library.
If I specify username and password with -u command line argument then
OPTIONS keepalive request is sent without Authorization header.
And subsequent requests (e.g. PAUSE or
Hi ,
Thanks for your instant reply,
I am not saying there is bug in code. I am really sorry if you felt so. we
are using live555 code as RTSP server, we started with doing UDP streaming
which works very well, now our customer wants to change it to TCP. so we
are trying to debug.
we are using wis
> I am trying to stream rtp over tcp and i am facing the issue like stream is
> stopping after 3-4 mins(I am using VLC as a client)
Oh please! Why do you think that this means that there is a bug in our code at
all, let alone a bug in one specific function?
I assume (although you didn’t say ex
Hi
I am trying to stream rtp over tcp and i am facing the issue like stream
is stopping after 3-4 mins(I am using VLC as a client), i applied
following patch but didn't work for me.
- sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]),
numBytesRemainingToSend, 0/*flag
> Probably increasing of the send buffer (SO_SNDBUF) can help
Yes, you can call "increaseSendBufferTo()" in your application. However,
you'll still get data loss if your stream's bitrate exceeds the capacity of
your TCP connection (which is *not* the same as the nominal bitrate of your
network
--- Begin Message ---
Thank you very much for detailed explanation.
Probably increasing of the send buffer (SO_SNDBUF) can help, it's value depends
on estimatedBitrate from RTPSink:
if (rtpSink != NULL && rtpSink->estimatedBitrate() > 0) streamBitrate =
rtpSink->estimatedBitrate();
if (rtpGroup
> I tried to fix the problem by this way:
>
> - sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]),
> numBytesRemainingToSend, 0/*flags*/);
> +
> + do {
> + sendResult = send(socketNum, (char
> const*)(&data[numBytesSentSoFar]), numBytesRemainingToSend
--- Begin Message ---
Hallo everybody!
I discovered strange disconnections when I used streaming over TCP.
I recompiled live555 library with -DDEBUG and -DDEBUG_SEND and saw some
diagnostic:
sendRTPorRTCPPacketOverTCP: 1448 bytes over channel 0 (socket 7)
sendDataOverTCP: resending 795-byte send
Thanks for the report. I have now installed a new version (2012.09.07) that
should fix the problem (with receiving RTP-over-TCP on Windows).
Thanks a lot!
(FYI: The bug got accidentally introduced back in version 2012.07.24, when we
added a fix to better handle the disconnection of the remote
Thanks for the report. I have now installed a new version (2012.09.07) that
should fix the problem (with receiving RTP-over-TCP on Windows).
(FYI: The bug got accidentally introduced back in version 2012.07.24, when we
added a fix to better handle the disconnection of the remote end of TCP
soc
Hello.
Don't know why but I cant post in my previous thread so I started another
one.
This is about the openrtsp/live555 problem on windows with the rtp over rtsp
tcp channel.
I've done some debugging and put additional debug output to live555 on
incoming data handling.
Take a look:
:Ski
> In liveMedia/RTSPServer.cpp, on line 1252, there's a multi clause if
> statement that, as formatted, looks like you want it to be evaluated in a
> way that precedence rules say you will get a surprise.
>
> The line looks like this:
> if (streamingMode == RTP_TCP && rtpChannelId == 0xFF ||
>s
> In liveMedia/MP3Internals.cpp, in the member function
> MP3FrameParams::getSideInfo(MP3SideInfo&), there's a var declared named
> i_stereo.
>
> It gets initialized, but never used.
Yes, that variable doesn't need to be there. Thanks.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
In liveMedia/RTSPServer.cpp, on line 1252, there's a multi clause if
statement that, as formatted, looks like you want it to be evaluated in a
way that precedence rules say you will get a surprise.
The line looks like this:
if (streamingMode == RTP_TCP && rtpChannelId == 0xFF ||
streamingMode
I've found a possible 'bug' that might just be an extra variable decl, but
might be a cut'n'paste bug.
In liveMedia/MP3Internals.cpp, in the member function
MP3FrameParams::getSideInfo(MP3SideInfo&), there's a var declared named
i_stereo.
It gets initialized, but never used.
It looks like it mig
> Why are there casts to void* here?
Because I want the 'void*' version of "operator<<" to be used, not the 'char*'
version. I.e., I want the value to the right of "<<" to be printed as a %p,
not as a %s
Once again, not all compiler warning messages indicate bugs.
Ross Finlayson
Live Network
I got several complaints from g++ 4.6 while building.
This is the second one I'm reporting - because it looks like the casts are
not needed.
Why are there casts to void* here?
65 if (frameStart[0] != 0 || frameStart[1] != 0) {
66 envir() << "H263plusVideoRTPSink::doSpecialFrameHandli
Although I can't rule out the possibility of a bug in "H264VideoStreamParser",
I think that your problem is that the buffer used by the "FileSink" object in
the "testH264VideoToTransportStream" demo application was too small for at
least some of the NAL units in your input file. Unfortunately,
Hi,
The H264VideoStreamParser::Parse() method appears to insert additional
0x0001 start codes when the buffered data is greater than the BANK_SIZE and
the fBank[] banks are switched.
Steps to reproduce:
1. Convert a H.264 video such as the Live555 sample slamtv10.264 file
to MPE
> You will need to figure our what about your data is causing the
> parsing to fail. (It is also not inconceivable that our parsing code
> is in error; if so, let is know.)
>
Good. I'll go for it and hopefully let the list know what went wrong.
Thanks for your help!
--
Belloni Cristiano
>Using strace (it's difficult to debug liveMedia with a debugger when
>it's running and sending packets), I found that the library seems to
>block for several seconds on a select(), waiting for three fd,
>corresponding to sockets and then timeout on the select.
This is all a Red Herring. Our base
> > I suggest that you first get your server to stream from a file
>> (containing pre-encoded H.263 video data). Only once you have that
>> working properly, should you move to the more difficult step of
>> streaming from a live encoder.
>
>Did it right now: server sends the prerecorded H263 r
Using strace (it's difficult to debug liveMedia with a debugger when
it's running and sending packets), I found that the library seems to
block for several seconds on a select(), waiting for three fd,
corresponding to sockets and then timeout on the select.
(opens the sockets)
17718 socket(PF_I
>he good news is that because you set "reuseFirstSource" to True,
>this 'close+reopen' will happen only once, regardless of the number
>of ciients that you have. However, it's unavoidable (and not a bug),
>so you're going to have to find a way to live with it.
Ok.
> I suggest that you first g
Cristiano Belloni skrev:
I realize H263plusVideoFileServerMediaSubsession is meant to send H263+
streams, which it does, but I thought H263+ was backwards compatible
with H263.
I'm sorry i cannot answer your full mail, but the H263 and H263+
uses different
format when it is sent over RTP
N
>As I explained in the previous emails, I'm trying to set up an rtsp
>server that streams h263 video, taken from a process that writes the
>stream on a unix named pipe.
I suggest that you first get your server to stream from a file
(containing pre-encoded H.263 video data). Only once you have th
Cristiano Belloni skrev:
I realize H263plusVideoFileServerMediaSubsession is meant to send H263+
streams, which it does, but I thought H263+ was backwards compatible
with H263.
I'm sorry i cannot answer your full mail, but the H263 and H263+ uses
different
format when it is sent over R
Greetings to all,
As I explained in the previous emails, I'm trying to set up an rtsp
server that streams h263 video, taken from a process that writes the
stream on a unix named pipe.
The "encoder" process sets up ffmpeg libraries, takes video frames from
an analog camera and encodes them in h
34 matches
Mail list logo
