Opened 3 years ago

Last modified 21 months ago

#3313 reopened defect

ffmpeg can't receive the UDP multicasted MPEGTS streams

Reported by: mrxwh Owned by:
Priority: important Component: avformat
Version: git-master Keywords: udp deadlock
Cc: ben@bbarker.co.uk Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

the command"ffmpeg -i 'udp://226.22.111.135:5001?localaddr=127.29.3.89&localport=1234&fifo_size=1000000&overrun_nonfatal=1' -f mpegts out.ts" is hanged up with the following information,there is none else. the ip "127.29.3.89" is the local ip,the the udp data is transported through it.

[root@cncodec89 transcode_20131203]# ffmpeg -i 'udp://226.22.111.135:5001?localaddr=127.29.3.89&localport=1234&fifo_size=1000000&overrun_nonfatal=1' -f mpegts out.ts
ffmpeg version 2.1.1 Copyright (c) 2000-2013 the FFmpeg developers

built on Jan 17 2014 12:30:02 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)
configuration: --prefix=/usr/local --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --bindir=/usr/local/bin --extra-libs=-ldl --enable-pthreads --enable-gpl --enable-nonfree --enable-libfdk_aac --enable-libx264 --enable-shared --enable-libmp3lame --enable-debug --disable-asm --enable-ffplay
libavutil 52. 48.101 / 52. 48.101
libavcodec 55. 39.101 / 55. 39.101
libavformat 55. 19.104 / 55. 19.104
libavdevice 55. 5.100 / 55. 5.100
libavfilter 3. 90.100 / 3. 90.100
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100

Change History (18)

comment:1 Changed 3 years ago by mrxwh

by the way,I added -v 9 -loglevel 99 for more information, the following information can be found.

[root@cncodec89 transcode_20131203]# ffmpeg -i 'udp://226.22.111.135:5001?localaddr=127.29.3.89&localport=1234&fifo_size=1000000&overrun_nonfatal=1' -f mpegts out.ts -v 9 -loglevel 99
ffmpeg version 2.1.1 Copyright (c) 2000-2013 the FFmpeg developers

built on Jan 17 2014 12:30:02 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)
configuration: --prefix=/usr/local --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --bindir=/usr/local/bin --extra-libs=-ldl --enable-pthreads --enable-gpl --enable-nonfree --enable-libfdk_aac --enable-libx264 --enable-shared --enable-libmp3lame --enable-debug --disable-asm --enable-ffplay
libavutil 52. 48.101 / 52. 48.101
libavcodec 55. 39.101 / 55. 39.101
libavformat 55. 19.104 / 55. 19.104
libavdevice 55. 5.100 / 55. 5.100
libavfilter 3. 90.100 / 3. 90.100
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100

Splitting the commandline.
Reading option '-i' ... matched as input file with argument 'udp://226.22.111.135:5001?localaddr=127.29.3.89&localport=1234&fifo_size=1000000&overrun_nonfatal=1'.
Reading option '-f' ... matched as option 'f' (force format) with argument 'mpegts'.
Reading option 'out.ts' ... matched as output file.
Reading option '-v' ... matched as option 'v' (set logging level) with argument '9'.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument '99'.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option v (set logging level) with argument 9.
Successfully parsed a group of options.
Parsing a group of options: input file udp://226.22.111.135:5001?localaddr=127.29.3.89&localport=1234&fifo_size=1000000&overrun_nonfatal=1.
Successfully parsed a group of options.
Opening an input file: udp://226.22.111.135:5001?localaddr=127.29.3.89&localport=1234&fifo_size=1000000&overrun_nonfatal=1.

comment:2 Changed 3 years ago by cehoyos

  • Component changed from FFmpeg to undetermined
  • Keywords ffmpeg removed
  • Priority changed from critical to normal

If you want to report that ffmpeg hangs (does it really or did you just stop waiting?), please provide a backtrace.

Please test current git head.

comment:3 follow-up: Changed 3 years ago by mrxwh

