By moving it to a later point relative and unknown timestamps
are more likely to have been corrected
similar patch reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Conflicts:
libavformat/utils.c
* qatar/master:
rtmp: Add a new option 'rtmp_pageurl'
doc: Update the description of the rtmp_tcurl option
rtmp: Make the description of the rtmp_tcurl option more generic
libfdk-aacenc: add LATM/LOAS encapsulation support
sctp: add port missing error message
tcp: add port missing error message
avfilter: Fix printf format string conversion specifier
Conflicts:
libavcodec/version.h
libavfilter/avfilter.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Without this patch a user a bit absent-minded may not notice that
the connection doesn't work because the port is missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
Without this patch a user a bit absent-minded may not notice that
the connection doesn't work because the port is missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
commit 20e88d8618
Fix avui stream-copy.
The native decoder and MPlayer's binary decoder only need the
APRG atom, QuickTime at least requires also the ARES atom and
four additional 0 bytes padding at the end of stsd.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The native decoder and MPlayer's binary decoder only need the
APRG atom, QuickTime at least requires also the ARES atom and
four additional 0 bytes padding at the end of stsd.
The old avcodec_find_best_pix_fmt() was insufficient due to 64 pix_fmt limit.
In ffmpeg this problem has been solved long ago through avcodec_find_best_pix_fmt2()
Today libav has added a incompatible modified version of avcodec_find_best_pix_fmt2()
under the same name, thus again breaking ABI/API ...
The avcodec_find_best_pix_fmt_of_list() added in this commit here makes the libav
API available to ffmpeg users too.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Attached patch (together with demuxing patch) allows WMP/msacm G723.1 codec decode files encoded by FFmpeg.
Tested with both 6400 and 5333 mode
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
OpenJPEG doesn't have a max lowres limit, so don't enforce an arbitrary one.
Signed-off-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
rtmp: Add credit/copyright to librtmp authors for parts of the RTMPE code
rtmp: Move the CONFIG_ condition into the if conditions
aac: Mention abbreviation as well in long_name
build: Skip compiling rtmpdh.h if ffrtmpcrypt protocol is not enabled
doc: Add Git configuration section
configure: Add a dependency on https for rtmpts
rtp: Only choose static payload types if the sample rate and channels are right
Conflicts:
doc/git-howto.texi
libavformat/rtmpproto.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Attached patch fixes remuxing of G723.1 in wav, so the output is playable by WMP.
(It's still not enough for encoding - probably some extradata should be added to the output file
to make it playable by WMP/win codec)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure these calls are removed by dead code elimination
even if optimization is disabled. This fixes building without
crypto libraries without optimization.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make it possible to use the run bisect sub command. As with all
other ffbisect commands, revisions that do not contain the needed
tools are skipped.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
In file libavcodec/x86/dsputil_mmx.c, function ff_put_pixels_clamped_mmx(), there are two assembly code blocks. In the first block (in the unrolled loop), the instructions "movq 8%3, %%mm1 \n\t" etc have problem.
For above instruction, it is clear what the programmer wants: a load from p + 8. But this assembly code doesn’t guarantee that. It only works if the compiler puts p in a register to produce an instruction like this: “movq 8(%edi), %mm1”. During compiler optimization, it is possible that the compiler will be able to constant propagate into p. Suppose p = &x[10000]. Then operand 3 can become 10000(%edi), where %edi holds &x. And the instruction becomes “movq 810000(%edx)”. That is, it will stride by 810000 instead of 8.
This will cause the segmentation fault.
This error was fixed in the second block of the assembly code, but not in the unrolled loop.
How to reproduce:
This error is exposed when we build the ffmpeg using Intel C++ Compiler, IPO+PGO optimization. The ffmpeg was crashed when decoding a mjpeg video.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Piotr Bandurski
Nicolas George
Samuel Pitoiset
Kieran Kunhya
Jordi Ortiz
Stefano Sabatini
Carl Eugen Hoyos
Diego Biurrun
Michael Bradshaw
Martin Storsjö
Alexander Strasser
yang