1
mirror of https://github.com/mpv-player/mpv synced 2024-10-30 04:46:41 +01:00
Commit Graph

353 Commits

Author SHA1 Message Date
wm4
be882175d8 demux: merge extradata fields
MPlayer traditionally had completely separate sh_ structs for
audio/video/subs, without a good way to share fields. This meant that
fields shared across all these headers had to be duplicated. This commit
deduplicates essentially the last remaining duplicated fields.
2015-06-21 18:06:14 +02:00
wm4
2b64eee8d5 demux: rename sh_stream.format to sh_stream.codec_tag
Why not. "format" sounds too misleading for the actual importance and
meaning of this field.
2015-06-21 16:56:35 +02:00
wm4
991af7dfb1 video: reduce error message when loading hwdec backend fails
When using --hwdec=auto, about half of all systems will print:

    "[vdpau] Error when calling vdp_device_create_x11: 1"

this happens because usually mpv will be linked against both vdpau and
vaapi libs, but the drivers are not necessarily available. Then trying
to load a driver will fail. This is a normal part of probing, but the
error messages were printed anyway. Silence them by explicitly
distinguishing probing.

This pretty much goes through all the layers. We actually consider
loading hw backends for vo_opengl always "auto probed", even if a hw
backend is explicitly requested. In this case vd_lavc will print a
warning message anyway (adjust this message a bit).
2015-06-20 22:26:57 +02:00
wm4
9fe6a8c5f5 vd_lavc: fix a hw decoding fallback case
On hw decoder reinit failure we did not actually always return a sw
format, because the first format (fmt[0]) is not always a sw format.
This broke some cases of fallback. We must go through the trouble to
determine the first actual sw format.
2015-05-29 14:17:51 +02:00
wm4
6f5a10542c vdpau: add support for the "new" libavcodec vdpau API
Yet another of these dozens of hwaccel changes. This time, libavcodec
provides utility functions, which initialize the vdpau decoder and map
codec profiles. So a lot of work the API user had to do falls away.

This also will give us support for high bit depth profiles, and possibly
HEVC once libavcodec supports it.
2015-05-28 21:56:13 +02:00
wm4
a9b1e72ef2 vd_lavc: allocate hw surfaces using the coded size
...instead of relying on the hw decoding API to align it for us. The old
method could in theory have gone wrong if the video is cropped by an
amount large enough to step over several blocks.
2015-05-28 21:55:16 +02:00
wm4
939132cbd9 vd_lavc: merge two functions
There's not much of a reason to keep get_surface_hwdec() and
get_buffer2_hwdec() separate. Actually, the way the mpi->AVFrame
referencing is done makes this confusing. The separation is probably
an artifact of the pre-libavcodec-refcounting compatibility glue.
2015-05-28 21:53:37 +02:00
wm4
a2eb0ab076 vd_lavc: make hardware decoding fallback less violent
Most of hardware decoding is initialized lazily. When the first packet
is parsed, libavcodec will call get_format() to check whether hw or sw
decoding is wanted. Until now, we've returned AV_PIX_FMT_NONE from
get_format() if hw decoder initialization failed. This caused the
avcodec_decode_video2() call to fail, which in turn let us trigger the
fallback. We didn't return a sw format from get_format(), because we
didn't want to continue decoding at all. (The reason being that full
reinitialization is more robust when continuing sw decoding.)

This has some disadvantages. libavcodec vomited some unwanted error
messages. Sometimes the failures are more severe, like it happened with
HEVC. In this case, the error code path simply acted up in a way that
was extremely inconvenient (and had to be fixed by myself). In general,
libavcodec is not designed to fallback this way.

Make it a bit less violent from the API usage point of view. Return a sw
format if hw decoder initialization fails. In this case, we let
get_buffer2() call avcodec_default_get_buffer2() as well. libavcodec is
allowed to perform its own sw fallback. But once the decode function
returns, we do the full reinitialization we wanted to do.

The result is that the fallback is more robust, and doesn't trigger any
decoder error codepaths or messages either. Change our own fallback
message to a warning, since there are no other messages with error
severity anymore.
2015-05-28 21:52:04 +02:00
wm4
449cdfc0ff vd_lavc: report actually used hwdec API
Instead of the requested one, which can be just "auto", and which is
rather useless.
2015-05-25 21:43:20 +02:00
wm4
c6d046414b player: change video-bitrate and audio-bitrate properties
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)

Also extend the documentation a little.

It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
2015-04-20 20:52:16 +02:00
Marcin Kurczewski
f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4
8fff125422 RPI support
This requires FFmpeg git master for accelerated hardware decoding.
Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav
will also work.

Most things work. Screenshots don't work with accelerated/opaque
decoding (except using full window screenshot mode). Subtitles are
very slow - even simple but huge overlays can cause frame drops.

This always uses fullscreen mode. It uses dispmanx and mmal directly,
and there are no window managers or anything on this level.

vo_opengl also kind of works, but is pretty useless and slow. It can't
use opaque hardware decoding (copy back can be used by forcing the
option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend
is preferred over the X11 ones in case you're trying on X11; but X11
is even more useless on RPI.

This doesn't correctly reject extended h264 profiles and thus doesn't
fallback to software decoding. The hw supports only up to the high
profile, and will e.g. return garbage for Hi10P video.

This sets a precedent of enabling hw decoding by default, but only
if RPI support is compiled (which most hopefully it will be disabled
on desktop Linux platforms). While it's more or less required to use
hw decoding on the weak RPI, it causes more problems than it solves
on real platforms (Linux has the Intel GPU problem, OSX still has
some cases with broken decoding.) So I can live with this compromise
of having different defaults depending on the platform.

Raspberry Pi 2 is required. This wasn't tested on the original RPI,
though at least decoding itself seems to work (but full playback was
not tested).
2015-03-29 16:09:56 +02:00
wm4
72e67064a3 vd_lavc: less confusing message when hardware decoding won't work
Codecs for hardware acceleration are not blacklisted, but whitelisted.
Also, if this emssage is printed, the codec might not have any hardware
acceleration support in the first place.
2015-03-20 22:14:14 +01:00
wm4
37cb9a965a vd_lavc: change message about using hardware decoding
This was requested. Apparently some find the old mesage confusing.
2015-03-17 22:33:31 +01:00
wm4
27b5492a82 vd_lavc: let --hwdec=auto select "vaapi-copy"
Instead of "vaapi", simply by changing the probe order.

"vaapi" uses the GLX GL interop, which has causing us more problems than
it solved.

Unfortunately this leads also to copying if "--hwdec=auto --vo=vaapi" is
used, even though GLX is not involved in this case - but I don't care
enough to make the probe logic cleverer just for this. You can still get
the zero-copy path with --hwdec=vaapi.
2015-03-05 13:02:30 +01:00
Niklas Haas
a76cc1dafc
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.

This reverts commit 8d24e9d9b8.

diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
     shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
     shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
     shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
-                   gamma_fun == MP_CSP_TRC_BT_1886);
+                   use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
     shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
-                   gamma_fun == MP_CSP_TRC_SRGB);
+                   use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
     shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
     if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
         shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 20:23:47 +01:00
wm4
8d24e9d9b8 Revert recent vo_opengl related commits
Breaks vo_opengl by default. I'm hot able to fix this myself, because I
have no clue about the overcomplicated color management logic. Also,
whilethis is apparently caused by commit fbacd5, the following commits
all depend on it, so revert them too.

This reverts the following commits:
 e141caa97d
 653b0dd529
 729c8b3f64
 fbacd5de31

