[FFmpeg-trac] #5971(ffserver:new): ffserver: Segmentation fault when streaming RTSP with ffserver (Always)
FFmpeg
trac at avcodec.org
Mon Nov 21 17:17:27 EET 2016
#5971: ffserver: Segmentation fault when streaming RTSP with ffserver (Always)
-------------------------------------+-------------------------------------
Reporter: smartzzz | Type: defect
Status: new | Priority: critical
Component: ffserver | Version: git-
Keywords: ffserver | master
SIGSEGV | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
When I try to stream a video via ffserver, it always terminate with
Setmentation fault due to NULL pointer access.
I run ffserver with following configuration.
#Server configuration
--------------------------------
HTTPPort 8090
HTTPBindAddress 0.0.0.0
RTSPPort 8091
RTSPBindAddress 0.0.0.0
MaxClients 1000
MaxBandwidth 10000
CustomLog -
<Feed feed1.ffm>
File /tmp/feed1.ffm
ACL Allow 127.0.0.1
</Feed>
<Stream test1.mp4>
Feed feed1.ffm
Format rtp
VideoFrameRate 30
VideoBitRate 5000
VideoSize 640x480
VideoQMin 3
VideoQMax 31
NoAudio
NoDefaults
</Stream>
And run ffmpeg in order to send video feed to server as follows.
# ffmpeg -f v4l2 -s 640x480 -r 30 -i /dev/video0
http://localhost:8090/feed1.ffm
Whenever I played this stream on remote PC, ffserver always terminates
with Segmentation fault.
#GDB information
Program received signal SIGSEGV, Segmentation fault.
0xb5cf9e38 in memcpy (__len=<optimized out>, __src=<optimized out>,
__dest=<optimized out>) at /usr/include/bits/string3.h:53
53 return __builtin___memcpy_chk (__dest, __src, __len, __bos0
(__dest));
(gdb) bt
#0 0xb5cf9e38 in memcpy (__len=<optimized out>, __src=<optimized out>,
__dest=<optimized out>) at /usr/include/bits/string3.h:53
#1 av_freep (arg=0xc) at libavutil/mem.c:248
#2 0xb6182a86 in codec_parameters_reset (par=par at entry=0x0)
at libavcodec/utils.c:4022
#3 0xb618876a in avcodec_parameters_from_context (par=0x0,
codec=0x7f5f7900)
at libavcodec/utils.c:4082
#4 0x7f5b9848 in prepare_sdp_description (stream=0x7f5f63c0,
pbuffer=0xbea2db74, my_ip=...) at ffserver.c:2999
#5 0x7f5ba9e6 in rtsp_cmd_describe (
url=0xbea2f8c4 "rtsp://12.23.66.28:8091/test1.mp4", c=0x7f600a00)
at ffserver.c:3059
#6 rtsp_parse_request (c=0x7f600a00) at ffserver.c:2935
#7 0x7f5b2092 in handle_connection (c=0x7f600a00) at ffserver.c:1008
#8 http_server () at ffserver.c:777
#9 main (argc=<optimized out>, argv=<optimized out>) at ffserver.c:4032
From running git bisect, I found that below commit cause this issue.
commit 9200514ad8717c63f82101dc394f4378854325bf
Author: Anton Khirnov <anton at khirnov.net>
Date: Wed Jun 18 20:42:52 2014 +0200
lavf: replace AVStream.codec with AVStream.codecpar
Currently, AVStream contains an embedded AVCodecContext instance,
which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding
(when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer
allowed to
read. This leads to erratic behaviour depending on whether
decoding or
encoding is being performed or not (and whether it uses the
AVStream
embedded codec context).
- various synchronization issues arising from the fact that the
same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders)
simultaneously, with
there being no clear rules for who can modify what and the
different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support
opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects
in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores
only
the stream parameters exported by the demuxers or read by the muxers.
This issue is same with https://trac.ffmpeg.org/ticket/5869
--
Ticket URL: <https://trac.ffmpeg.org/ticket/5971>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list