I've had a chance to test this change, and everything still seems to
work OK for me (I use the RTSPClient to pull directly from a Live555
on-demand server; I also use the darwin push code, which uses the
RTSPClient internally). How do you want the patch?
A regular 'patch'-format file (e.g., p
OK, I have now installed a new version (2010.01.22) of the software
that should fix this problem.
Note to Rob Krakora and Alex Nemec: Please download and test this, to
see whether it works OK (and still avoids getting any "select()"
errors). I can't test it myself.
Important note: As a res
On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson wrote:
> Looking at the original patch, it's pretty clear that the author forgot to
>> set the socket back to be blocking. But considering that this issue has
>> been present for well over a year, I have to wonder whether or not the
>> RTSPClient ev
I am not sure if the live555 support redundant AMR frames in RTP
streams. I don't see such code in the live555 lib. So if the SDP
contains max-red >0, how does the RTSP client react such RTP stream?
We don't recognize the "max-red" parameter, but our receiving code
("AMRAudioRTPSource") *might
I want to test the RTSP client on the all kinds of possible formates
of the RTP AMR payload. But I can not find the testing resource
which can generate the desired RTP stream used for this testing. I
want to know how did you perform such test?
I can't remember, but I think I found some publica
Hi Experts,
I am not sure if the live555 support redundant AMR frames in RTP streams. I
don't see such code in the live555 lib. So if the SDP contains max-red >0, how
does the RTSP client react such RTP stream?
Attach is the description on max-red in SDP described in RFC4867, section 8:
max-red