Fixes #1636.
2015-02-28 19:29:03 +01:00
Niklas Haas
e141caa97d
vd_lavc: respect lavc's color_trc field
We now actually use the TRC tagging information lavc provides us with,
instead of always manually guessing.
2015-02-28 01:42:04 +01:00
wm4
5baf74fa24 video: remove redundant codec parameters
Remove coded_width and coded_height. This was originally added in commit
fd7dde40, when BITMAPINFOHEADER was killed. The separate fields became
redundant in commit e68f4be1. Remove them (nothing passed to the
decoders actually changes with _this_ commit).
2015-02-24 11:56:48 +01:00
wm4
cf073138b2 vd_lavc: uninit the hwdec backend after closing the decoder
A recent behavior change in libavcodec's h264 decoder keeps at least 1
surface even after avcodec_flush_buffers() has been called. We used to
flush the decoder in order to make sure all surfaces are free'd, so that
the hw decoder can be safely uninitialized. This doesn't work anymore.

Fix it by closing the AVCodecContext before the hw decoder is
uninitialized. This is actually simpler and more robust. It seems to be
well-supported too.

Fixes invalid read accesses with vaapi-copy and dxva2-copy. These
destroyed the hwdec API fully on uninit, and could not deal with
surfaces surviving the decoder.

Probably fixes #1587.
2015-02-14 16:45:38 +01:00
wm4
be5994a781 video: work around libswscale for PNG pixel formats
The intention is that we can test vo_opengl with high bit depth PNGs
better. This throws libswscale completely out of the loop, which before
was needed in order to convert from big endian to little endian.

Also apply a minimal cleanup to fmt-conversion.c (unrelated).
2015-02-06 23:22:16 +01:00
wm4
0f4bf347c5 player: print used number of threads in verbose mode
Also, don't use av_log() for mpv output.
2015-01-05 12:17:55 +01:00
wm4
aaa319fcbd vd_lavc: fix error handling path
The ctx->pic check must uninitialize the decoder.
2014-12-13 22:00:42 +01:00
wm4
2b337d67a4 Check some mallocs
Fixes #1337.
2014-12-12 17:28:22 +01:00
wm4
c65bce0738 vd_lavc: use avcodec_is_open()
This is "better", although nobody seems to know how this API is supposed
to work at all.
2014-12-02 20:36:55 +01:00
wm4
b57ab4bb3b vd_lavc: don't crash if codec could not be opened
Fixes #1307.
2014-12-01 13:58:30 +01:00
wm4
8a1d5e91ad vd_lavc: flush frames before uninitializing hw decoder
This way, no surfaces are in use when uninitializing the hw decoders,
which might help with -copy hw decoders (normal hw decoding is not
affected).
2014-11-20 16:48:03 +01:00
wm4
423a7de676 video: initial dxva2 support
Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug
it yourself.
2014-10-25 19:25:22 +02:00
wm4
c2592be4f0 vd_lavc: fix a small memory leak on init error
The private context wasn't free'd when codec init failed. Restructure
the code so that it can't happen.
2014-09-29 20:37:12 +02:00
wm4
debbff76f9 Remove mpbswap.h
This was once central, but now it's almost unused. Only vf_divtc still
uses it for extremely weird and incomprehensible reasons. The use in
stream.c is trivial. Replace these, and remove mpbswap.h.
2014-09-25 21:32:55 +02:00
wm4
fd7dde404d video: remove BITMAPINFOHEADER from internal demuxer API
MPlayer traditionally did this because it made sense: the most important
formats (avi, asf/wmv) used Microsoft formats, and many important
decoders (win32 binary codecs) also did. But the world has changed, and
I've always wanted to get rid of this thing from the codebase.

demux_mkv.c internally still uses it, because, guess what, Matroska has
a VfW muxing mode, which uses these data structures natively.
2014-09-25 00:59:15 +02:00
wm4
8599c959fe video: initial Matroska 3D support
This inserts an automatic conversion filter if a Matroska file is marked
as 3D (StereoMode element). The basic idea is similar to video rotation
and colorspace handling: the 3D mode is added as a property to the video
params. Depending on this property, a video filter can be inserted.

As of this commit, extending mp_image_params is actually completely
unnecessary - but the idea is that it will make it easier to integrate
with VOs supporting stereo 3D mogrification. Although vo_opengl does
support some stereo rendering, it didn't support the mode my sample file
used, so I'll leave that part for later.

Not that most mappings from Matroska mode to vf_stereo3d mode are
probably wrong, and some are missing.

Assuming that Matroska modes, and vf_stereo3d in modes, and out modes
are all the same might be an oversimplification - we'll see.

See issue #1045.
2014-08-30 23:24:46 +02:00
wm4
68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.

The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
2014-08-29 12:31:52 +02:00
wm4
f1e78306cb vaapi: try dealing with Intel's braindamaged shit drivers
So talking to a certain Intel dev, it sounded like modern VA-API drivers
are reasonable thread-safe. But apparently that is not the case. Not at
all. So add approximate locking around all vaapi API calls.

The problem appeared once we moved decoding and display to different
threads. That means the "vaapi-copy" mode was unaffected, but decoding
with vo_vaapi or vo_opengl lead to random crashes.

Untested on real Intel hardware. With the vdpau emulation, it seems to
work fine - but actually it worked fine even before this commit, because
vdpau was written and designed not by morons, but competent people
(vdpau is guaranteed to be fully thread-safe).

There is some probability that this commit doesn't fix things entirely.
One problem is that locking might not be complete. For one, libavcodec
_also_ accesses vaapi, so we have to rely on our own guesses how and
when lavc uses vaapi (since we disable multithreading when doing hw
decoding, our guess should be relatively good, but it's still a lavc
implementation detail). One other reason that this commit might not
help is Intel's amazing potential to fuckup anything that is good and
holy.
2014-08-21 22:45:58 +02:00
wm4
b8f025a58a video: don't keep multiple pointers to hwdec info struct
This makes a certain corner case simpler at a later point.
2014-08-11 23:09:39 +02:00
wm4
8dfe0c73c9 video: remove "hard" framedrop mode
Completely useless, and could accidentally be enabled by cycling
framedrop modes. Just get rid of it.

But still allow triggering the old code with --vd-lavc-framedrop, in
case someone asks for it. If nobody does, this new option will be
removed eventually.
2014-08-09 00:35:35 +02:00
wm4
d68a759fa4 Improve setting AVOptions
Use OPT_KEYVALUELIST() for all places where AVOptions are directly set
from mpv command line options. This allows escaping values, better
diagnostics (also no more "pal"), and somehow reduces code size.

Remove the old crappy option parser (av_opts.c).
2014-08-02 03:12:33 +02:00
Niklas Haas
70f50ddc5e video: Add support for non-BT.709 primaries
This add support for reading primary information from lavc, categorized
into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the
vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020
and transform our source into this colorspace in the shader.
2014-06-22 19:00:38 +02:00
wm4
72aac9ae8a video: introduce failure path for image allocations
Until now, failure to allocate image data resulted in a crash (i.e.
abort() was called). This was intentional, because it's pretty silly to
degrade playback, and in almost all situations, the OOM will probably
kill you anyway. (And then there's the standard Linux overcommit
behavior, which also will kill you at some point.)

But I changed my opinion, so here we go. This change does not affect
_all_ memory allocations, just image data. Now in most failure cases,
the output will just be skipped. For video filters, this coincidentally
means that failure is treated as EOF (because the playback core assumes
EOF if nothing comes out of the video filter chain). In other
situations, output might be in some way degraded, like skipping frames,
not scaling OSD, and such.

Functions whose return values changed semantics:

  mp_image_alloc
  mp_image_new_copy
  mp_image_new_ref
  mp_image_make_writeable
  mp_image_setrefp
  mp_image_to_av_frame_and_unref
  mp_image_from_av_frame
  mp_image_new_external_ref
  mp_image_new_custom_ref
  mp_image_pool_make_writeable
  mp_image_pool_get
  mp_image_pool_new_copy
  mp_vdpau_mixed_frame_create
  vf_alloc_out_image
  vf_make_out_image_writeable
  glGetWindowScreenshot
