The error was fixed in commit ce9bd30379
more than one year ago, and does not affect all the currently supported
versions.
In particular, fix trac issue #1535.
In particular, reference segment muxer and clarify difference between
segment filename number and playlist sequence number.
Should fix trac ticket #2601.
Drop references to the doxy image gradients and style a the code blocks to
keep the whitespace and indent properly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '57ead8449e44bd07b3d4a5bd42f1aab64566f92e':
doc: fix link to the ISC license text in the developer documentation.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6c0e83511705e7f8f5100e7852a1e7fd16aa8877':
doc: fix a coding style error in the developer documentation.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
- do not allocate resample dst buffer when resample is off
- free sample buffers in addition to freeing data pointer arrays
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Hi list! Since my last patch (fix 2 memleaks in doc/examples/muxing.c)
I found more problems to fix.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 792845e436, reversing
changes made to 1d6666a6b8.
Bumping libavutil requires all libraries that use libavutil to have their
major version bumped (yes breakage has been confirmed this is not a hypotheses)
One case of breakage is due to new types being added to AVOptions and
applications that linked to old libavutil and libswresample
then trying to use old libavutil (its soname changed so the old isnt updated)
and new swresample (its soame didnt change so it is updated)
the new swresample contains AVOption types that the old libavutil doesnt
know of thus the application attempting to access these avoptions
fails
AVOptions are used by all libs so the issue can potentially happen with
any other lib, libswresample was just the first that showed the problem
ive not checked if the other libs are affected currently by the same issue
or not
Also in addition to AVOptions, AVFrames are also defined in
libavutil, bumping it without all libs that use AVFrames could lead to
serious inconsistencies when 2 libs/app end up using 2 different libavutils
The alternative of bumping all is still possible after this revert, if it
turns out to be the preferred solution
* commit '6d3ea1957f681b3bf9c752e6d21a501cc8d4180d':
Bump major of libavfilter for reference counted buffer API changes.
Conflicts:
libavfilter/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c':
Bump libavutil major version to account for the LLS API/ABI changes.
Conflicts:
libavutil/version.h
Bump done to stay compatible with libav, its not neccessary otherwise for ffmpeg
as we have the new ABI/API under LLS2 and the old (unused) under LLS
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is useful for debugging.
Reference and ffprobe.xsd changes done and tested by Stefano Sabatini.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
Applications that have been linked against an older release of Libav and pick up
updated libraries experience segmentation faults because they pick up the new
libavfilter, which assumes AVFrames have been allocated by libavutil and thus
contain new reference-counting related fields. This will break for AVFrames that
have been allocated by old libavcodec.
All scheduled API changes are deferred to the next bump.
Commit 41578f70cf changed the LLS API, which was
called from libavcodec. Thus using an old libavcodec with a new libavutil will
break.
All scheduled API changes are deferred to the next bump.
Stefano Sabatini
Michael Niedermayer
Anton Khirnov
Werner Robitza
Carl Eugen Hoyos
Timothy Gu
Maxim Poliakovski
Luca Barbato
Tim Walker
Justin Ruggles
Ilya Basin
Gildas Cocherel
wm4
Reinhard Tartler