Opened 4 years ago

Closed 5 months ago

Last modified 5 months ago

#3732 closed defect (invalid)

ffserver does not perceive closing of input feed

Reported by: andrixnet Owned by:
Priority: normal Component: ffserver
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Having ffserver set up as a streaming server I sometimes encounter the following problem :

Sometimes, but not always, the following happens:

  • ffserver is running, configured to distribute multiple streams
  • one or more feeds are being supplied by ffmpeg encodes
  • any one of the feeds gets cut (either by killing the ffmpeg encoder or by the permanent loss of connection).

even after many hours, ffserver still considers the feed as active and behaves like this:

  • the ffmpeg encoder gets a 404 error
  • ffserver logs this:
Fri Jun 20 13:40:16 2014 Feed '/tmp/rrc.ffm.ffm' already being received
Fri Jun 20 13:40:16 2014 xxxxxxxx - - [GET] "/rrc.ffm HTTP/1.1" 404 158

Other feeds are unaffected.

The only way to solve this is to restart ffserver.
ffmpeg encoders feeding other feeds die. They need to be manually restarted.


ffserver version 2.2.1 Copyright (c) 2000-2014 the FFmpeg developers

built on Apr 30 2014 19:39:58 with gcc 4.8.2 (GCC)
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/doc/ffmpeg-2.2.1 --datadir=/usr/share/ffmpeg --mandir=/usr/man --enable-libmp3lame --enable-libfaac --enable-libvo-aacenc --enable-nonfree --enable-gpl --enable-version3 --enable-avfilter --enable-avresample --enable-libass --enable-libdc1394 --enable-libgsm --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libbluray --enable-libiec61883 --enable-libmodplug --enable-libopenjpeg --enable-libsoxr --enable-libtwolame --enable-frei0r --enable-libquvi --enable-libvidstab --enable-postproc --enable-runtime-cpudetect --enable-vaapi --disable-vdpau --enable-memalign-hack --enable-pthreads --enable-x11grab --enable-bzlib --enable-zlib --enable-shared --enable-static --disable-debug --arch=x86_64 --enable-pic --extra-cflags=-DRUNTIME_CPUDETECT --extra-ldflags='-ldl -lssl -lcrypto -lz -lusb'
libavutil 52. 66.100 / 52. 66.100
libavcodec 55. 52.102 / 55. 52.102
libavformat 55. 33.100 / 55. 33.100
libavdevice 55. 10.100 / 55. 10.100
libavfilter 4. 2.100 / 4. 2.100
libavresample 1. 2. 0 / 1. 2. 0
libswscale 2. 5.102 / 2. 5.102
libswresample 0. 18.100 / 0. 18.100
libpostproc 52. 3.100 / 52. 3.100

Change History (11)

comment:1 Changed 4 years ago by cehoyos

Is this problem reproducible with current FFmpeg git head?

comment:2 Changed 4 years ago by andrixnet

  • Component changed from undetermined to ffserver

This bug I know of since ffmpeg-0.5, I have seen it at version 1.x, at 2.0 and lastly at 2.2.1.

As I am trying to run an automated encoding and distribution solution based on ffmpeg+ffserver, this issue is a significant setback to the reliability factor.

comment:3 Changed 4 years ago by andrixnet

Unfortunately this bug is not easy to reproduce.
I had 3 concurrent streams for 2 days working, starting and stopping any one of them at 1-2 hours intervals. No problems.
Then the next day one in 3-4 source disconnects resulted in the described behaviour.

As I have said, it is an issue I encountered since version 0.5.

My setup is production level and I cannot experiment -current builds on it.
I would have to build a new setup of server machine and encoder to test with latest git head.
This would only happen on the server side, as the encoders are on windows machines due to hardware availability and I do not have the resources to make a windows build. I can use a binary if provided.

Please instruct me what to look for and what information to provide (both at ffserver and encoder side).

comment:4 Changed 4 years ago by cehoyos

Sorry if I was unclear:
The bug reporting guidelines require you to test current FFmpeg git head before report problems, please test and report your results.

comment:5 follow-up: Changed 4 years ago by andrixnet

I understand.

Given the long version history since I've been aware of this bug (and my bad for not reporting it earlier), I am pretty sure I'll find it.

To help me investigate it better, I respectfully ask again for instructions on what to look for and what information to provide (both at ffserver and encoder side).

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

Replying to andrixnet:

I understand.

Good.

Given the long version history since I've been aware of this bug (and my bad for not reporting it earlier), I am pretty sure I'll find it.

Sorry, I don't understand: What you are searching for / trying to find?

Just test if the problem you experience with the version of FFmpeg you tested is also reproducible with current FFmpeg git head.

comment:7 Changed 4 years ago by reynaldo

FWIW I have been trying to reproduce this with current git head to no avail. Will try to automate it to rly knock ffserver down and report back. andrixnet: are you still experiencing this? If so, can you try reproducing with a minimal ffserver.conf and report back? You can keep the push side of things just as you have them now (your windows ffmpeg clients), if this is still a problem is likely the server side the one at fault. If you manage to reproduce please share the config used and the version you are testing with alongside details on the ffserver (ffmpeg) version you reproduced it with.

comment:8 Changed 2 years ago by castg

I have same problem and i'm gonna go crazy. How to reproduce this bug? You shuldn't close the ffmpeg instance. I have a pc that streams with ffmpeg to a ffserver feed in a vps. The problem appears when the ffmpeg connection stops not intentional (internet abruptly cuts).
When FFmpeg streams to that feed again, ffserver return an 404 Not Found and show in log "This feed already being recived".
To restream correctly i should to restart ffserver service and the feed can be used again. And that's the problem. I shouldn't restart ffserver.

Thanks. Sorry my english. I explain the problem also in spanish.

Tengo una PC transmitiendo con ffmpeg a un VPS que tiene ffserver. Transmite a la perfección. Si se corta internet en la pc de transmisión (la del ffmpeg), o se apaga rotundamente (por ejemplo si se queda sin electricidad), el vps con ffserver se tilda. Aquel feed que recibía la transmisión queda colgado y es necesario reiniciar el ffserver para liberar la conexión.

comment:9 Changed 5 months ago by atomnuker

  • Resolution set to invalid
  • Status changed from new to closed

ffserver was removed from git master, closing bug as invalid

comment:10 follow-up: Changed 5 months ago by andrixnet

Will "ffserver" be developed as a separate project from now on?

comment:11 in reply to: ↑ 10 Changed 5 months ago by llogan

Replying to andrixnet:

Will "ffserver" be developed as a separate project from now on?

I doubt it. As far as I know nobody showed any interest in doing so before it got removed. mkvserver_mk2 was mentioned as a possible alternative but I know nothing of that.

Note: See TracTickets for help on using tickets.