2014-06-17 22:43:43 +02:00
wm4
6a4a5595d8 options: remove OPT_FLAG_CONSTANTS
This means use of the min/max fields can be dropped for the flag option
type, which makes some things slightly easier. I'm also not sure if the
client API handled the case of flag not being 0 or 1 correctly, and this
change gets rid of this concern.
2014-06-13 02:10:45 +02:00
wm4
a7a14be088 vd_lavc: use option parser for skip suboptions 2014-06-13 02:03:45 +02:00
wm4
14983eb37d vd_lavc: make option struct local
Removes specifics from options.h and options.c, and puts everything into
vd_lavc.c.
2014-06-11 01:36:11 +02:00
wm4
99f5fef0ea Add more const
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
2014-06-11 00:39:14 +02:00
Marcoen Hirschberg
ecea66e8dc vd_lavc: set video bitrate if available
Set the bitrate of dec_video if it is available in avcodec.
2014-05-28 21:38:20 +02:00
wm4
d99f30d726 video: warn if an emulated hwdec API is used
mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each
of these has emulation wrappers. The wrappers are usually slower and
have fewer features than their native opposites. In particular the libva
vdpau driver is practically unmaintained.

Check the vendor string and print a warning if emulation is detected.
Checking vendor strings is a very stupid thing to do, but I find the
thought of people using an emulated API for no reason worse.

Also, make --hwdec=auto never use an API that is detected as emulated.
This doesn't work quite right yet, because once one API is loaded,
vo_opengl doesn't unload it, so no hardware decoding will be used if the
first probed API (usually vdpau) is rejected. But good enough.
2014-05-28 02:08:45 +02:00
wm4
6125ba613f video: add --video-rotate option for controlling auto-rotation 2014-05-24 16:17:52 +02:00
Luca Barbato
5cbfdac2a8 vd_lavc: Support hwaccel 1.2 and later
Hwaccel 1.2 populates only the third data field and assumes
that the AVCodecContext is available to the dealloc function.
2014-05-12 12:59:16 +02:00
wm4
8a74638dc7 video: add a "hwdec" property to enable or disable hw decoding at runtime 2014-04-23 01:58:12 +02:00
wm4
fd2f40762f demux: export video rotation parameter
Now the rotation hint is propagated everywhere. It just isn't used
anywhere yet.
2014-04-21 02:57:16 +02:00
wm4
8fbf0300d8 vd_lavc: reinit hwdec on profile changes
Needed in theory. I don't know if there are even any real-world files
which change the profile mid-stream.
2014-03-17 18:19:03 +01:00
wm4
2963d84a9b vd_lavc: remove unused field 2014-03-16 15:05:46 +01:00
wm4
269c1e1f41 vd_lavc: reduce hardware decoder mid-stream reinitializations
Instead of doing it on every seek (libavcodec calls get_format on every
seek), reinitialize the decoder only if the video resolution changes.

Note that this may be relatively naive, since we e.g. (or: in
particular) don't check for profile changes. But it's not worse than the
state before the get_format change, and at least it paints over the
current vaapi breakage (issue #646).
2014-03-16 14:54:21 +01:00
wm4
3ec7f528c4 vd_lavc: remove compatibility crap
All this code was needed for compatibility with very old libavcodec
versions only (such as Libav 9).

Includes some now-possible simplifications too.
2014-03-16 13:19:19 +01:00
wm4
ba160f5c84 vd_lavc: ridiculous workaround for Libav 9 compatibility
This "sometimes" crashed when seeking. The fault apparently lies in
libavcodec: the decoder returns an unreferenced frame! This is
completely insane, but somehow I'm apparently still expected to
work this around. As a reaction, I will drop Libav 9 support in the
next commit. (While this commit will go into release/0.3.)
2014-03-16 01:38:13 +01:00
wm4
ccce58d6d6 video: initialize hw decoder in get_format
Apparently the "right" place to initialize the hardware decoder is in
the libavcodec get_format callback.

This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and
vdpau_old.c is probably going to be removed soon (if Libav ever manages
to release Libav 10). So for now the init_decoder callback added with
this commit is optional.

This also means vdpau.c and vaapi.c don't have to manage and check the
image parameters anymore.

This change is probably needed for when libavcodec VDA supports gets a
new iteration of its API.
2014-03-10 22:56:26 +01:00
wm4
3433f25697 vd_lavc: matroska: remove weird code setting extra_huff for mjpeg
Like with the previous commit, this is probably not needed, but it's
unclear whether that really is the case. Most likely, it used to be
needed by some demuxer, and now the only demuxer left that could
_possibly_ trigger this is demux_mkv.c.

Note that mjpeg is the only decoder that reads the extra_huff option,
and nothing in libavformat actually sets the option. So maybe it's
fundamentally not needed anymore.
2014-01-11 01:49:20 +01:00
wm4
589f4871ea vd_lavc: matroska: remove weird realvideo special handling
This case can't happen with the normal realvideo codepath in
demux_mkv.c, because the code would errors out if the extradata is too
small, and everything would be broken anyway in the case the vd_lavc.c
condition is actually triggered.

It still might happen with VfW-muxed realvideo in Matroska, though.
Basically, I'm hoping this doesn't matter anyway, and that the vd_lavc.c
code was for other old demuxers, like demux_avi or demux_rm. Following
the commit history, it's not really clear for what demuxer this code
was added.
2014-01-11 01:47:14 +01:00
wm4
85e90668ae vd_lavc: minor simplification 2014-01-11 01:33:07 +01:00
wm4
4b4926bbb3 Factor out setting AVCodecContext extradata 2014-01-11 01:25:49 +01:00
wm4
392856ed4d vd_lavc: by default, output all frames, even corrupted ones
Set the flag CODEC_FLAG_OUTPUT_CORRUPT by default. Note that there is
also CODEC_FLAG2_SHOW_ALL, which is older, but this seems to be ffmpeg
only.

Note that whether you want this enabled depends on the user. Some might
prefer that only good frames are output, while others want the decoder
to try as hard as possible to output _anything_. Since mplayer/mpv is
rather the kind of player that tries hard instead of being "clever", set
the new default to override libavcodec's default.

A nice way to test this is switching video tracks. Since mpv doesn't
wait for the next key frame, it'll start feeding the decoder with a
packet from the middle of the stream.
2013-12-29 14:19:22 +01:00
wm4
2eefa31c88 video/decode: mp_msg conversions
Doesn't cover vdpau/vaapi parts yet, because these are a bit messier.
2013-12-21 20:50:10 +01:00
wm4
0112143fda Split mpvcore/ into common/, misc/, bstr/ 2013-12-17 02:39:45 +01:00
wm4
eb15151705 Move options/config related files from mpvcore/ to options/
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.

Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
2013-12-17 02:07:57 +01:00
wm4
7dc7b900c6 Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsg
The tmsg stuff was for the internal gettext() based translation system,
which nobody ever attempted to use and thus was removed. mp_gtext() and
set_osd_tmsg() were also for this.

mp_dbg was once enabled in debug mode only, but since we have log level
for enabling debug messages, it seems utterly useless.
2013-12-16 20:41:08 +01:00
wm4
9838bf5565 video: move video filter chain initialization from decoder to player
This should help fixing some issues (like not draining video frames
correctly on reinit), as well as decoupling the decoder, filter chain,
and VO code.

I also wanted to make the hardware video decoding fallback work properly
if software-only video filters are inserted. This currently has the
issue that the fallback is too violent, and throws away a bunch of
demuxer packets needed to restart software decoding properly. But
keeping "backup" packets turned out as too hacky, so I'm not doing this,
at least not yet.
2013-12-10 20:07:39 +01:00
wm4
bb6165342d video: create a separate context for video filter chain
This adds vf_chain, which unlike vf_instance refers to the filter chain
as a whole. This makes the filter API less awkward, and will allow
handling format negotiation better.
2013-12-07 19:32:44 +01:00
wm4
47c4b5c000 vd_lavc: factor out libavcodec thread setup 2013-12-04 23:12:51 +01:00
wm4
0afd121ae6 vd_lavc: don't check required hwdec fields 2013-12-04 23:12:51 +01:00
wm4
8a84da8102 av_common: add timebase parameter to mp_set_av_packet()
If the timebase is set, it's used for converting the packet timestamps.
Otherwise, the previous method of reinterpret-casting the mpv style
double timestamps to libavcodec style int64_t timestamps is used.

Also replace the kind of awkward mp_get_av_frame_pkt_ts() function by
mp_pts_from_av(), which simply converts timestamps in a way the old
function did. (Plus it takes a timebase parameter, similar to the
addition to mp_set_av_packet().)

Note that this should not change anything yet. The code in ad_lavc.c and
vd_lavc.c passes NULL for the timebase parameters. We could set
AVCodecContext.pkt_timebase and use that if we want to give libavcodec
"proper" timestamps.

This could be important for ad_lavc.c: some codecs (opus, probably mp3
and aac too) have weird requirements about doing decoding preroll on the
container level, and thus require adjusting the audio start timestamps
in some cases. libavcodec doesn't tell us how much was skipped, so we
either get shifted timestamps (by the length of the skipped data), or we
give it proper timestamps. (Note: libavcodec interprets or changes
timestamps only if pkt_timebase is set, which by default it is not.)
This would require selecting a timebase though, so I feel uncomfortable
with the idea. At least this change paves the way, and will allow some
testing.
2013-12-04 23:12:51 +01:00
wm4
597b8a3550 Take care of some libavutil deprecations, drop support for FFmpeg 1.0
PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants)
enum PixelFormat -> enum AVPixelFormat
Losen some version checks in certain newer pixel formats.
av_pix_fmt_descriptors -> av_pix_fmt_desc_get