I tested it with ffmpeg-2.1.1 and ffmpeg-2.0,both of them doesn't work.

I traced with the following codes

static int udp_read(URLContext *h, uint8_t *buf, int size)
{

UDPContext *s = h->priv_data;
int ret;
int avail, nonblock = h->flags & AVIO_FLAG_NONBLOCK;


#if HAVE_PTHREAD_CANCEL

if (s->fifo) {

pthread_mutex_lock(&s->mutex);
do {

avail = av_fifo_size(s->fifo);
printf("udp_read: avail=%d\n",avail);

.......................
}

the printed result shows "udp_read: avail=0"

It looks like there is no UDP data captured.

Best Regards!

comment:4 in reply to: ↑ 3 Changed 3 years ago by cehoyos

Replying to mrxwh:

I tested it with ffmpeg-2.1.1 and ffmpeg-2.0,both of them doesn't work.

Please test current git head to make this a valid ticket - as explained on http://ffmpeg.org/bugreports.html

And please consider providing a backtrace.

comment:5 Changed 3 years ago by mrxwh

  • Component changed from undetermined to avformat
  • Priority changed from normal to critical
  • Version changed from 2.1.3 to git-master

comment:6 Changed 3 years ago by cehoyos

  • Priority changed from critical to normal
  • Resolution set to needs_more_info
  • Status changed from new to closed

Please reopen the ticket if you can provide the missing information.

comment:7 follow-up: Changed 3 years ago by dbrb2

I seem to be able to replicate this on a version of ffmpeg built from master last week. I can't immediately revuild from todays master - is this recent enough?

ffmpeg version N-60232-gfbafd64 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 2 2014 16:34:03 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)

ffmpeg -loglevel debug -i "udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222"
ffmpeg version N-60232-gfbafd64 Copyright (c) 2000-2014 the FFmpeg developers

built on Feb 2 2014 16:34:03 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)
configuration: --enable-libfreetype --enable-libtheora --enable-libvpx --enable-libvorbis --enable-gpl --enable-nonfree --enable-pthreads --enable-libx264 --enable-libfaac --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib
libavutil 52. 63.100 / 52. 63.100
libavcodec 55. 49.101 / 55. 49.101
libavformat 55. 28.101 / 55. 28.101
libavdevice 55. 7.100 / 55. 7.100
libavfilter 4. 1.101 / 4. 1.101
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100

Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
Reading option '-i' ... matched as input file with argument 'udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222&buffer_size=65535'.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input file udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222&buffer_size=65535.
Successfully parsed a group of options.
Opening an input file: udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222&buffer_size=65535.
[udp @ 0x134336e0] end receive buffer size reported is 131070
...
...
..
.
hangs here

Running tshark seems to confirm that the stream has not been joined

comment:8 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by cehoyos

Replying to dbrb2:

I seem to be able to replicate this on a version of ffmpeg built from master last week.

I can't immediately revuild from todays master - is this recent enough?

(Why not?)

ffmpeg -loglevel debug -i "udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222"

hangs here

Please provide a backtrace.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by dbrb2

Sorry - I was away from a machine I could do it on. I have now rebuilt from master:

ffmpeg version N-60500-g6421111 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 10 2014 13:59:44 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)

The problem manifests as described above.

Sorry to ask a basic question, but how would I provide a backtrace?

comment:10 in reply to: ↑ 9 Changed 3 years ago by cehoyos

Replying to dbrb2:

Sorry to ask a basic question, but how would I provide a backtrace?

Start the debugger with the ffmpeg debug build:
$ gdb ffmpeg_g
Then start the failing command:
(gdb) r -i "udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222"
If ffmpeg hangs, press Ctrl-C and type "bt" to get a backtrace.

This is also documented on http://ffmpeg.org/bugreports.html

comment:11 Changed 3 years ago by dbrb2

ffmpeg version N-60500-g6421111 Copyright (c) 2000-2014 the FFmpeg developers

