* qatar/master:
libvpxenc: use the default bitrate if not set
utvideo: Rename utvideo.c to utvideodec.c
doc: Fix syntax errors in sample Emacs config
mjpegdec: more meaningful return values
configure: clean up Altivec detection
getopt: Remove an unnecessary define
rtmp: Use int instead of ssize_t
getopt: Add missing includes
rtmp: Add support for receiving incoming streams
Add missing includes for code relying on external libraries
Conflicts:
libavcodec/libopenjpegenc.c
libavcodec/libvpxenc.c
libavcodec/mjpegdec.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
There used to be one test for Altivec intrinsics support and a
separate test to determine which of two possible syntaxes to use
for vector literals. Since 2008, we only support the more common
of these so the split test no longer makes sense.
This combines the tests into one and also changes the hard error on
failure to a warning. The test can reasonably fail if no --cpu flag
is provided (or is provided with an unknown CPU) and the compiler
default target does not support Altivec. Aborting in this case is
probably over-reacting.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This function is problematic in several ways, its also quite
unpredictable which flags it ends up turning on
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Not all compilers support ssize_t (MSVC doesn't), and none of these
variables need to be larger than 32 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
Fix even more missing includes after the common.h removal
build: Factor out rangecoder dependencies to CONFIG_RANGECODER
build: Factor out error resilience dependencies to CONFIG_ERROR_RESILIENCE
x86: avcodec: Consistently name all init files
Add more missing includes after removing the implicit common.h
Add some more missing includes after removing the implicit common.h
Don't include common.h from avutil.h
rtmp: Automatically compute the hash for SWFVerification
Conflicts:
configure
doc/APIchanges
doc/examples/decoding_encoding.c
libavcodec/Makefile
libavcodec/assdec.c
libavcodec/audio_frame_queue.c
libavcodec/avpacket.c
libavcodec/dv_profile.c
libavcodec/dwt.c
libavcodec/libtheoraenc.c
libavcodec/rawdec.c
libavcodec/rv40dsp.c
libavcodec/tiff.c
libavcodec/tiffenc.c
libavcodec/v210dec.h
libavcodec/vc1dsp.c
libavcodec/x86/Makefile
libavfilter/asrc_anullsrc.c
libavfilter/avfilter.c
libavfilter/buffer.c
libavfilter/formats.c
libavfilter/vf_ass.c
libavfilter/vf_drawtext.c
libavfilter/vf_fade.c
libavfilter/vf_select.c
libavfilter/video.c
libavfilter/vsrc_testsrc.c
libavformat/version.h
libavutil/audioconvert.c
libavutil/error.h
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The logic here was off. If the packet size is exactly two, then
it's a well-formed empty subtitle, used to mark the end of the
duration of the previous subtitle.
Signed-off-by: Philip Langdale <philipl@overt.org>
Unsurprisingly, if a timing-less subrip decoder is desireable, an
encoder is as well. With this in place, we can move on to remove
the use of the old encoder/decoder with embedded timing and move
all timing handling the (de)muxer where they belong.
Signed-off-by: Philip Langdale <philipl@overt.org>
After various discussions, we concluded that, amongst other things,
it made sense to have a separate subrip decoder that did not use
in-band timing information, and rather relied on the ffmpeg level
timing.
As this is 90% the same as the existing srt decoder, it's implemented
in the same file.
Signed-off-by: Philip Langdale <philipl@overt.org>
There are currently no statements from any person qualified in the art
of law about the LGPL compatibility of the libfaac license and others.
Furthermore their is no consensus about their compatibility amongth
people not qualified in the art.
Also of interrest may be that ubuntu distributes and links libfaac
to LGPL code. And the ubuntu technical comittee decision about libfaac
https://lists.ubuntu.com/archives/technical-board/2011-February/000703.html
Comments and other viewpoints, especially if i have missed something
are very welcome!
Reviewed-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
