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

[Andrey Utkin]

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