| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Fixes #434
Fixes #437
|
| |
|
|
|
|
|
|
|
|
| |
Libav 9 still uses the unprefixed PIX_FMT_... symbols, but they will
probably be removed some time in the future.
There are some other deprecations we have yet to take care of, but
there are no clear replacements yet.
|
|
|
|
|
| |
The compatibility issue actually didn#t get solved, it's just handled
differently in mpv now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We consider FFmpeg 1.x and Libav 0.9.x releases compatible. Support
for FFmpeg 0.9.x and Libav 0.8.x is considered infeasible and has been
dropped in the previous commits. The bits that break compatibility are
mainly the CodecID renaming (trivial, but would require nasty hacks
everywhere), the avcodec_encode_video2() function (missing in older
releases, mandatory in newer ones), and the resampler changes (older
releases miss lib{av,sw}resample, newer versions removed the
libavcodec resampler).
Remove some other compatibility bits that were needed to for releases
for which we drop support.
The comment about Libav 0.9 in compat/libav.h is incorrect and should
have been 0.8 (the symbol is present in Libav 0.9).
|
|
|
|
|
|
|
|
|
| |
The old names have been deprecated a while ago, but were needed for
supporting older ffmpeg/libav versions. The deprecated identifiers
have been removed from recent Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x and equivalent
FFmpeg releases.
|
|
|
|
|
|
| |
Tested with n0.10.4. All these version checks are rather tricky,
because Libav and FFmpeg change the same thing at slightly different
versions.
|
|
|
|
|
|
|
|
| |
The EXTERN_PREFIX definition changed in 94b7db2 needs a separate case
for _WIN64, as MinGW defines both that and _WIN32 but there is no prefix
unlike 32-bit case.
Patch by redxii on http://devel.mplayer2.org/ticket/226
|
|
|
|
|
| |
AVPROBE_SCORE_RETRY was too new, and doesn't even exist in Libav. Go
back to using the value explicitly.
|
|
|
|
|
|
|
|
|
|
| |
Doesn't define AVPROBE_SCORE_RETRY for some reason. They use
AVPROBE_SCORE_MAX/4 directly internally. AV_DISPOSITION_ATTACHED_PIC
is not defined with the most recent Libav release.
AVIOContext.av_class exists in Libav, but is apparently disabled in
old releases. Disable it for now until people stop torturing me with
old crap releases.
|
|
|
|
|
|
|
|
|
|
|
| |
Libav 0.8.4 is ridiculously old (in relative terms), so I don't know
how many things are broken silently.
Encoding is disabled, because the required API hasn't been added yet.
(On the other hand, the old API can't be used in newer versions.)
This should improve compatibility with ffmpeg 0.11.2 as well, which
didn't define AV_CODEC_ID_SUBRIP yet.
|
|
|
|
|
| |
av_noreturn is a rather recent addition to libavutil, and defining it
ourselves is trivial and makes playing compatibility games easier.
|
|
|
|
|
|
| |
Put MP_EXPAND_ARGS() in compiler.h, even though it's not compiler
dependent. Both mp_talloc.h and mp_common.h need it, while mp_common.h
includes mp_talloc.h. This is the least annoying solution.
|
|
|
|
|
| |
libavutil/version.h was only recently split off from
libavutil/avutil.h, and that file includes version.h anyway.
|
|
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.
Renames the following directories:
libaf -> audio/filter
libao2 -> audio/out
libvo -> video/out
libmpdemux -> demux
Split libmpcodecs:
vf* -> video/filter
vd*, dec_video.* -> video/decode
mp_image*, img_format*, ... -> video/
ad*, dec_audio.* -> audio/decode
libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.
Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.
sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).
Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
|