Maybe the kernel is dropping multicast packets before they are delivered to your app?
On Fri, Oct 28, 2011 at 12:24 PM, Andrey Utkin <[email protected]> wrote: > Hi. I use libav* app to transcode a stream that arrives via multicast. > When i overload server CPU, i see that no new frames are read from > av_read_frame. > Stack backtrace shows > > 0x00007f4240084f13 in select () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007f4240084f13 in select () from /lib64/libc.so.6 > #1 0x00007f424065d553 in udp_read (h=0x201c6c0, buf=, size=) > at libavformat/udp.c:565 > #2 0x00007f42405db98c in retry_transfer_wrapper (h=0x201c6c0, > buf=0x202c9e0 "G\037\377\020", size=1472) > at libavformat/avio.c:269 > #3 ffurl_read (h=0x201c6c0, buf=0x202c9e0 "G\037\377\020", size=1472) > at libavformat/avio.c:295 > #4 0x00007f42405de9c6 in fill_buffer (s=0x202d000, buf=0x7fff1c3d0ee0 > "G\037\377\020", size=188) > at libavformat/aviobuf.c:568 > #5 avio_read (s=0x202d000, buf=0x7fff1c3d0ee0 "G\037\377\020", > size=188) at libavformat/aviobuf.c:657 > #6 0x00007f424061cd0b in read_packet (s=0x201c140, buf=0x7fff1c3d0ee0 > "G\037\377\020", > raw_packet_size=188) at libavformat/mpegts.c:1429 > #7 0x00007f424061d866 in handle_packets (ts=0x202d0c0, nb_packets=0) > at libavformat/mpegts.c:1485 > #8 0x00007f424062001a in mpegts_read_packet (s=, pkt=0x7fff1c3d10c0) > at libavformat/mpegts.c:1706 > #9 0x00007f424066463c in av_read_packet (s=0x201c140, > pkt=0x7fff1c3d10c0) at libavformat/utils.c:744 > #10 0x00007f42406660aa in read_frame_internal (s=0x201c140, > pkt=0x7fff1c3d1200) > at libavformat/utils.c:1220 > #11 0x000000000040329c in main (argc=10, argv=0x7fff1c5d1508) at > transcoder.c:383 > (gdb) > > BTW it steps cyclically, not hangs in system call. > > If i restart app after such cpu load peaks, it works correctly. > The issue has nothing to do with source, because if i run several > instances of my app, some of them may 'survive'. > My app is https://github.com/krieger-od/transcoder > I feed it with UDP URL like udp://224.0.0.1:1234 > Is this issue known? > Is the problem introduced by non-ideal reader mechanism implementation > in libavformat? > Can it be fixed soon in libavformat? > Or should i work around it by myself by implementing my own reading > mechanism that'll reconnect on timeout? > > -- > Andrey Utkin > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