built on Feb 10 2014 13:59:44 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)
configuration: --enable-libfreetype --enable-libtheora --enable-libvpx --enable-libvorbis --enable-gpl --enable-nonfree --enable-pthreads --enable-libx264 --enable-libfaac --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib
libavutil 52. 63.101 / 52. 63.101
libavcodec 55. 50.100 / 55. 50.100
libavformat 55. 31.100 / 55. 31.100
libavdevice 55. 8.100 / 55. 8.100
libavfilter 4. 1.102 / 4. 1.102
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100

[New Thread 0x2aaaabfcc940 (LWP 3802)]

Program received signal SIGINT, Interrupt.
0x0000003cafe0b280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
(gdb) bt
#0 0x0000003cafe0b280 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x000000000057d315 in udp_read (h=0x1c89740, buf=0x1c99b80 "", size=65536) at libavformat/udp.c:809
#2 0x00000000004bf2d1 in retry_transfer_wrapper (h=0x1c89740, buf=0x1c99b80 "", size=65536) at libavformat/avio.c:289
#3 ffurl_read (h=0x1c89740, buf=0x1c99b80 "", size=65536) at libavformat/avio.c:320
#4 0x00000000004bfe15 in fill_buffer (s=0x1ca9be0) at libavformat/aviobuf.c:435
#5 0x00000000004c00ec in avio_read (s=0x1ca9be0, buf=0x1ca9cc0 "", size=2048) at libavformat/aviobuf.c:516
#6 0x00000000005839fe in av_probe_input_buffer2 (pb=0x1ca9be0, fmt=0x1c89108, filename=<value optimized out>, logctx=0x1c89100, offset=0, max_probe_size=1048576) at libavformat/utils.c:388
#7 0x0000000000588aab in init_input (ps=0x7fffffffe1c8, filename=0x7fffffffeaa7 "udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222", fmt=0x0, options=0x1c818f8) at libavformat/utils.c:473
#8 avformat_open_input (ps=0x7fffffffe1c8, filename=0x7fffffffeaa7 "udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222", fmt=0x0, options=0x1c818f8) at libavformat/utils.c:535
#9 0x0000000000412487 in open_input_file (o=0x7fffffffe240, filename=0x7fffffffeaa7 "udp://10.163.18.222:5004?reuse=1&include=1&sources=10.163.18.222") at ffmpeg_opt.c:844
#10 0x000000000040c795 in open_files (l=0x1c7a0d8, inout=0xe26bff "input", open_file=0x4120e0 <open_input_file>) at ffmpeg_opt.c:2587
#11 0x000000000040c9d3 in ffmpeg_parse_options (argc=<value optimized out>, argv=0x7fffffffe838) at ffmpeg_opt.c:2624
#12 0x000000000042151d in main (argc=3, argv=0x7fffffffe840) at ffmpeg.c:3574

comment:12 Changed 3 years ago by dbrb2

  • Cc ben@bbarker.co.uk added
  • Resolution needs_more_info deleted
  • Status changed from closed to reopened

comment:13 Changed 21 months ago by liberus

So what's the state of this bug? I'm able to reproduce it sometime using QtAV player(and I investigated it deep enough that it's obviously not QtAV fault). Maybe I'll be able to add some missing details?

comment:14 Changed 21 months ago by cehoyos

  • Keywords deadlock added
  • Priority changed from normal to important

Do you see the same backtrace?

comment:15 Changed 21 months ago by liberus

No, Maybe I'm facing different bug, in my case call to avformat_open_input fails with return code -5. I'm also using udp point to point streaming from grabbing device(screen-capture-recorder). This problem occurs only ~1 out of 10 cases.

comment:16 Changed 21 months ago by cehoyos

So you do not see any kind of hang?

comment:17 Changed 21 months ago by liberus

No, sorry. Looks like it's different bug, I misread description.
So, should I report it elsewhere?

comment:18 Changed 21 months ago by kierank

(For the original reporter)
If it's on Linux, look into reverse path filtering - this is a feature of the kernel that blocks multicast from addresses from which there is no route.

Note: See TracTickets for help on using tickets.