Opened 6 years ago

Closed 6 years ago

#609 closed defect (fixed)

Hang on reading UDP

Reported by: Krieger Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: udp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Sorry for inappropriately forming the report. Time constraints.

The symptoms:
When opening udp:// url with libavformat, and not having explicitly set fifo_size=0, there's a situation when av_read_frame never exits. When attaching with gdb, it shows the following bt (sorry for incompleteness).
I suspect that problem resides in libavformat/udp.c:565 of git HEAD 988f585fcb1cfb40fe4b706c32b31594b536bba0

We can't rely on select() to monitor new data arrival to socket that is recv()'ed by another thread (circular_buffer_task). Even if those socket calls are thread-safe, there's logical flaw.
We are probable to miss the moment of time when new data arrive, and kernel can notify our select() call. We repeatedly select() for 1 second intervals, but between them there's time for event to happen.
Although, this thinking does not answer on question 'why it hangs forever?'

(gdb) bt
#0  0x00007fe62b5def13 in select () from /lib64/
#1  0x00007fe62bbb7553 in udp_read (h=0x145a780, buf=<value optimized out>, size=<value optimized out>)
    at libavformat/udp.c:569
#2  0x00007fe62bb3598c in retry_transfer_wrapper (h=0x145a780, buf=0x146aaa0 "G\037\377\020", size=1472)
    at libavformat/avio.c:269
#3  ffurl_read (h=0x145a780, buf=0x146aaa0 "G\037\377\020", size=1472) at libavformat/avio.c:295
#4  0x00007fe62bb389c6 in fill_buffer (s=0x146b0c0, buf=0x7fffce573430 "G\037\377\020", size=188)
    at libavformat/aviobuf.c:568
#5  avio_read (s=0x146b0c0, buf=0x7fffce573430 "G\037\377\020", size=188) at libavformat/aviobuf.c:657
#6  0x00007fe62bb76d0b in read_packet (s=0x145a200, buf=0x7fffce573430 "G\037\377\020", 
    raw_packet_size=188) at libavformat/mpegts.c:1429
#7  0x00007fe62bb77866 in handle_packets (ts=0x146b180, nb_packets=0) at libavformat/mpegts.c:1485
#8  0x00007fe62bb7a01a in mpegts_read_packet (s=<value optimized out>, pkt=0x7fffce573610)
    at libavformat/mpegts.c:1706
#9  0x00007fe62bbbe66c in av_read_packet (s=0x145a200, pkt=0x7fffce573610) at libavformat/utils.c:744
#10 0x00007fe62bbc00da in read_frame_internal (s=0x145a200, pkt=0x7fffce573750)
    at libavformat/utils.c:1220

Change History (6)

comment:1 Changed 6 years ago by brazilbrown

I also am seeing this issue. Although, av_read_frame does not hang forever, it eventually returns, but far too late to be useful. Is there a known workaround for this issue besides setting fifo_size to 0? I find that if I set fifo_size to 0, I lose a lot more data (obviously) and therefore I need a buffer of some kind. Any help would be appreciated.

comment:2 follow-up: Changed 6 years ago by Krieger

There is buffer_size option for that :)

comment:3 in reply to: ↑ 2 Changed 6 years ago by brazilbrown

Replying to Krieger:

There is buffer_size option for that :)

Thanks for the help, but buffer_size seems to have no effect. When I use the udpx.x.x.x:x?fifo_size=0, I get a whole lot off decoding errors (but no hangs). Adding a buffer_size of 5373952 (18 times the default) to the input path didn't change that.

Do you know if this is a recent bug, or has this been a problem for a while? I've tried previous versions of ffmpeg, and still get the same error, so I suspect this bug has been a problem for a while.

comment:4 Changed 6 years ago by michael

is this issue still reproduceable ? there is no select() in udp.c anymore

comment:5 Changed 6 years ago by Krieger

I think this bug was eliminated a couple of months ago, and iirc even by your changes. I don't have the environment to test this now, though.

comment:6 Changed 6 years ago by cehoyos

  • Keywords udp added
  • Resolution set to fixed
  • Status changed from new to closed

Please reopen if this is still reproducible.

Note: See TracTickets for help on using tickets.