[Libav-user] Multicast source is 'lost' on high cpu load

[Roger Pack]

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
<andrey.krieger.utkin at gmail.com> 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
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>