<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>also in  udp.c change MAX_PACKET_SIZE , works fine</span></div><div></div><div> </div><div>Kenan Aksoy<br><blockquote style="padding-left: 5px; margin-left: 5px; border-left-color: rgb(16, 16, 255); border-left-width: 2px; border-left-style: solid;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font size="2" face="Arial"><div style="margin: 5px 0px; padding: 0px; border: 1px solid rgb(204, 204, 204); height: 0px; line-height: 0; font-size: 0px;" class="hr" contentEditable="false" readonly="true"></div><b><span style="font-weight: bold;">From:</span></b> Luke Clemens <lclemens@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> "This list is about using libavcodec,
 libavformat, libavutil, libavdevice and libavfilter." <libav-user@ffmpeg.org><br><b><span style="font-weight: bold;">Sent:</span></b> Friday, 15 July 2011, 1:10<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Libav-user] RTP/RTSP support in FFMPEG<br></font><br>I did a diff with an old version of rtpdec.c and a new version (the<br>old on has the timeout problem but it doesn't get mpeg4 errors). They<br>are very different - it's almost a complete rewrite. The code is<br>difficult to follow (well for me anyway, coming from an object<br>orientated C++ point of view). Also, I'm not an RTP expert so I need<br>to give myself a crash course with RFC3550 documentation and<br>wikipedia.<br><br>I tried setting the queue size (which was defaulting to zero). That<br>can be done in ffplay using something like -max_delay 500000. After<br>doing that I can now see that lots of packets are being dropped. My<br>next thought was that maybe the
 decoding was too slow so the socket<br>wasn't able receive fast enough. So I commented out the decoding<br>portion. Now I have a loop that's basically reading as fast as<br>possible and doing nothing with the frame.<br><br>while (1) {<br>     av_read_frame(ctx, pkt);<br>}<br><br>I set the log level to debug using av_set_log_level(AV_LOG_DEBUG).<br>Even without decoding there one or two bright yellow warnings every<br>second or so that look like:<br><br>[mpeg4 @ 0037b6a0] RTP: missed 3 packets<br>[pcm_mulaw @ 0037d980] RTP: missed 5 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 1 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 1 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 2 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 1 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 3 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 1 packets<br>[pcm_mulaw @ 0037d980] RTP: missed 3 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 1 packets<br>[mpeg4 @ 0037b6a0] RTP: missed 1 packets<br>[mpeg4 @
 0037b6a0] RTP: missed 4 packets<br><br>I'm almost positive that the "drops" are not due to network or<br>hardware. The AXIS mpeg4 camera I'm testing with is plugged into the<br>same gigabit switch as my PC and I've sent WAY higher bandwidth RTP<br>streams through without any problems. Also, the older version of<br>libavformat didn't have this issue, nor does live555 which VLC uses.<br><br>Those warnings come from the rtp_parse_queued_packet() function in<br>rtpdec.c. It throws the warning when the following packet's sequence<br>number isn't the current sequence number plus one. Unless I'm missing<br>something, the rtp parsing code doesn't appear to account for packets<br>coming in out of order. Perhaps the AXIS and Panasonic cameras have a<br>problem sending packets in order? But if that were the case, I would<br>think the older versions of libavformat wouldn't have worked.  Wish I<br>knew the guy who wrote this code because he would understand it
 much<br>better...<br><br>The rtp_parse_queued_packet() function gets called by<br>ff_rtsp_fetch_packet() in rtsp.c, which is called by<br>rtsp_read_packet() in rtspdec.c.<br><br>The socket reading code occurs in ffurl_read(), which calls<br>retry_transfer_wrapper(), which calls transfer_func(), which calls a<br>callback in the URLContext structure, which performs udp_read(), which<br>calls recv() on a socket.<br><br>At this point, I don't know if the problem is in the rtsp decoder, or<br>if it's an issue with the actual UDP socket reading. If other UDP<br>transport protocols work, then that probably means it's not the UDP<br>reading at fault.<br><br>I also have a headache... :-)<br><br>This would be easier if I could get ffmpeg working with a visual<br>debugger. I tried it with Qt Creator in Ubuntu but ran into problems.<br>Does anyone know where I can find a tutorial or something on how to<br>visually debug libavformat or ffmpeg? I don't care if it's
 qt creator,<br>eclipse or visual studio - as long as I can step into ffmpeg<br>functions.<br><br>--luke<br>_______________________________________________<br>Libav-user mailing list<br><a href="mailto:Libav-user@ffmpeg.org" ymailto="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br><a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br><br><br></div></div></blockquote></div></div></body></html>