When the command line for children is created, it is assumed that
my_program_name always ends with "ffserver", which doesn't have to
be true if ffserver is called through a symbolic link.
In such a case, it could be that not enough space for "ffmpeg" is
available at the end, leading to a buffer overflow.
One example would be:
$ ln -s /usr/bin/ffserver ~/f; ~/f
As this is only a local buffer overflow, i.e. is based on a weird
program call, this has NO security impact.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes producing swf and rm files as done by ffservertest.
Reviewed-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This should not be needed, our AVParsers should do this
I do not have a testcase though, please help testing this and please
add fate tests if you can.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes null pointer dereference
Testcase is simply a ffmpeg instance sending a stream to ffserver while another ffmpeg reads from it
This reverts commit 6f0a1710d7.
AVStream.codec is deprecated
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVStream.codec is deprecated
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVStream.codec is deprecated
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVStream.codec is deprecated
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVStream.codec is deprecated
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Compare using AVCodecParameters instead of the deprecated
AVStream.codec field
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I discovered that ffserver streaming was broken (it seems like it has been since 20th November) and I opened a ticket for this (https://trac.ffmpeg.org/ticket/5250 <https://trac.ffmpeg.org/ticket/5250>).
I spent yesterday learning git bisect (with the kind help of cehoyos) to painstakingly track down the cause. This was made more difficult due to the presence of a segfault in ffserver during the period where the bug was introduced so I first had to identify when and how that was fixed and then retrospectively apply that fix again for each step of the second git bisect to find the actual bug.
Anyway, the fruits of my labour are the innocent looking patch below to correct a couple of typos and define a valid range for two variables.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes weirdness like our "??filename? not found" 404.
None of the chars being used from the previously blacklisted
list needs to be scaped on an UTF-8 document context
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
* Avoid excesive nesting that made it really hard to follow
* Drop unneeded vars
* Factor out codec compatibility check routine
* Ensure inputs are closed and contexts are freed as needed
before returning
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Exit from main on build_feed_streams() failures & use
standard EXIT_ codes on error out/normal exit.
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Avoids segfault at init_muxer() (mux.c) due to a
null pointer dereference on the recently
introduced AVStream->internal
Fixes: #5059 (https://trac.ffmpeg.org/ticket/5059)
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Fixes: ==13287== Invalid read of size 4
==13287== at 0x45161A: flush_buffer (aviobuf.c:143)
==13287== by 0x451971: avio_flush (aviobuf.c:200)
==13287== by 0x512CCF: av_write_trailer (mux.c:1016)
==13287== by 0x41A5E0: close_connection (ffserver.c:853)
==13287== by 0x421EDC: rtsp_cmd_interrupt (ffserver.c:3245)
==13287== by 0x420B9C: rtsp_parse_request (ffserver.c:2854)
==13287== by 0x41A9C2: handle_connection (ffserver.c:930)
==13287== by 0x41A04B: http_server (ffserver.c:700)
==13287== by 0x423A60: main (ffserver.c:3897)
==13287== Address 0xb6cd258 is 88 bytes inside a block of size 192 free'd
==13287== at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==13287== by 0x1004DAC: av_free (mem.c:239)
==13287== by 0x454835: avio_close_dyn_buf (aviobuf.c:1170)
==13287== by 0x41F385: http_prepare_data (ffserver.c:2368)
==13287== by 0x41F59B: http_send_data (ffserver.c:2416)
==13287== by 0x41ABE2: handle_connection (ffserver.c:986)
==13287== by 0x41A04B: http_server (ffserver.c:700)
==13287== by 0x423A60: main (ffserver.c:3897)
Reviewed-by: "Reynaldo H. Verdejo Pinochet" <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
server_attached is newly added so the demuxer knows if there is an attached server
that can update the write index. This is needed to fix a infinite loop
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Somewhat ironic that this "safe" interface is actually being used
unsafely here. This fixes the usage preventing potential null pointer
dereference, where the old code was doubly broken: ctime can return
NULL, and ctime can return an arbitrarily long buffer.
Reviewed-by: Mark Harris <mark.hsj@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