This removes support for FFmpeg 1.0.x, which is even older than
Libav 9.x. Support for it probably was already broken, and its
libswresample was rejected by our build system anyway because it's
broken.

Mostly untested; it does compile with Libav 9.9.
2013-11-29 17:39:57 +01:00
wm4
f5219720f8 video: refactor PTS code, add fall back heuristic to DTS
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.

Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.

The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.

This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.

The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.

[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
2013-11-27 21:14:39 +01:00
wm4
f09b2ff661 cosmetics: rename video/audio reset functions
These used the suffix _resync_stream, which is a bit misleading. Nothing
gets "resynchronized", they really just reset state.

(Some audio decoders actually used to "resync" by reading packets for
resuming playback, but that's not the case anymore.)

Also move the function in dec_video.c to the top of the file.
2013-11-27 21:14:39 +01:00
wm4
9f72a9753e demux: export dts from demux_lavf, use it for avi
Having the DTS directly can be useful for restoring PTS values.

The avi file format doesn't actually store PTS values, just DTS. An
older hack explicitly exported the DTS as PTS (ignoring the [I assume]
genpts generated non-sense PTS), which is not necessary anymore due to
this change.
2013-11-25 23:13:01 +01:00
wm4
4205bbf243 video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFrame
Instead of passing the PTS as separate field, pass it as part of the
usual data structures. Basically, this removes strange artifacts from
the API. (It's not finished, though: the final decoded PTS goes through
strange paths, and filter_video() finally overwrites the decoded
mp_image's pts field with it.)

We also stop using libavcodec's reordered_opaque fields, and use
AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because
these pts fields are not "really" opaque anymore, yet we treat them as
such. But the end result should be the same, and reordered_opaque is
marked as partially deprecated (it's not clear whether it's really
deprecated).
2013-11-25 23:08:29 +01:00
wm4
df8d00cc1f vd_lavc: improve a comment 2013-11-24 14:44:58 +01:00
wm4
5a3e01fa80 vd_lavc: when falling back to software, revert filter error status
When mpv is started with some video filters set (--vf is used), and
hardware decoding is requested, and hardware decoding would be possible,
but is prevented due to video filters that accept software formats only,
the fallback didn't work properly sometimes.

This fallback works rather violently: it tries to initialize the filter
chain, and if it fails it throws away the frame decoded using the
hardware, and retries with software. The case that didn't work was when
decoding the current packet didn't immediately lead to a new frame. Then
the filter chain wouldn't be reinitialized, and the playloop would stop
playback as soon as it encounters the error flag.

Fix this by resetting the filter error flag (back to "uninitialized"),
which is a rather violent, but somewhat working solution.

The fallback in general should perhaps be cleaned up later.
2013-11-23 22:28:39 +01:00
wm4
de68b8f23c video: move handling of container vs. stream AR out of vd_lavc.c
Now the actual decoder doesn't need to care about this anymore, and it's
handled in generic code instead. This simplifies vd_lavc.c, and in
particular we don't need to detect format changes in the old way
anymore.
2013-11-23 21:40:51 +01:00
wm4
4c2fb8f3a2 dec_video: make vf_input and hwdec_info statically allocated
The only reason why these structs were dynamically allocated was to
avoid recursive includes in stheader.h, which is (or was) a very central
file included by almost all other files. (If a struct is referenced via
a pointer type only, it can be forward referenced, and the definition of
the struct is not needed.) Now that they're out of stheader.h, this
difference doesn't matter anymore, and the code can be simplified.

Also sneak in some sanity checks.
2013-11-23 21:39:07 +01:00
wm4
904c73d2d2 demux: remove gsh field from sh_audio/sh_video/sh_sub
This used to be needed to access the generic stream header from the
specific headers, which in turn was needed because the decoders had
access only to the specific headers. This is not the case anymore, so
this can finally be removed again.

Also move the "format" field from the specific headers to sh_stream.
2013-11-23 21:37:56 +01:00
wm4
3486302514 video: move decoder context from sh_video into new struct
This is similar to the sh_audio commit.

This is mostly cosmetic in nature, except that it also adds automatical
freeing of the decoder driver's state struct (which was in
sh_video->context, now in dec_video->priv).

Also remove all the stheader.h fields that are not needed anymore.
2013-11-23 21:36:20 +01:00
wm4
82068ec56c demux: rename demux_packet.h to packet.h
This always bothered me.
2013-11-18 18:46:44 +01:00
wm4
467ad4413e vd_lavc: select correct hw decoder profile for constrained baseline h264
The existing code tried to remove the "extra" profile flags for h264.

FF_PROFILE_H264_INTRA doesn't matter for us at all, because it's set
only for profiles the vdpau/vaapi APIs don't support.

The FF_PROFILE_H264_CONSTRAINED flag on the other hand is added to
H264_BASELINE, except that it makes the file a real subset of H264_MAIN
and H264_HIGH. Removing that flag would select the BASELINE profile,
which appears to be rarely supported by hardware decoders. This means we
accidentally rejected perfectly hardware decodable files. Use MAIN for
it instead.

(vaapi has explicit support for CONSTRAINED_BASELINE, but it seems to be
a new thing, and is not reported as supported where I tried. So don't
bother to check it, and do the same as on vdpau.)

See github issue #204.
2013-11-14 19:51:42 +01:00
wm4
6d2c5fc99a vd_lavc: remove explicit crystalhd support
This removes "--hwdec=crystalhd".

I doubt anyone even tried to use this. But even if someone wants to
use it, the decoders can still be explicitly invoked with e.g.:

    --vd=lavc:h264_crystalhd

The only advantage our special code provided was fallback to
software decoding. (But I'm not sure how the ffmpeg crystalhd
pseudo-decoder actually behaves.)

Removing this will allow some simplifications as soon as we don't need
vdpau_old.c anymore.
2013-11-06 00:47:53 +01:00
wm4
f7b2d644ef Merge branch 'master' into have_configure
Conflicts:
	configure
2013-11-04 00:43:06 +01:00
wm4
571e697a7c vo_opengl: add infrastructure for hardware decoding OpenGL interop
Most hardware decoding APIs provide some OpenGL interop. This allows
using vo_opengl, without having to read the video data back from GPU.

This requires adding a backend for each hardware decoding API. (Each
backend is an entry in gl_hwdec_vaglx[].) The backends expose video data
as a set of OpenGL textures.

Add infrastructure to support this. The next commit will add support for
VA-API.
2013-11-04 00:11:07 +01:00
Stefano Pigozzi
37388ebb0e configure: uniform the defines to #define HAVE_xxx (0|1)
The configure followed 5 different convetions of defines because the next guy
always wanted to introduce a new better way to uniform it[1]. For an
hypothetic feature 'hurr' you could have had:

  * #define HAVE_HURR 1   / #undef HAVE_DURR
  * #define HAVE_HURR     / #undef HAVE_DURR
  * #define CONFIG_HURR 1 / #undef CONFIG_DURR
  * #define HAVE_HURR 1   / #define HAVE_DURR 0
  * #define CONFIG_HURR 1 / #define CONFIG_DURR 0

All is now uniform and uses:
  * #define HAVE_HURR 1
  * #define HAVE_DURR 0

We like definining to 0 as opposed to `undef` bcause it can help spot typos
and is very helpful when doing big reorganizations in the code.

[1]: http://xkcd.com/927/ related
2013-11-03 21:59:54 +01:00
wm4
4d903127ad demux: rename Windows symbols
There are some Microsoft Windows symbols which are traditionally used by
the mplayer core, because it used to be convenient (avi was the big
format, using binary windows decoders made sense...). So these symbols
have the exact same definition as the Windows one, and if mplayer is
compiled on Windows, the symbols from windows.h are used.

This broke recently just because some files were shuffled around, and
the symbols defined in ms_hdr.h collided with windows.h ones. Since we
don't have windows binary decoders anymore, there's not the slightest
reason our symbols should have the same names. Rename them to reduce the
risk for collision, and to fix the recent regression.

Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines
its own version if the windows headers don't define it, and ao_wasapi is
not available on systems where this symbol is missing.

Also reindent ms_hdr.h.
2013-11-02 15:14:12 +01:00
wm4
24897eb94c video: check profiles with hardware decoding
We had some code for checking profiles earlier, which was removed in
commits 2508f38 and adfb71b. These commits mentioned that (working) hw
decoding was sometimes prevented due to profile checking, but I can't
find the samples anymore that showed this behavior. Also, I changed my
opinion, and I think checking the profiles is something that should be
done for better fallback to software decoding behavior.

The checks roughly follow VLC's vdpau profile checks, although we do
not check codec levels. (VLC's profile checks aren't necessarily
completely correct, but they're a welcome help anyway.)

Add a --vd-lavc-check-hw-profile option, which skips the profile check.
2013-11-01 17:33:33 +01:00
wm4
7100a10127 vd_lavc: add more ifdeffery and ffmpeg cargo culting for correctness
We mixed the "old" AVFrame management functions (avcodec_alloc_frame,
avcodec_free_frame) with reference counting. This doesn't work
correctly; you must use av_frame_alloc and av_frame_free. Of course
ffmpeg doesn't warn us about the bad usage, but will just mess up
things silently. (Thanks a lot...)

While the alloc function seems to be 100% compatible, the free function
will do bad things, such as freeing memory that might still be
referenced by another frame. I didn't experience any actual bugs, but
maybe that was pure luck.
2013-10-31 18:17:14 +01:00
wm4
f01744ac4e core: add --force-window
This commit adds the --force-window option, which will cause mpv always
to create a window when started. This can be useful when pretending that
mpv is a GUI application (which it isn't, but users pretend anyway), and
playing audio files would run mpv in the background without giving a
window to control it.

This doesn't actually create the window immediately: it only does so
only after initializing playback and when it is clear that there won't
be any actual video. This could be a problem when starting slow or
completely stuck network streams (mpv would remain frozen in the
background), or if video initialization somehow is stuck forever in
an in-between state (like when the decoder doesn't output a video
frame, but doesn't return an error either). Well, we can pretend only
so much that mpv is a GUI application.
2013-10-02 01:39:28 +02:00
wm4
9a55c4e70c video: let sh_video->aspect always be container aspect ratio
Now writing -1 to the 'aspect' property resets the video to the auto
aspect ratio. Returning the aspect from the property becomes a bit more
complicated, because we still try to return the container aspect ratio
if no frame has been decoded yet.
2013-09-26 17:29:14 +02:00
wm4
641e94cd27 vaapi: allow GPU read-back with --hwdec=vaapi-copy
This code is actually quite inefficient: it reuses the (slow, simple)
screenshot code. It uses an inefficient method to read the image
(vaGetImage() instead of vaDeriveImage()), allocates new memory for
each frame that is read, and it tries all image formats again each
time.

Also, in my tests it always picked NV12 as image format, which is not
ideal if you actually want to filter the video, and vo_xv can't handle
this format without conversion either.

However, a user confirmed that it worked for him, so everything is fine.
2013-09-25 13:53:42 +02:00
wm4
7c3f1ffc44 vd_lavc: allow process_image to change image format
This will allow GPU read-back with process_image.

We have to restructure how init_vo() works. Instead of initializing the
VO before process_image is called, rename init_vo() to
update_image_params(), and let it update the params only. Then we really
initialize the VO after process_image.

As a consequence of these changes, already decoded hw frames are
correctly unreferenced if creation of the filter chain fails. This
could trigger assertions on VO uninitialization, because it's not
allowed to reference hw frames past VO lifetime.
2013-09-25 13:53:42 +02:00
xylosper
1a1504914a vd_lavc: reset last_sample_aspect_ratio in uninit_avctx()
In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set,
sh->aspect is overwritten. With software decoding fallback behaviour,
this makes the aspect ratio from container ignored since
last_sample_aspect_ratio is already set in first try with hardware
decoding.
2013-09-13 21:32:29 +02:00
wm4
c3a0721d09 video/out: don't require VOs to handle screenshot aspect specially
This affects VOs which just reuse the mp_image from draw_image() to
return screenshots. The aspect of these images is never different
from the aspect the screenshots should be, so there's no reason to
adjust the aspect in these cases.

Other VOs still need it in order to restore the original image
attributes.

This requires some changes to the video filter code to make sure that
the aspect in the passed mp_images is consistent.

The changes in mplayer.c and vd_lavc.c are (probably) not strictly
needed for this commit, but contribute to consistency.
2013-08-24 17:03:06 +02:00
Stefano Pigozzi
a9cb2dc1b8 video: add vda decode support (with hwaccel) and direct rendering
Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec'
decoder in FFmpeg.

The Good: This new implementation has some advantages over the previous one:

 - It works with Libav: vda_h264_dec never got into Libav since they prefer
   client applications to use the hwaccel API.

 - It is way more efficient: in my tests this implementation yields a
   reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and
   ~65-75% compared to h264 software decoding. This is mainly because
   `vo_corevideo` was adapted to perform direct rendering of the
   `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework.

The Bad:
  - `vo_corevideo` is required to use VDA decoding acceleration.
  - only works with versions of ffmpeg/libav new enough (needs reference
    refcounting). That is FFmpeg 2.0+ and Libav's git master currently.

The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture.
One one end this makes the code simple since Apple's OpenGL implementation
actually supports this out of the box. It would be nice to support other
output image formats and choose the best format depending on the input, or at
least making it configurable. My tests indicate that CPU usage actually
increases with a 420p IMGFMT output which is not what I would have expected.

NOTE: There is a small memory leak with old versions of FFmpeg and with Libav
since the CVPixelBufferRef is not automatically released when the AVFrame is
deallocated. This can cause leaks inside libavcodec for decoded frames that
are discarded before mpv wraps them inside a refcounted mp_image (this only
happens on seeks).
For frames that enter mpv's refcounting facilities, this is not a problem
since we rewrap the CVPixelBufferRef in our mp_image that properly forwards
CVPixelBufferRetain/CvPixelBufferRelease calls to the underying
CVPixelBufferRef.

So, for FFmpeg use something more recent than `b3d63995` for Libav the patch
was posted to the dev ML in July and in review since, apparently, the proposed
fix is rather hacky.
2013-08-22 12:13:30 +02:00
wm4
006c2f66e1 video/decode: change fix_image callback
This might make it slightly easier when trying to implement surface
read-back for hardware decoding.
2013-08-15 23:40:02 +02:00
wm4
be2f2ff033 vd_lavc: fix comment, document hwdec video frame size trickiness
About this issue, it would be better if the surfaces could be allocated
with the real size, and the vdpau video mixer could be created with that
size as well. That would be a bit hard, because the real surface size
had to be communicated to vdpau. So I'm going with this solution. vaapi
seems to be fine with either surface size, so there's hopefully no
problem.
2013-08-15 23:40:02 +02:00
wm4
0da9638576 video/decode: pass parameters directly to hwdec allocate_image callback
Instead of passing AVFrame. This also moves the mysterious logic about
the size of the allocated image to common code, instead of duplicating
it everywhere.
2013-08-15 23:40:02 +02:00
wm4
2827295703 video: add vaapi decode and output support
This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.

This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).

On the other hand, some features not present in the original patch were
added, like screenshot support.

VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).

Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.

Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)

Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
2013-08-12 01:12:02 +02:00
wm4
8fe4790ec8 video: redo hw decoding initialization, add --hwdec=auto
Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.

Add an "auto" choice to the --hwdec option, which automatically enables
hardware decoding if libavcodec and/or the VO supports it.

What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
2013-08-11 23:59:18 +02:00
Stefano Pigozzi
406241005e core: move contents to mpvcore (2/2)
Followup commit. Fixes all the files references.
2013-08-06 22:52:31 +02:00
wm4
a34c707f03 vd_lavc: print warning if hardware decoding API is not available
At least currently, this case pretty much happens only in the case vdpau
is requested, but not compiled in.
2013-07-30 16:32:21 +02:00
wm4
7f5303fbb6 vd_lavc: fix CONFIG_VDPAU check
CONFIG_VDPAU was just defined to 0, instead of undefined when vdpau was
unavailable. I blame the old mplayer code, which apparently can't have
consistent conventions.
2013-07-30 16:26:54 +02:00
wm4
5accc5e7c1 vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").

Add support for the "new" libavcodec vdpau support. This was recently
added and replaces the "old" vdpau parts. (In fact, Libav is about to
deprecate and remove the "old" API without deprecation grace period,
so we have to support it now. Moreover, there will probably be no Libav
release which supports both, so the transition is even less smooth than
we could hope, and we have to support both the old and new API.)

Whether the old or new API is used is checked by a configure test: if
the new API is found, it is used, otherwise the old API is assumed.

Some details might be handled differently. Especially display preemption
is a bit problematic with the "new" libavcodec vdpau support: it wants
to keep a pointer to a specific vdpau API function (which can be driver
specific, because preemption might switch drivers). Also, surface IDs
are now directly stored in AVFrames (and mp_images), so they can't be
forced to VDP_INVALID_HANDLE on preemption. (This changes even with
older libavcodec versions, because mp_image always uses the newer
representation to make vo_vdpau.c simpler.)

Decoder initialization in the new code tries to deal with codec
profiles, while the old code always uses the highest profile per codec.

Surface allocation changes. Since the decoder won't call config() in
vo_vdpau.c on video size change anymore, we allow allocating surfaces
of arbitrary size instead of locking it to what the VO was configured.
The non-hwdec code also has slightly different allocation behavior now.

Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
2013-07-28 19:25:07 +02:00
wm4
e83cbde1a4 Fix some -Wshadow warnings
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
2013-07-23 00:45:23 +02:00
wm4
cb8f638292 vd: add VDCTRL_GET_PARAMS
This is probably going to be unused, but might help with debugging and
such. It returns the image parameters as determined by the video
decoder.
2013-07-15 01:49:26 +02:00
wm4
af0c41e162 Remove old demuxers
Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does
better than them (except in rare corner cases), and the demuxers have
a bad influence on the rest of the code. Often they don't output
proper packets, and require additional audio and video parsing. Most
work only in --no-correct-pts mode.

Remove them to facilitate further cleanups.
2013-07-07 23:54:11 +02:00
wm4
ac266da658 vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.

FFmpeg provides a small overview in libavcodec/avcodec.h:

-----------
/**
 *  X   X      3 4 X      X are luma samples,
 *             1 2        1-6 are possible chroma positions
 *  X   X      5 6 X      0 is undefined/unknown position
 */
enum AVChromaLocation{
    AVCHROMA_LOC_UNSPECIFIED = 0,
    AVCHROMA_LOC_LEFT        = 1, ///< mpeg2/4, h264 default
    AVCHROMA_LOC_CENTER      = 2, ///< mpeg1, jpeg, h263
    AVCHROMA_LOC_TOPLEFT     = 3, ///< DV
    AVCHROMA_LOC_TOP         = 4,
    AVCHROMA_LOC_BOTTOMLEFT  = 5,
    AVCHROMA_LOC_BOTTOM      = 6,
    AVCHROMA_LOC_NB             , ///< Not part of ABI
};
-----------

The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.

Not sure about correctness, but it's probably ok.
2013-06-28 21:20:41 +02:00
wm4
3382a6f6e4 video: add a new method to configure filters and VOs
The filter chain and the video ouputs have config() functions. They are
strictly limited to transfering the video size and format. Other
parameters (like color levels) have to be transferred separately.

Improve upon this by introducing a separate set of reconfig() functions,
which use mp_image_params to carry format parameters. This struct
contains all image format related parameters from config(), plus
additional parameters such as colorspace.

Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just
an example/test case, but vo_opengl will need it later.

The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This
information is now handed to the VOs via reconfig(). The getter,
VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
2013-06-28 20:34:46 +02:00
wm4
0435ab7131 options: remove -lavdopts debug suboption
This can be set as avopt instead.
2013-06-28 14:42:06 +02:00
wm4
9f4261de65 core: add common function to initialize AVPacket
Audio and video had their own (very similar) functions to initialize an
AVPacket (ffmpeg's packet struct) from a demux_packet (mplayer's packet
struct). Add a common function for these.

Also use this function for sd_lavc_conv. This is actually a functional
change, as some libavfilter subtitle demuxers add weird out-of-band
stuff as side-data.
2013-06-03 22:40:07 +02:00
wm4
a21cfddaab options: remove some questionable -lavdopts suboptions
Most of these are rather questionable, the rest you rarely need to set
manually. You still can set all of them with -lavdopts-o (because
libavcodec has AVOptions for them).
2013-05-29 14:57:05 +02:00
wm4
41d38b3a2b vd_lavc: change VDCTRL_REINIT_VO behavior
This tried to use ctx->pic (last decoded AVFrame) for the frame bounds.
However, if av_frame_unref() on the AVFrame is called, the function will
reset _all_ AVFrame fields, even those which are not involved with
memory management. As result, mpcodecs_config_vo() was called with 0
width/height, which made the function exit early, instead of
reconfiguring the filter chain.

Go back to using mpcodecs_config_vo() directly. (That's what it did
before this VDCTRL was originally introduced; the original reason for
it disappeared.)
2013-05-18 17:32:37 +02:00
wm4
c970f5c328 video: rename VDCTRL_RESET_ASPECT to VDCTRL_REINIT_VO
Same thing, and VDCTRL_REINIT_VO implies more generic use.
2013-05-18 17:32:37 +02:00
wm4
bc8815d69f vd_lavc: hack-fix vdpau decoding with non mod 16 video
This changes the code so that it does the same as MPlayer, mplayer2
and mpv before ref-counted AVFrame. The problem is that get_buffer2
is called with aligned frame dimensions, while get_buffer didn't. This
breaks the mpv video frame size change detection.
2013-05-14 01:10:05 +02:00
wm4
012d297bb1 video: add --hwdec-codecs option to whitelist codecs for hw decoding 2013-05-04 01:38:27 +02:00
wm4
844249317b vd_lavc: allow explicitly selecting vdpau hw decoders
This allows using the vdpau decoders with -vd without having to use
the -hwdec switch (basically like in mplayer).

Note that this way of selecting the hardware decoder is still
deprecated. libavcodec went away from adding special decoder entries
for hardware decoding, and instead makes use of the "hwaccel"
architecture, where hardware decoders use the same decoder names as
the software decoders. The old vdpau special decoders will probably
be deprecated and removed in the future.
2013-05-04 01:36:15 +02:00
wm4
bf48f1ecce vd_lavc: fix decoder init failure path
libavcodec decoder initialization failure caused a segfault, because it
wasn't properly reported back in init().

Also remove the return value from init_avctx(), which actually makes
things simpler. Instead, ctx->avctx can be checked to see whether
initialization was ok.
2013-04-27 13:40:55 +02:00
wm4
3374a43998 core: always pass data via packet fields to video decoders
Makes the code a bit simpler to follow, at least in the "modern"
decoding path (update_video_nocorrect_pts() is used with old demuxers,
which don't return proper packets and need further parsing, so this code
looks less simple now).
2013-03-28 21:46:17 +01:00
wm4
514d8a7c9d video: make use of libavcodec refcounting
Now lavc_dr1.c is not used anymore if libavcodec is recent enough.
2013-03-13 23:51:30 +01:00
wm4
71b09be040 video: prepare for libavcodec refcounting
Some minor refactoring and moving code around.
There should be no functional changes.
2013-03-13 23:51:30 +01:00
wm4
c9088fff86 m_option: don't define OPT_BASE_STRUCT by default
OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.)
reference implicitly, since these macros take struct member names but no
struct type. Normally, only cfg-mplayer.h should need this, and other
places shouldn't be bothered with having to #undef it.

(Some files, like demux_lavf.c, still store their options in MPOpts. In
the long term, this should be removed, and handled like e.g. with VO
suboptions instead.)
2013-03-01 11:27:59 +01:00
wm4
281e10f05d dec_video: remove weird offset for VDCTRL_QUERY_UNSEEN_FRAMES
The return value of get_current_video_decoder_lag() should be the same
before and after this change in all cases.
2013-02-26 01:55:52 +01:00
wm4
8884ac9f79 vd_lavc: better warning message for software decoding fallback
At least I hope it's better.
2013-02-26 01:55:52 +01:00
wm4
2f6257e2f4 vd_lavc: fix software decoding fallback
The string is deallocated by the callee after initialization, so
fallback at runtime passes a deallocated string to libavcodec, which
results in random crashes. Regression introduced by commit 4d016a9.
2013-02-21 21:53:10 +01:00
wm4
01869d1391 demux_lavf, ad_lavc, vd_lavc: pass codec header data directly
Instead of putting codec header data into WAVEFORMATEX and
BITMAPINFOHEADER, pass it directly via AVCodecContext. To do this, we
add mp_copy_lav_codec_headers(), which copies the codec header data
from one AVCodecContext to another (originally, the plan was to use
avcodec_copy_context() for this, but it looks like this would turn
decoder initialization into an even worse mess).

Get rid of the silly CodecID <-> codec_tag mapping. This was originally
needed for codecs.conf: codec tags were used to identify codecs, but
libavformat didn't always return useful codec tags (different file
formats can have different, overlapping tag numbers). Since we don't
go through WAVEFORMATEX etc. and pass all header data directly via
AVCodecContext, we can be absolutely sure that the codec tag mapping is
not needed anymore.

Note that this also destroys the "standard" MPlayer method of exporting
codec header data. WAVEFORMATEX and BITMAPINFOHEADER made sure that
other non-libavcodec decoders could be initialized. However, all these
decoders have been removed, so this is just cruft full of old hacks that
are not needed anymore. There's still ad_spdif and ad_mpg123, bu neither
of these need codec header data. Should we ever add non-libavcodec
decoders, better data structures without the past hacks could be added
to export the headers.
2013-02-10 17:25:57 +01:00
wm4
dd61fac943 demux_lavf, ad_lavc, vd_lavc: refactor, cleanup
Rearrange some code to make it easier readable. Remove some dead code,
and stop printing AVI headers in demux_lavf. (These are not actual AVI
headers, just for internal use.)

There should be no functional changes, other than reducing output in
verbose mode.
2013-02-10 17:25:57 +01:00
wm4
4d016a92c8 core: redo how codecs are mapped, remove codecs.conf
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)

The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)

demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.

Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.

Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
2013-02-10 17:25:56 +01:00
wm4
88d843f909 cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAG
OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed),
but that has been long removed by special casing flag options in the
option parser. OPT_FLAG_ON() used to imply that there's no "no-"
prefixed option, but this hasn't been the case for a while either.
(Conceptually, it has been replaced by OPT_FLAG_STORE().)

Remove OPT_FLAG_OFF, which was unused.
2013-02-09 00:21:17 +01:00
wm4
c162b6d64d vd_lavc: add stupid hack to fix decoding of some files with Libav 0.8.x
The decoder returns with AVFrame.format not correctly set for some h264
files (strangely only some). We have to access AVCodecContext.pix_fmt
instead. On newer libavcodec versions, it's the other way around: the
AVCodecContext.pix_fmt may be incorrectly set on pixel format changes,
and you are supposed to use AVFrame.format.

The same problem probably exists on older ffmpeg versions too.
2013-01-24 12:43:36 +01:00
wm4
07d14bd323 Silence two compiler warnings
Both should be harmless.
2013-01-16 02:03:21 +01:00
wm4
4056765643 vd_lavc: remove -lavdopts vstats suboption
This printed per-frame statistics into a file, like bitrate or frame
type. Not very useful and accesses obscure AVCodecContext fields
(danger of deprecation/breakage), so get rid of it.
2013-01-13 23:30:12 +01:00
wm4
8e172afc8f vd_lavc: remove lowres decoding
This was a "broken misfeature" according to Libav developers. It wasn't
implemented for modern codecs (like h264), and has been removed from
Libav a while ago (the AVCodecContext field has been marked as
deprecated and its value is ignored). FFmpeg still supports it, but
isn't much useful due to aforementioned reasons.

Remove the code to enable it.
2013-01-13 23:29:30 +01:00
wm4
bd6470ec6a vd_lavc: prefer AVFrame over AVCodecContext fields
This is more correct. Not all frame specific fields are in AVFrame,
such as colorspace and color_range, and these are still queried
through the decoder context.
2013-01-13 20:04:13 +01:00
wm4
8751a0e261 video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)

Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.

Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)

The TV code has not been tested.

Some corrective changes regarding endian and other image format flags
creep in.
2013-01-13 20:04:11 +01:00
wm4
aa6ba6372c mp_image: change how palette is handled
According to DOCS/OUTDATED-tech/colorspaces.txt, the following formats
are supposed to be palettized:

    IMGFMT_BGR8
    IMGFMT_RGB8,
    IMGFMT_BGR4_CHAR
    IMGFMT_RGB4_CHAR
    IMGFMT_BGR4
    IMGFMT_RGB4

Of these, only BGR8 and RGB8 are actually treated as palettized in some
way. ffmpeg has only one palettized format (AV_PIX_FMT_PAL8), and
IMGFMT_BGR8 was inconsistently mapped to packed non-palettized RGB
formats too (AV_PIX_FMT_BGR8). Moreover, vf_scale.c contained messy
hacks to generate a palette when AV_PIX_FMT_BGR8 is output. (libswscale
does not support AV_PIX_FMT_PAL8 output in the first place.)

Get rid of all of this, and introduce IMGFMT_PAL8, which directly maps
to AV_PIX_FMT_PAL8. Remove the palette creation code from vf_scale.c.
IMGFMT_BGR8 maps to AV_PIX_FMT_RGB8 (don't ask me why it's swapped),
without any palette use. Enabling it in vo_x11 or using it as vf_scale
input seems to give correct results.
2013-01-13 20:04:11 +01:00
wm4
ab94c64ed2 mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.

Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.

Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.

Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2013-01-13 20:04:10 +01:00
wm4
c54fc507da video/filter: change filter API, use refcounting, remove filter DR
Change the entire filter API to use reference counted images instead
of vf_get_image().

Remove filter "direct rendering". This was useful for vf_expand and (in
rare cases) vf_sub: DR allowed these filters to pass a cropped image to
the filters before them. Then, on filtering, the image was "uncropped",
so that black bars could be added around the image without copying. This
means that in some cases, vf_expand will be slower (-vf gradfun,expand
for example).

Note that another form of DR used for in-place filters has been replaced
by simpler logic. Instead of trying to do DR, filters can check if the
image is writeable (with mp_image_is_writeable()), and do true in-place
if that's the case. This affects filters like vf_gradfun and vf_sub.

Everything has to support strides now. If something doesn't, making a
copy of the image data is required.
2013-01-13 20:04:10 +01:00
wm4
d77d9fb933 mp_image: require using mp_image_set_size() for setting w/h
Setting the size of a mp_image must be done with mp_image_set_size()
now. Do this to guarantee that the redundant fields (like chroma_width)
are updated consistently. Replacing the redundant fields by function
calls would probably be better, but there are too many uses of them,
and is a bit less convenient.

Most code actually called mp_image_setfmt(), which did this as well.
This commit just makes things a bit more explicit.

Warning: the video filter chain still sets up mp_images manually,
and vf_get_image() is not updated.
2013-01-13 17:39:32 +01:00
wm4
881f82dd33 vd_lavc: use refcounting
Note that if the codec doesn't support DR1, the image has to be copied.
There is no other way to guarantee that the image will be valid after
decoding the next image.

The only important codec that doesn't support DR1 yet is rawvideo. It's
likely that ffmpeg/Libav will fix this at some time. For now, this
decoder uses an evil hack and puts pointers to the packet data into the
returned frame. This means the image will actually get invalid as soon
as the corresponding video packet is free'd, so copying the image is the
only reasonable thing anyway.
2013-01-13 17:39:32 +01:00
wm4
a8e69707f7 vd_lavc: add DR1 support
Replace libavcodec's native buffer allocation with code taken from
ffplay/ffmpeg's libavfilter support. The code in lavc_dr1.c is directly
copied from cmdutils.c. Note that this is quite arcane code, which
contains some workarounds for decoder bugs and the like. This is not
really a maintainance burden, since fixes from ffmpeg can be directly
applied to the code in lavc_dr1.c.

It's unknown why libavcodec doesn't provide such a function directly.
avcodec_default_get_buffer() can't be reused for various reasons.
There's some hope that the work known as The Evil Plan [1] will make
custom get_buffer implementations unneeded.

The DR1 support as of this commit does nothing. A future commit will
use it to implement ref-counting for mp_image (similar to how AVFrame
will be ref-counted with The Evil Plan.)

[1] http://lists.libav.org/pipermail/libav-devel/2012-December/039781.html
2013-01-13 17:39:32 +01:00
wm4
58d196c07e video: different way to enable hardware decoding, add software fallback
Deprecate the hardware specific video codec entries (like ffh264vdpau).
Replace them with the --hwdec switch, which requests that a specific
hardware decoding API should be used. The codecs.conf entries will be
removed at a later time, but for now they are useful for testing and
compatibility.

Instead of --vc=ffh264vdpau, --hwdec=vdpau should be used.

Add a fallback if hardware decoding fails. Most hardware decoders
(including vdpau) support only a subset of h264, and having such a
fallback is supposed to enable a better user experience.
2013-01-13 17:39:32 +01:00
wm4
dab286a159 vd_lavc: remove codec DR
This was buggy and didn't even work in the simplest cases. It was
disabled when multithreading was used, and always disabled for h264.

A better alternative (reference counting) will be added later.

Hardware decoding still uses the ffmpeg DR mechanism, but has been
decoupled from mpv's DR in the previous commit.
2013-01-13 17:39:32 +01:00
wm4
2d8fb838d7 video: make vdpau hardware decoding not use DR code path
vdpau hardware decoding used the DR (direct rendering) path to let the
decoder query a surface from the VO. Special-case the HW decoding path
instead, to make it separate from DR.
2013-01-13 17:39:32 +01:00
wm4
0d1aca1289 vd_lavc: do not mutate global threads option
This mutated the variable for the thread count option
(lavc_param->threads) on decoder initialization. This didn't have any
practical relevance, unless formats supporting hardware video decoding
and other formats were played in the same mpv instance. In this case,
hardware decoding would set threads to 1, and all files played after
that would use only one thread as well even with software decoding.

Remove XvMC leftover (CODEC_CAP_HWACCEL).
2013-01-13 17:39:31 +01:00
wm4
fcd6e74e48 vd_lavc: cosmetics: move debugging code out of the way
Relatively useless statistics printing code was stuffed directly into
the middle of the central decode() function. Move it away.
2013-01-13 17:39:31 +01:00
wm4
06ccd9f671 video: simplify decoder pixel format handling
Simplify the decoder pixel format handling by making it handle only
the case vd_lavc needs: a video stream always decodes to a single
pixel format.

Remove the handling for multiple pixel formats, and remove the
codecs.conf pixel format declarations that are left.

Remove the handling of "ambiguous" pixel formats like YV12 vs. I420 (via
VDCTRL_QUERY_FORMAT etc.). This is only a problem if the video chain
supports I420, but not YV12, which doesn't seem to be the case anywhere,
and in fact would not have any advantage.

Make the "flip" flag a global per-codec flag, rather than a pixel format
specific flag. (Some ffmpeg decoders still return a flipped image, so
this has to be done manually.) Also fix handling of the flip operation:
do not overwrite the global flip option, and make the --flip option
invert the codec flip option rather than overriding it.
2013-01-13 17:39:31 +01:00
wm4
23ab098969 video: remove slice based filtering and video output
Slices allowed filtering or drawing video in horizontal bands or
blocks. This allowed working on the video in smaller units. In theory,
this could bring a performance win by lowering cache pressure, as you
didn't have to keep the whole video frame in cache while filtering,
only the slice.

In practice, the slice code path was barely used for the following
reasons:
- Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg
  slice callback was disabled, because it can be called from another
  thread, and the mplayer video chain is not thread-safe.
- There was nothing that would turn "full" images into appropriate
  slices, so slices were rarely used.
- Most filters didn't actually support slices.

On the other hand, supporting slices lead to code duplication and more
complex code in general. I made some experiments and didn't find any
actual measurable performance improvements when using slices. Even
ffmpeg removed slices based filtering from libavfilter in favor of
simpler code.

The most broken thing about the slices code path is that slices can't
be queued, like it is done for images in vo.c.
2013-01-13 17:39:31 +01:00
wm4
cfa1f9e082 video: make vdpau hardware decoding not use slices code path
For some reason, libavcodec abuses the slices rendering code path for
hardware decoding: in that case, the only purpose of the draw callback
is to pass a vdpau video surface object to video output. (It is unclear
to me why this had to use the slices code, instead of just returning an
AVFrame with the required vdpau state.)

Make this code separate within mpv, so that the internal slices code
path is not used for hardware decoding. Pass the vdpau state with
VOCTRL_HWDEC_DECODER_RENDER instead.

Remove the mencoder specific VOCTRLs.
2013-01-13 17:39:31 +01:00
wm4
46cf722d80 Add missing compat/libav.h includes
For avcodec_free_frame().
2012-11-12 20:08:24 +01:00
wm4
4873b32c59 Rename directories, move files (step 2 of 2)
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.

The two commits are separate, because git is bad at tracking renames
and content changes at the same time.

Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
2012-11-12 20:08:18 +01:00
wm4
d4bdd0473d Rename directories, move files (step 1 of 2) (does not compile)
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.
2012-11-12 20:06:14 +01:00