There is no need to write two HTTP newlines (\r\n) into "headers",
because http_connect (in http.c) already appends one HTTP newline at
the end of the given headers chunk, which would result in sending
three HTTP newlines after the headers. Most of the time it's okay
(although not RFC-conforming), but many proxy servers and the
occasional strict httpd will puke with a "400 bad request".
In this case, the string that was passed couldn't contain
user-defined data and thus there was no risk for injection
bugs, but it's safer this way, if we later change the
content of the options string.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
ac3enc: use correct alignment and length in channel coupling dsp functions.
ffmpeg: don't abuse a global for passing framerate from input to output
ffmpeg: don't abuse a global for passing channels from input to output
ffmpeg: don't abuse a global for passing samplerate from input to output
ARM: update ff_h264_idct8_add4_neon for 4:4:4 changes
swscale: use SwsContext for av_log when available
swscale: Remove HAVE_MMX from files that are only compiled with MMX enabled.
swscale: Fix compilation with --disable-mmx2.
Conflicts:
ffmpeg.c
libswscale/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
swscale: remove misplaced comment.
ffmpeg: fix streaming to ffserver.
swscale: split out RGB48 output functions from yuv2packed[12X]_c().
build: move vpath directives to main Makefile
swscale: fix JPEG-range YUV scaling artifacts.
build: move ALLFFLIBS to a more logical place
ARM: factor some repetitive code into macros
Fix SVQ3 after adding 4:4:4 H.264 support
H.264: fix CODEC_FLAG_GRAY
4:4:4 H.264 decoding support
ac3enc: fix allocation of floating point samples.
Conflicts:
ffmpeg.c
libavcodec/dsputil_template.c
libavcodec/h264.c
libavcodec/mpegvideo.c
libavcodec/snow.c
libswscale/swscale.c
libswscale/swscale_internal.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is part of the Great Evil Plan to simplify swscale. Note that
you'll see some code duplication between the output functions for
different RGB variants, and even between packed-YUV and RGB
variants. This is intentional because it improves readability.
The H.264 parser that we use to detect interlacing can only handle
an Annex B stream, so we need to actually use the filter. This is
unfortunate as the crystalhd library is already doing this conversion
internally. A future change will reorganise the decode path more
completely so that we can feed the converted stream into libcrystalhd
and avoid the second conversion.
Signed-off-by: Philip Langdale <philipl@overt.org>
In preparation for using the filter on the actual bitstream, we need
to extend it's lifetime to match that of the decoder.
Signed-off-by: Philip Langdale <philipl@overt.org>
