[FFmpeg-devel] ffserver: current status and future plans

[Michael Fritscher]

Hello,




1. FATE


"

"
in the Makefile regarding this test?

2. rtsp server


3. ffm
3.1. Using it as a ring buffer.
I think that can be solved rather easy.
3.2. Using it for transfering the streams.
Not that big story either - there are other formats like nut.
3.3. Using it for negotiating the needed video formats.


4. other issues


5. time frame


Best regards,
Michael Fritscher
--
ZfT - Zentrum für Telematik e.V.
Michael Fritscher
Magdalene-Schoch-Straße 5
97074 Würzburg
Tel: +49 (931) 615 633 - 57
Fax: +49 (931) 615 633 - 11
Email: michael.fritsc...@telematik-zentrum.de
Web: http://www.telematik-zentrum.de

Vorstand:
Prof. Dr. Klaus Schilling, Hans-Joachim Leistner
Sitz: Gerbrunn
USt.-ID Nr.: DE 257 244 580, Steuer-Nr.:  257/111/70203
Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167

as promised I started to work on ffserver. The focus of the first week was to remake a fresh building environment - incl. FATE - and get an overview what it is needed to be done. There is already a test for ffserver, but out of FATE. This test does not work for me, but this is a cygwin related problem (wget <blah> | dd bs=1 count=20k : wget isn't exited automatically if dd exits, and because of that the test hangs) Does anybody know more details of the warning Unfortunately ffserver is broken and therefore its regression test fails randomly. Treat the results accordingly. I was told that the rtsp-demuxer can listen now as well. Can this demuxer cope with multiple concurrent connections as well? If not, is this a problem with this demuxer or the demuxer API in general? If the later one I would like to get some advise how to solve this. This is by far(!) the biggest obstacle I found. This is the main cause ffm is plant to be removed I guess (because of the AVCodecContext problem). Additionally, some people doesn't like the idea that ffserver sets the streaming options. Honestly, I personally like this, and there is a ffserver_ignore flag even today. I think that via a new protocol this can be solved. This protocol will be only used to configure the streams of ffmpeg. The other internal includes are less critical I think - rather utility functions etc. Did I miss something? I know that ffserver hinders removal of some internal stuff (most importantly ffm with its usage of AVCodecContext). On IRC, the idea of a deadline popped up. Honestly I like this idea - it would be a clear rule and would avoid a lot of confusion. I propose the 2016-12-31 - if by then the usage of the internal things is not solved ffserver is going to be removed. At least the things which are announced to me by 2016-10-15. I would be more than happy making a detailed list what is to be done - this mail being the first step.

<<attachment: michael_fritscher.vcf>>

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel