Hi experts,
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? The RTSP server can only generate the s
Thanks Ross.
I now do see that there is a while loop in the
MultiFramedRTPSource::doGetNextFrame1 and the
BufferedPacket::use is used in the loop to travers all the frames in the single
packet unitl this packet is used out.
Also the afterGetting(this) is called in this loop to ensure that " eac
Ross:
No multicast packets are received with the 2010-01-15 version for which you
provided the fix. I looked at the TCP/IP stack source and it appears that
once a socket is bound it cannot be rebound. As a test I commented out the
'bind' code block in the setupDatagramSocket() function in the
"G
My bad,
SO_REUSEADDR allows binding to an address that is in a TIME_WAIT state while
SO_REUSEPORT allows multiple processes to bind to the same address. This
has nothing to do with rebinding...I will keep looking...
On Thu, Jan 21, 2010 at 10:58 AM, Robert Krakora wrote:
> Ross:
>
> It looks li
Ross:
It looks like kernel 2.6.18-128.1.10.el5 utilized in CentOS 5.3 does not
implement SO_REUSEPORT (see commented out SO_REUSEPORT below from "socket.h"
file for this kernel and the comment about it's needed implementation in *bold
red*). Otherwise I believe your fix would have worked. I did
Ross:
I will debug this and let you know what is going on. Multicast data was
arriving per Wireshark. However, I did not capture the RTSP traffic...I
cannot see the video as the location is remote. It was bad judgement on my
part to indicate to you that it was working prematurely. I will have
Have someone tested the functions used to deinterleave multi AMR
frames in a single RTP packet? Here I have a question on the method
AMRDeinterleave::deliverIncomingFrame.
I suspect this method can only support the scenario that one RTP
packet contains only one AMR frame.
No. Although our cur
