<DIV>Hello,</DIV>
<DIV> I can't answer your questions, but I have some suggestions.</DIV>
<DIV> First, making sure your stream is good with UDP client and server.Maybe the problem does not come from RTP.</DIV>
<DIV> Second, your test program must run in the simplest net environment.</DIV>
<DIV> Third, you must know the problem come from which side- receiver or sender or both of them.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV ></DIV><BR>在2007-02-13，xcsmith@rockwellcollins.com 写道：<BR>
<BLOCKQUOTE style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><PRE>Hello!
I hope you will please help me figure out the reason I am losing RTP
packets when recording a live stream. The RTCP of my openRTSP reports
packet loss (I'm using ethereal to look at this). My recorded video also
shows large chunks of missing data and freezes. When I use VLC to play the
recorded video, VLC messages say "buffer underrun" every time the video
freezes. So I think that somehow I am losing RTP packets. When I play the
video live using VLC as an RTSP client, the video is fine.
It seems that about every 30 - 40 seconds, a large number of packets are
dropped. I thought this was happening every time the packet reorder
threshold is reached, but now I'm not quite so sure of this. I tried
increasing the wait threshold to 40 seconds and the RTP socket buffer in
MultiFramedRTPSource to 100 MB (which I see is successfully changed). I
have varied the wait threshold to 1, 2, 20 and 40 seconds. I also used the
default 100ms.
I have tried the following things to figure out the cause of lost packets.
1. In ReorderingPacketBuffer::getNextCompletedPacket() print debug
statement any time fHeadPacket->rtpSeqNo() != fNextExpectedSeqNo. I got
quite a lot of printout from this statement. I printed both the head
packet and the expected sequence number. I checked ethereal, and the
missing seq no. packets had been sent to me. Later I removed this and just
print a single statement any time the "packetLossPreceded" was set to true.
2. Add printf to MultiframedRTPSource::networkReadHandler() for each case
in which an RTP packet could be discarded before being stored in
fReorderingBuffer. None of my RTP packets seem to be invalidated before
being stored.
3. Add printf to MultiframedRTPSource::networkReadHandler() to show if
fReorderingBuffer->storePacket fails. No failures reported.
4. Comment out using MPEG2TransportStreamFramer in MediaSession.cpp. It
doesn't seem to make much of a difference whether or not
MPEG2TransportStreamFramer is used or if the RTPSource goes directly to
FileSink.
5. In ReorderingPacketBuffer::storePacket() print debug statement any time
we see a late packet. No late packets noted.
I also notice that the RTP packets sent to me all have an RTPTime of 0.
Ethereal I/O graph shows my data rate to be about 4 Mbps. My host computer
is on a private network with 1 other computer and 2 embedded computers
which are used as RTSP servers or clients. I can't see how it's possible
for network packets to be 30 - 40 seconds late on this private network, but
I see that LIVE acts as though this is happening.
Can you point me to a part of the code to look at for these RTP packet
losses? Any ideas for me? Thank you!
Xochitl
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
</PRE></BLOCKQUOTE><br><!-- footer --><br><hr>
<a style="font-size:12px;line-height:15px; color:#000; text-decoration:none" href="http://www.126.com/" target="_blank">想加入吗？1.9亿用户正在使用网易邮箱 <span style="font-family:Tahoma; text-decoration:underline; color:blue">www.126.com</span> </a>