1
0
mirror of https://github.com/mpv-player/mpv synced 2025-03-11 08:37:59 +00:00
Commit Graph

543 Commits

Author SHA1 Message Date
wm4
9a88b118b4 video: decouple filtering/decoding slightly more
Lots of noise to remove the vfilter/vo fields from dec_video.

From now on, video filtering and output will still be done together,
summarized under struct vo_chain.

There is the question where exactly the vf_chain should go in such a
decoupled architecture. The end goal is being able to place a "complex"
filter between video decoders and output (which will culminate in
natural integration of A->V filters for natural integration of
libavfilter audio visualizations). The vf_chain is still useful for
"final" processing, such as format conversions and deinterlacing. Also,
there's only 1 VO and 1 --vf option. So having 1 vf_chain for a VO seems
ideal, since otherwise there would be no natural way to handle all these
existing options and mechanisms.

There is still some work required to truly decouple decoding.
2016-01-14 00:18:48 +01:00
wm4
5722f93a74 video: refactor: shuffle code around
struct dec_video should have nothing to do with video filters or
outputs, and this huge chunk of code was somehow stuck directly in
dec_video.c.
2016-01-14 00:18:36 +01:00
wm4
bf13bd0d47 video: refactor: handle video format fixups closer to decoder
Instead of handling this on filter chain reinit, do it directly after
the decoder. This makes the code less entangled. In particular, this
gets rid of the really weird "override params" concept in the video
filter code.

The last_format/fixed_formats have some redundance with decoder_output,
but unfortunately the latter has a slightly different use.
2016-01-14 00:18:31 +01:00
wm4
671df54e4d demux: merge sh_video/sh_audio/sh_sub
This is mainly a refactor. I'm hoping it will make some things easier
in the future due to cleanly separating codec metadata and stream
metadata.

Also, declare that the "codec" field can not be NULL anymore. demux.c
will set it to "" if it's NULL when added. This gets rid of a corner
case everything had to handle, but which rarely happened.
2016-01-12 23:48:19 +01:00
Dmitrij D. Czarkoff
ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +01:00
wm4
9acea8759b dxva2: log more debug infos
Dump the complete list of decoders and image formats. If it's a decoder
we know, add a stringified name.
2016-01-11 16:24:13 +01:00
wm4
2a80680d95 Fix build on older libavcodec versions
avcodec_profile_name() was added only a week ago or so.
2016-01-08 17:19:04 +01:00
wm4
12b4f177ec vd_lavc: log codec profile when attempting hardware decoding
Should be useful.
2016-01-08 09:22:25 +01:00
BtbN
5790bbba61 vaapi: add VP9 profile entires 2015-12-20 10:40:06 +01:00
wm4
0a0bb9059f video: switch from using display aspect to sample aspect
MPlayer traditionally always used the display aspect ratio, e.g. 16:9,
while FFmpeg uses the sample (aka pixel) aspect ratio.

Both have a bunch of advantages and disadvantages. Actually, it seems
using sample aspect ratio is generally nicer. The main reason for the
change is making mpv closer to how FFmpeg works in order to make life
easier. It's also nice that everything uses integer fractions instead
of floats now (except --video-aspect option/property).

Note that there is at least 1 user-visible change: vf_dsize now does
not set the display size, only the display aspect ratio. This is
because the image_params d_w/d_h fields did not just set the display
aspect, but also the size (except in encoding mode).
2015-12-19 20:45:36 +01:00
wm4
565efeeada vd_lavc: fix avctx NULL checks
If reinit after a fallback from hardware fails, this field can be NULL.
The check in control() was broken due to a typo (found by Coverity), and
decode() lacked the check entirely.
2015-12-05 23:53:55 +01:00
wm4
344d44681e video: readd codec delay estimation
Approximately reverts commit 3ccac74d. This failed with some avi files,
which do pseudo-VFR by sending packets with empty frames (or repeat
frames, depending on point of view). Specifically, these packets are not
0 bytes, so they don't get skipped by libavformat, as with the usual VFR
avi hack. Instead, the packet contains a VOP with vop_coded=0, so
libavcodec will just return no frame. We could probably distinguish such
skipped frames and delayed frames by explicitly measuring the codec
delay by counting how long it takes to get the very first frame (and
then treat skips as explicit drops), but we may as well simply reinstate
the old code.

To appease to at least one semi-broken case, do not enable this logic on
the RPI, as the FFmpeg MMAL wrapper has arbitrary buffering (and MMAL
itself is asynchronous).
2015-12-02 14:38:47 +01:00
wm4
52af1f72e2 dxva2: reject 10 bit HEVC
10 bit HEVC would require DXVA2_ModeHEVC_VLD_Main10, and most a
different surface type (judging by lavfsplitter source code, both
P010 and P016 would work). Since I'm unable to test this stuff,
exclude 10 bit for now.

See #2516.
2015-11-23 12:38:06 +01:00
wm4
0ec35fa111 videotoolbox: make decoder format customizable
Because apparently there's no ideal universally working format.

The weird OpenGL texture format for kCVPixelFormatType_32BGRA is from:

http://stackoverflow.com/questions/22077544/draw-an-iosurface-to-an-opengl-context

(Which apparently got it from the linked Apple example code.)
2015-11-17 21:21:19 +01:00
wm4
9a6ec9de2f vd_lavc: be more careful with flushing the decoder
Until now, we've relied on the following things:

- you can send flush packets to the decoder even if it's fully flushed,
- you can send new packets to a flushed decoder,
- you can send new packers to a partially flushed decoder.

("flushing" refers to sending flush packets to the decoder until the
decoder does not return new pictures, not avcodec_flush_buffers().)

All of these are questionable. The libavcodec API probably doesn't
guarantee that these work well or at all, even though most decoders have
no issue with these. But especially with hardware decoding wrappers
(like MMAL), real problems can be expected. Isolate us from these corner
cases by handling them explicitly.
2015-11-10 16:06:42 +01:00
wm4
b2a3e877c0 video: increase avi pts buffer size
When decoding on RPI/MMAL, the buffering between decoder input and
output can be quite excessive.
2015-11-06 17:06:32 +01:00
wm4
2cf9ee989c rpi: add support for codecs other than h264
FFmpeg now supports h264 and mpeg2. At least vc-1 will probably follow.
2015-11-05 17:24:35 +01:00
wm4
163c6ad862 vd_lavc: make hwdec fallback more tolerant
A hw decoder might fail to decode a frame for multiple reasons, and not
always just because decoding is impossible. We can't generally
distinguish these reasons well. Make it more tolerant by accepting
failures of 3 frames, but not more. The threshold can be adjusted by the
repurposed --vd-lavc-software-fallback option.

(This behavior was suggested much earlier in some PR, but at the time
the "proper" hwdec fallback was indistinguishable from decoding error.
With the current situation, "proper" fallback is still instantious.)
2015-11-03 14:03:02 +01:00
wm4
1d2d649281 vdpau: fix uninit when init fails
The uninit() function was called twice if the uninit() function failed
(once by init(), once by vd_lavc.c code), which caused crashes due to
double-free. (This failure is a corner case, and all other hwdec
backends appear to handle this case gracefully.)

I do not think this code should be able to deal with uninit() being
called other than once. Guarantee that it's called exactly once.
2015-11-01 23:03:02 +01:00
wm4
3dec68ba47 vd_lavc: fix declarations
Fixes linker failure. How did this ever work? Apparently it did most of
the time, but apparently we just got the first case where it didn't.

Fixes #2433.
2015-10-30 09:41:55 +01:00
Rodger Combs
d6e7190836 vd_lavc: make software decoding fallback an option 2015-10-25 15:21:11 +01:00
wm4
50f8548b2f vd_lavc: attempt to fallback from hwdec before anything is decoded
The previous commit moved the av_frame_unref() after the got_picture
check. This accidentally also deferred the software fallback
reinitialization to until a software picture was decoded (instead of the
exact time of the fallback), which is not ideal.

Just rely on the fact that calling av_frame_unref() on a frame is ok
even if nothing was decoded.
2015-10-19 18:19:57 +02:00
wm4
0ab6031d76 vd_lavc: continue decoding properly after decoding failure
Commit 12cd48a8 started setting the hwdec_failed field even if hwdec was
not active, and because it also checked this field even if hwdec was not
active, broke decoding forever.

Fix this, and also avoid a memory leak or API misuse by releasing the
decoded picture. Passing an unreleased frame to the decoder has as far
as I know no defined effects.
2015-10-19 17:49:30 +02:00
wm4
8d004f07a4 vd_lavc: work around libavcodec nonsense causing hwdec init failure
The libavcodec h264 decoder contains some idiotic code with unknown
purpose (no sample or explanation known that necessitates its
existence), that causes the AVCodecContext.get_format callback to be
invoked at a time when hwaccels can't be initialized. By definition, the
get_format callback is supposed to initialize hwaccels (another idiotic
thing now part of the API, but different story). This causes hwdec
initialization sometimes to fail (WolfensteinTwitch.mp4): the first
get_format callback will mark it as failed, so the second get_format
(the "proper" normal one) will not bother restoring the state, and hwdec
init fails.

While this should be fixed in libavcodec (good luck with that), it's
quite easy to workaround.
2015-10-12 21:24:25 +02:00
wm4
9e7069fde2 vd_lavc: refuse to initialize vaapi with unknown profiles
Bad idea, although I'm not sure how harmful it actually was.

Although this is common code, only the vaapi hwaccel still uses it.
2015-10-11 18:48:02 +02:00
wm4
b4804a4b26 video: fix base for --no-correct-pts
Use the first encountered packet PTS/DTS as base, instead of the last
one. This does not add the amount of frames buffered in the codec to the
PTS offset, and thus is better.

Also, don't add the frame time if there was no decoded frame yet. The
first frame should obviously have the timestamp of the first packet
(going by this heuristic).
2015-10-06 18:19:20 +02:00
wm4
5015759334 video: increase maximum number of buffered AVI pts samples
While b-frame reordering limits the maximum required number to around
16, the number of additionally buffered frames can be much higher.

Guess when this actually matters? (For the libavcodec MMAL wrapper.)
2015-10-06 18:19:20 +02:00
wm4
3c292395ca video: don't sort AVI pts samples
It's obviously not needed, and only an artifact of the old PTS
determination code.
2015-10-06 18:19:20 +02:00
wm4
8e654d3f78 video: remove user-controllable PTS sorting (--pts-association-mode)
Useless. Sometimes it might be useful to make some extremely broken
files work, but on the other hand --no-correct-pts is sufficient for
these cases.

While we still need some of the code for AVI, the "auto" mode in
particular inflated the size of the code.
2015-10-06 18:19:20 +02:00
wm4
0e245b3752 video: disable framedrop if avi-style timestamps are used
This can't be handled correctly at all. Other cases when the decoder
might drop a frame (such as completely failing to decode a frame) will
shift timestamps by a frame, and it can't be avoided.

While we could maybe find a better way to handle this with libavcodec's
main decoders, this seems to be much harder if it should work with
certain HW decoders, which don't passthrough the DTS field (such as
MMAL). Another problem are .avi files with b-frames. So just leave it
as it is.
2015-10-06 18:18:57 +02:00
wm4
3ccac74de2 video: remove codec delay estimation
This was used only by the timestamp sorting code, which is a fallback
for avi files (as well as avi-muxed mkv files). This was supposed to
prevent accumulating timestamps in case the decoder consumes more
packets than it outputs frames (i.e. frames are dropped). This didn't
work very well (timestamps could be off by a large amount), the
estimation of the delay was fragile, and the interdependencies with the
decoder were annoying, so kill it.
2015-10-03 22:10:44 +02:00
wm4
ee283843fa video: cosmetics: remove trailing whitespace 2015-10-03 21:21:27 +02:00
wm4
12cd48a8a9 Revert "vd_lavc: do not abort hardware decoding on errors"
This essentially reverts commit 009dfbe3. FFmpeg VideoToolbox support
is being wacky, and can cause major issues, such as not being able
to decode a single frame. (E.g. by playing a .ts file. This should be
fixed in FFmpeg eventually.)

This is not a straight revert of the commit; just a functional one. We
keep the slightly simpler code structure.
2015-09-28 22:31:47 +02:00
wm4
1dd7b7bddc video: remove VDA support
VideoToolbox is preferred. Now that FFmpeg released 2.8, there's no
reason to support VDA anymore. In fact, we had a bug that made VDA not
useable with older FFmpeg versions in some newer mpv releases.

VideoToolbox is supported even on slightly older OSX versions, and if
not, you still can run mpv without hw decoding.
2015-09-28 22:03:14 +02:00
wm4
15ef9f9ee6 vd_lavc: remove some ancient cargo-culting
Definitely not needed anymore, and fixes a crash in some weird corner-
cases.

The extradata freeing is apparently still needed, though. (Because a
codec context can be opened again, which makes no sense, but ok.)
2015-09-28 22:03:14 +02:00
wm4
710872bc22 vaapi: remove dependency on X11
There are at least 2 ways of using VAAPI without X11 (Wayland, DRM).
Remove the X11 requirement from the decoder part and the EGL interop.
This will be used by a following commit, which adds Wayland support.

The worst about this is the decoder part, which includes a bad hack for
using the decoder without any VO interop (also known as "vaapi-copy"
mode). Separate the X11 parts so that they're self-contained. For the
EGL interop code we do something similar (it's kept slightly simpler,
because it essentially only has to translate between our silly
MPGetNativeDisplay abstraction and the vaGetDisplay...() call).
2015-09-27 21:33:15 +02:00
wm4
0ae8aebb89 video: refactor GPU memcpy usage
Make the GPU memcpy from the dxva2 code generally useful to other parts
of the player.

We need to check at configure time whether SSE intrinsics work at all.
(At least in this form, they won't work on clang, for example. It also
won't work on non-x86.)

Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some
awkward stuff to share the existing code used by mp_image_copy(). I'm
hoping that FFmpeg will sooner or later provide a function like this, so
we can remove most of this again. (There is a patch, bit it's stuck in
limbo since forever.)

All this is used by the following commit.
2015-09-25 19:18:16 +02:00
Philip Langdale
361040f9d9 vd_lavc: Fix recovery from vdpau preemption
Flushing buffers, and thereby triggering decoder reinitialisation
needs to happen before attempting, and failing, to decode.
2015-09-25 17:29:44 +02:00
wm4
009dfbe3b6 vd_lavc: do not abort hardware decoding on errors
Usually, libavcodec ignores errors reported by the hardware decoding
API, so it's not like we can actually escape if the hardware is somehow
acting up.

For normal fallback purposes, or if parts of the hw decoding API which
we actually check fails, we do this by setting and checking the
hwdec_failed flag anyway.
2015-09-23 20:37:47 +02:00
wm4
4d6c1be7b6 vd_lavc: minor cleanup to hwdec fallback code
The comment was largely outdated, and described the old situation when
we used a "violent" fallback by making get_buffer2 fail completely.

Also, for the case when the hw decoder initialization succeeded (in
get_format), but get_buffer2 for some reason requests something
unexpected, we also can fallback more gracefully and in the same way.
2015-09-23 14:20:50 +02:00
Kevin Mitchell
269f271b73 video: make --field-dominance set interlaced flag
fixes #2289
2015-09-10 23:46:06 -07:00
wm4
61b902f5a7 vd_lavc: better hwdec log output
Often, we don't know whether hardware decoding will work until we've
tried. (This used to be different, but API changes and improvements in
libavcodec led to this situation.) We will often output that we're going
to use hardware decoding, and then print a fallback warning.

Instead, print the status once we have decoded a frame.

Some of the old messages are turned into verbose messages, which should
be helpful for debugging. Also add some new ones.
2015-09-02 23:33:13 +02:00
wm4
11f44a10f9 vd_lavc: factor all hwdec fallbacks into the same function
The fallback at initialization time was basically duplicated, maybe for
the sake of showing a different error message. This doesn't matter
anymore; not much can fail at initialization anymore. Most meaningful
and common errors happen either at probing or in get_format (when the
actual hw decoder is initialized).
2015-09-02 23:10:39 +02:00
wm4
82f0d373fb video: make container vs. bitstream aspect ratio configurable
Utterly idiotic bullshit.

Fixes #2259.
2015-08-30 23:04:17 +02:00
wm4
1ec1b4186c vd_lavc: bump number of allocated surfaces for hwdec with HEVC 2015-08-24 23:02:40 +02:00
wm4
2172c22ee3 vaapi: add HEVC profile entries
libavcodec does not support HEVC via VAAPI yet, so this won't work.
However, there is ongoing work to add HEVC support to VAAPI, and this
change might help with testing. (Or maybe not - but there is no harm in
this change.)
2015-08-24 23:00:45 +02:00
wm4
bffd78748f vd_lavc: remove unneeded hwdec parameters
All hwdec backends now use a single pixel format, and the format is
always checked.

Also, the init_decoder callback is now mandatory.
2015-08-19 21:33:18 +02:00
wm4
6894858bf2 video: fix VideoToolbox/VDA autodetection
This affects vo_opengl_cb in particular: it'll most likely auto-load
VDA, and then the VideoToolbox decoder won't work. And everything fails.

This is mainly caused by FFmpeg using separate pixfmts for the _same_
thing (CVPixelBuffers), simply because libavcodec's architecture demands
that hwaccel backends are selected by pixfmts. (Which makes no sense,
but now we have the mess.)

So instead of duplicating FFmpeg's misdesign, just change the format to
our own canonical one on the image output by the decoder. Now the GL
interop code is exactly the same for VDA and VT, and we use the VT name
only.
2015-08-17 23:51:31 +02:00
wm4
8d66bd76e2 video: remove old vdpau hwaccel API usage
While the "old" libavcodec vdpau API is not deprecated (only the very-
old API is), it's still relatively complicated code that badly
duplicates the much simpler newer vdpau code. It exists only for the
sake of older FFmpeg releases; get rid of it.
2015-08-10 00:07:35 +02:00
Sebastien Zwickert
31b5a211f4 hwdec: add VideoToolbox support
VDA is being deprecated in OS X 10.11 so this is needed to keep hwdec working.
The code needs libavcodec support which was added recently (to FFmpeg git,
libav doesn't support it).

Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
2015-08-05 17:47:30 +02:00
wm4
41101c2996 win32: revert wchar_t changes
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"

Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
2015-08-01 21:09:11 +02:00
wm4
fefac2c941 win32: more wchar_t -> WCHAR replacements
This was essentially missing from commit 0b52ac8a.

Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.

For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
2015-07-30 21:50:11 +02:00
wm4
281c21b7f1 video: don't restrict --vd-lavc-threads to a maximum of 16
Only do it when the number of threads is autodetected, as more than 16
threads are still considered not recommended. (libavcodec prints a
warning.)
2015-07-23 17:17:26 +02:00
wm4
d1c37c0e29 vaapi: allow allocating additional surfaces during decoding
Fixes problems with --vo=opengl:interpolation. The issue here is that
vo_opengl retains more surfaces than what was preallocated for the
decoder. Until now, we just explicitly failed to decode frames for which
no additional surfaces are available. Since modern drivers usually are
fine with not "registering" surfaces before the decoder is created, just
allow allocating additional surfaces if needed.

(We also could probably recreate the HW decoder, since the HW decoder
should be stateless. But let's try to avoid raising the overall
complexity of the code.)
2015-07-15 12:37:28 +02:00
wm4
9620e37d6a vaapi: increase number of additional surfaces
Sometime recently, hardware decoding started to fail if h264 with full
reference frames was decoded, and --vo=vaapi was used. VAAPI requires
registering all surfaces that the decoder will ever use in advance, so
if the playback chain uses more surfaces than originally allocated, we
fail and drop back to software decoding.

I'm not really sure why or when this started happening. Commit 7b9d7265
for one is not the cause - it can be reproduced with earlier commits. It
also seems to be timing dependent. Possibly it has to do with the way
vo.c retains previous surfaces, and the way they can be queued/unqueued
asynchronously.

Increasing the number of reserved additional surfaces by 1 fixes it.

(Though I have no idea where exactly all these surfaces are being used.
Or rather, _when_.)
2015-07-08 12:18:29 +02:00
wm4
dcd167ca37 dxva2: fix handling of cropped video
Basically, we need to make sure to allocate enough data for the pretty
dumb copy_nv12 function. (It could be avoided by making the function
less dumb, but this fix is simpler.)
2015-07-06 21:25:07 +02:00
wm4
7b9d726588 video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.

Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.

There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 23:56:00 +02:00
wm4
561416597e client API, dxva2: add a workaround for OpenGL fullscreen issues
This is basically a hack for drivers which prevent the mpv DXVA2 decoder
glue from working if OpenGL is in fullscreen mode.

Since it doesn't add any "hard" new API to the client API, some of the
code would be required for a true zero-copy hw decoding pipeline, and
sine it isn't too much code after all, this is probably acceptable.
2015-07-03 16:38:12 +02:00
wm4
b85321d057 vo_direct3d, dxva2: use the same D3D device
Since we still read-back (and don't have hard plans on changing this),
this doesn't have much of an advantage.
2015-07-03 16:04:42 +02:00
wm4
b6dc11810b dxva2: move device creation code
Preparation for the following commit.
2015-07-03 15:42:52 +02:00
wm4
a5b96226a0 vaapi: prefer direct display over copy-back
Again. With the old OpenGL interop dropped, this probably works better
than vaapi-copy now. Last time we defaulted to vaapi-copy, because the
OpenGL interop could swap U/V planes and other stupid crap. We'll see.
2015-06-29 15:14:38 +02:00
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
e00e9d651b player: make decoding cover art more robust
When showing cover art, the decoding logic pretends that the source has
an infinite number of frames. This slightly simplifies dealing with
filter data flow. It was done by feeding the same packet repeatedly to
the decoder (each decode run produces new output).

Change this by decoding once at the video initialization. This is easier
to follow, and increases robustness in case of broken images. Usually,
we try to tolerate decoding errors, so decoding normally continues, but
in this case it would just burn the CPU for no reason.

Fixes #2056.
2015-06-18 18:39:46 +02:00
wm4
d3894290ec vaapi: remove direct mapping non-sense
This must have been some non-sense in the original vaapi mplayer patch.
While I still have no good idea what this "direct mapping" business is
about, it appears to be pretty much pointless. Nothing can hold
additional "real" surface references (due to how the API and mpv/lavc
refcounting work), so removing the additional surfaces won't break
anything. It still could be that this was for achieving additional
buffering (not reusing surfaces as soon), but we buffer some additional
data anyway. Plus, the original intention of the vaapi mplayer code was
probably increasing surface count just by 1 or 2, not actually doubling
it, and/or it was a "trick" to get to the maximum count of 21 when h264
is in use.

gstreamer-vaapi uses "ref_frames + SCRATCH_SURFACES_COUNT" here, with
SCRATCH_SURFACES_COUNT defined to 4. It doesn't appear to check the
overlay attributes at all in the decoder.

In any case, remove this non-sense.
2015-05-29 16:28:55 +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
0699a6c598 video: rename vdpau.c to vdpau_old.c
vdpau.c will be used for new code.
2015-05-28 21:56:09 +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
a2235b0280 dxva2: support HEVC
This is pretty much copy&pasted from Libav commit
a7e0380497306d9723dec8440a4c52e8bf0263cf.

Note that if FFmpeg was not compiled with HEVC DXVA2 support or your
video drivers do not support HEVC, the player will not fallback and
just fail decoding any video. This is because libavcodec appears not
to return an error in this case. The situation is made worse by the
fact that MSYS2 is on an ancient MinGW-w64 release, which does not
have the required headers for HEVC DXVA2 support.
2015-05-14 17:44:48 +02:00
Stefano Pigozzi
5258c012fe vda: add support for nv12 image formats
The hardware always decodes to nv12 so using this image format causes less cpu
usage than uyvy (which we are currently using, since Apple examples and other
free software use that). The reduction in cpu usage can add up to quite a bit,
especially for 4k or high fps video.

This needs an accompaning commit in libavcodec.
2015-05-13 19:57:39 +02:00
Avi Halachmi (:avih)
e2326bda82 dxva2: fix broken build with gcc 5.1
gpu_mempcy should to be called from code which targets SSE

Signed-off-by: wm4 <wm4@nowhere>
2015-04-24 17:40:39 +02:00
wm4
74ae74db0c video: cleanup some old log messages
These are basically MPlayer leftovers, and barely useful due to being
redundant with other messages. The FPS message is used somewhere else.
2015-04-20 23:19:19 +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
Dan Oscarsson
33d587ffa9 vdpau: fix preemption handling
Signed-off-by: wm4 <wm4@nowhere>
2015-03-31 14:48:34 +02:00
wm4
27715b7dd1 video: move colorspace overrides to vf_format, simplify
Remove the colorspace-related top-level options, add them to vf_format.
They are rather obscure and not needed often, so it's better to get them
out of the way. In particular, this gets rid of the semi-complicated
logic in command.c (most of which was needed for OSD display and the
direct feedback from the VO). It removes the duplicated color-related
name mappings.

This removes the ability to write the colormatrix and related
properties. Since filters can be changed at runtime, there's no loss of
functionality, except that you can't cycle automatically through the
color constants anymore (but who needs to do this).

This also changes the type of the mp_csp_names and related variables, so
they can directly be used with OPT_CHOICE. This probably ended up a bit
awkward, for the sake of not adding a new option type which would have
used the previous format.
2015-03-31 00:09:03 +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
fe0c37b007 player: better handling of video with no timestamps
Trying to handle such video is almost worthless, but it was requested by
at least 2 users.

If there are no timestamps, enable byte seeking by setting
ts_resets_possible. Use the video FPS (wherever it comes from) and the
audio samplerate for timing. The latter was already done by making the
first packet emit DTS=0; remove this again and do it "properly" in a
higher level.
2015-03-20 22:08:12 +01:00
wm4
47c131bb0c player: warn against non-monotonic video PTS only once
For some reason there were two points in the code where it warned
against non-monotonic video PTS. The one in video.c triggered on PTS
going backwards or making large jumps forwards, while dec_video.c
triggered on PTS going backwards or PTS not changing. Merge them into a
single check, which warns against all cases.
2015-03-18 22:26:49 +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
d96fad04be video: don't drop anamorphic scaling if it's too minor
This played e.g. a 1264x722 file as 1264x720. There was some code which
dropped the aspect ratio if the video (in original resolution) wasn't
scaled by more than 4 pixels. Commit 5f3c3f8c introduced this (although
I'm not really sure what the code replaced by it did).

Just remove this "feature".
2015-03-16 20:39:24 +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
wm4
c31e5da734 Remove some FFmpeg/Libav compatibility hacks
All of these are now in the supported FFmpeg and Libav versions.

The 3 remaining API checks are for FFmpeg-only things.
2015-03-03 12:28:46 +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
d71bbcbc98 video: un-discourage "vaapi-copy" hwdec mode
Maybe I don't know what I'm doing. I'm fairly certain though that Intel
does not know what they're doing.
2015-02-20 22:24:37 +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
2a9534871d command: add property returning detected hwdec API
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)

This also requires every hwdec backend to identify itself (see hwdec.h
changes).
2015-02-02 22:43:13 +01:00
wm4
aae9af348e video: have a generic context struct for hwdec backends
Before this commit, each hw backend had their own specific struct types
for context, and some, like VDA, had none at all. Add a context struct
(mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec
context around. Some things get slightly better, some slightly more
verbose.

mp_hwdec_info is still around; it's still needed, but is reduced to its
role of handling delayed loading of the hwdec backend.
2015-01-22 15:32:23 +01:00
wm4
f61b8b312d win32: request UTF-16 API variants, Vista+ APIs, and COM C macros
Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into
the build system, instead of defining them over and over in the code.
2015-01-07 21:42:44 +01:00
James Ross-Gowan
a095958263 dxva2: copy mp_image attributes to sw_img 2015-01-07 23:00:22 +11: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
James Ross-Gowan
a95ce07273 dxva2: use gpu_memcpy with unmatched strides
Like memcpy_pic, this checks if the strides match first.
2014-10-27 12:37:25 +01:00
James Ross-Gowan
ac35e3b308 dxva2: fix copying surfaces with different stride 2014-10-27 10:56:00 +01:00
wm4
f22acd94af dxva2: fix crash on initialization failure
If dxva2_init() fails, dxva2_uninit() will be called twice.
2014-10-26 15:42:47 +01:00
James Ross-Gowan
0166f2c7a0 dxva2: gpu_memcpy: fix build for GCC 4.8.3 2014-10-26 13:56:41 +01:00
James Ross-Gowan
52b52800ce dxva2: use optimized memcpy
At least on my machine, reading back the frame with system memcpy is
slower than just using software rendering. Use the optimized gpu_memcpy
from LAV to speed things up.
2014-10-26 02:34:15 +02: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
b518142236 build: handle insane libavcodec API bullshit
The oldest supported FFmpeg release doesn't provide
av_vdpau_alloc_context(). With these versions, the application has no
other choice than to hard code the size of AVVDPAUContext. (On the other
hand, there's av_alloc_vdpaucontext(), which does the same thing, but is
FFmpeg specific - not sure if it was available early enough, so I'm not
touching it.)

Newer FFmpeg and Libav releases require you to call this function, for
ABI compatibility reasons. It's the typcal lakc of foresight that make
FFmpeg APIs terrible. mpv successfully pretended that this crap didn't
exist (ABI compat. is near impossible to reach anyway) - but it appears
newer developments in Libav change the function from initializing the
struct with all-zeros to something else, and mpv vdpau decoding would
stop working as soon as this new work is relewased.

So, add a configure test (sigh).

CC: @mpv-player/stable
2014-09-05 01:52:29 +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
7520d39e8b vaapi: we need more surfaces
Playing with high framedrop could make it run out of surfaces. In
theory, we wouldn't need an additional surface, if we could just clear
the vo_vaapi internal surface - but doing so would probably be a pain,
so I don't care.
2014-08-18 22:59:01 +02:00
wm4
df58e82237 video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.

In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.

This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.

Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.

Side note:

Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.

As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:24:08 +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
056622c33e vaapi: fix uninitialized value read
Found with valgrind. This is somewhat terrifying, because the VA-API API
function is supposed to fill these values, and we access them only if
the API functions return success. So this shouldn't have happened.
2014-08-11 21:57:41 +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
Stefano Pigozzi
6aac17cebb vda: only support the new hwaccel 1.2 API (remove old code)
Since the new hwaccel API is now merged in ffmpeg's stable release, we can
finally remove support for the old API.

I pretty much kept lu_zero's new code unchanged and just added some error
printing (that we had with the old glue code) to make the life of our users
less miserable.
2014-08-01 10:38:18 +02:00
wm4
338004bcfc dvd, bluray, cdda: add demux_disc containing all related hacks
DVD and Bluray (and to some extent cdda) require awful hacks all over
the codebase to make them work. The main reason is that they act like
container, but are entirely implemented on the stream layer. The raw
mpeg data resulting from these streams must be "extended" with the
container-like metadata transported via STREAM_CTRLs. The result were
hacks all over demux.c and some higher-level parts.

Add a "disc" pseudo-demuxer, and move all these hacks and special-cases
to it.
2014-07-05 17:07:15 +02:00
Niklas Haas
ef6db24366 options: Expose --colormatrix-primaries to the user
Signed-off-by: wm4 <wm4@nowhere>
2014-06-22 19:01:25 +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
wm4
498c997474 player: hide audio/video codec and file format messages
None of these are very important usually. For error analysis, the plain
log is useless anyway, and this information is still printed with "-v".
2014-05-31 22:07:36 +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
Marcoen Hirschberg
434242adb5 audio: rename i_bps to 'bitrate' to avoid confusion
Since i_bps now contains bits/sec, rename it to reflect this change.
2014-05-28 21:37:50 +02:00
Marcoen Hirschberg
6e58b20cce audio: change values from bytes-per-second to bits-per-second
The i_bps members of the sh_audio and dev_video structs are mostly used
for displaying the average audio and video bitrates. Keeping them in
bits-per-second avoids truncating them to bytes-per-second and changing
them back lateron.
2014-05-28 21:37:44 +02:00
wm4
b442b522f6 vaapi: fix destruction with --hwdec=haapi-copy
This is incomplete; the video chain will still hold some vaapi objects
after destroying the decoder and thus the vaapi context. This is very
bad. Fixing it would require something like refcounting the vaapi
context, but I don't really want to.
2014-05-28 02:08:45 +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
22b16a40e5 video: better handling for (very) broken timestamps
Sometimes, Matroska files store monotonic PTS for h264 tracks with
b-frames, which means the decoder actually returns non-monotonic PTS.

Handle this with an evil trick: if DTS is missing, set it to the PTS.
Then the existing logic, which deals with falling back to DTS if PTS is
broken. Actually, this trick is not so evil at all, because usually, PTS
has no errors, and DTS is either always set, or always unset. So this
_should_ provoke no regressions (famous last words).

libavformat actually does something similar: it derives DTS from PTS in
ways unknown to me. The result is very broken, but it causes the DTS
fallback to become active, and thus happens to work.

Also, prevent the heuristic from being active if PTS is merely monotonic
instead of strictly-monotonic. Non-unique PTS is broken, but we can't
fallback to DTS anyway in these cases.

The specific mkv file that is fixed with this commit had the following
fields set:

  Muxing application: libebml v1.3.0 + libmatroska v1.4.1
  Writing application: mkvmerge v6.7.0 ('Back to the Ground') [...]

But I know that this should also fix playback of mencoder produced mkv
files.
2014-05-27 21:58:07 +02:00
wm4
6125ba613f video: add --video-rotate option for controlling auto-rotation 2014-05-24 16:17:52 +02:00
wm4
b3aa5dafa3 vdpau: don't fallback to software decoding on preemption
This was requested by someone. Not sure if it's a good idea; it seems
more can go wrong than right.
2014-05-18 19:21:39 +02:00
Luca Barbato
e0e79a2e7e vda: Hwaccel 1.2 support
Use the new context and the default functions provided.
2014-05-12 12:59:16 +02:00
Luca Barbato
dab56b5fd5 vda: Simplify codec selection
VDA supports h264 only.
2014-05-12 12:59:16 +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
203be26588 vdpau: handle display preemption during decoding
This was broken for some time, and it didn't recover correctly.

Redo decoder display preemption. Instead of trying to reinitialize the
hw decoder, simply fallback to software decoding. I consider display
preemption a bug in the vdpau API, so being able to _somehow_ recover
playback is good enough.

The approach taking here will probably also make it easier to handle
multithreading.
2014-05-10 10:44:16 +02:00
Martin Herkt
48bd03dd91 options: remove deprecated --identify
Also remove MSGL_SMODE and friends.

Note: The indent in options.rst was added to work around a bug in
ReportLab that causes the PDF manual build to fail.
2014-05-04 02:46:11 +02:00
wm4
eb9d203946 video: change everything
Change how the video decoding loop works. The structure should now be a
bit easier to follow. The interactions on format changes are (probably)
simpler. This also aligns the decoding loop with future planned changes,
such as moving various things to separate threads.
2014-05-02 01:09:58 +02:00
wm4
50ebcf1a43 video: handle colorspace and aspect overrides separately
Now the video filter code handles these explicitly, which should
increase robustness (or at least find bugs earlier).
2014-05-02 01:09:55 +02:00
wm4
ee574c67ea video: improve error messages 2014-04-30 22:20:08 +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
9dba2a52db player: add a --dump-stats option
This collects statistics and other things. The option dumps raw data
into a file. A script to visualize this data is included too.

Litter some of the player code with calls that generate these
statistics.

In general, this will be helpful to debug timing dependent issues, such
as A/V sync problems. Normally, one could argue that this is the task of
a real profiler, but then we'd have a hard time to include extra
information like audio/video PTS differences. We could also just
hardcode all statistics collection and processing in the player code,
but then we'd end up with something like mplayer's status line, which
was cluttered and required a centralized approach (i.e. getting the data
to the status line; so it was all in mplayer.c). Some players can
visualize such statistics on OSD, but that sounds even more complicated.
So the approach added with this commit sounds sensible.

The stats-conv.py script is rather primitive at the moment and its
output is semi-ugly. It uses matplotlib, so it could probably be
extended to do a lot, so it's not a dead-end.
2014-04-17 21:47:00 +02:00
wm4
9be93d6b60 vdpau: remove pointer indirection for a field
There's no reason to. This is basically a cosmetic change.
2014-03-19 19:57:08 +01:00
wm4
917650fefa vdpau: fix decoder init return value 2014-03-19 19:35:25 +01:00
wm4
49d13f76ca vaapi: make struct va_surface private
It's not really needed to be public. Other code can just use mp_image.
The only disadvantage is that the other code needs to call an accessor
to get the VASurfaceID.
2014-03-17 18:22:35 +01:00
wm4
31fc5e8563 vaapi: replace image pool implementation with mp_image_pool
Although I at first thought it would be better to have a separate
implementation for hwaccels because the difference to software images
are too large, it turns out you can actually save some code with it.

Note that the old implementation had a small memory management bug. This
got painted over in commit 269c1e1, but is hereby solved properly.

Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and
I hope I didn't accidentally break it.
2014-03-17 18:22:25 +01:00
wm4
6389507314 vdpau: remove legacy pixel formats
They were used by ancient libavcodec versions. This also removes the
need to distinguish vdpau image formats at all (since there is only
one), and some code can be simplified.
2014-03-17 18:21:11 +01:00
wm4
4e70335c2f vdpau: remove unused type 2014-03-17 18:20:44 +01: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
Andrey Morozov
d0e64dcc9b vdpau: change the error message when video too large 2014-02-24 17:59:52 +01:00
wm4
7448d1958d video: fix --no-aspect
This also affects the --aspect option and the "aspect" property.
2014-02-11 17:36:25 +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
56ce2a39be video: fix --brightness etc. options
They were set before the VO was intitialized, which silently failed.
2013-12-29 22:18:27 +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
4833e92b54 vda: attempt to fix build (2)
Still no OSX here.
2013-12-22 01:44:19 +01:00
wm4
eef36f03ea msg: rename mp_msg_log -> mp_msg
Same for companion functions.
2013-12-21 22:13:04 +01:00
wm4
5f0fbacf16 codecs: mp_msg conversion 2013-12-21 20:50:12 +01:00
wm4
70af7ab8e5 vaapi: mp_msg conversions
This ended up a little bit messy. In order to get a mp_log everywhere,
mostly make use of the fact that va_surface already references global
state anyway.
2013-12-21 20:50:11 +01:00
wm4
9e0b84c321 vdpau: mp_msg conversions 2013-12-21 20:50:11 +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
2c08bf1bd7 Reduce recursive config.h inclusions in headers
In my opinion, config.h inclusions should be kept to a minimum. MPlayer
code really liked including config.h everywhere, though, even in often
used header files. Try to reduce this.
2013-12-18 17:12:21 +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
88432b817d dec_video: fix handling of timestamp resets
This code tried to pass a still monotonic (even if not strictly
monotonic) PTS to the player, but as a result it remained stuck on
the PTS before a reset (since the PTS was lower).
2013-12-12 23:46:27 +01:00
wm4
227d087db6 video: display last frame, drain frames on video reconfig
Until now, the player didn't care to drain frames on video reconfig.
Instead, the VO was reconfigured (i.e. resized) before the queued frames
finished displaying. This can for example be observed by passing
multiple images with different size as mf:// filename. Then the window
would resize one frame before image with the new size is displayed. With
--vo=vdpau, the effect is worse, because this VO queues more than 1
frame internally.

Fix this by explicitly draining buffered frames before video reconfig.

Raise the display time of the last frame. Otherwise, the last frame
would be shown for a very short time only. This usually doesn't matter,
but helps when playing image files. This is a byproduct of frame
draining, because normally, video timing is based on the frames queued
to the VO, and we can't do that with frames of different size or format.
So we pretend that the frame before the change is the last frame in
order to time it. This code is incorrect though: it tries to use the
framerate, which often doesn't make sense. But it's good enough to test
this code with mf://.
2013-12-10 20:07:39 +01:00
wm4
2f46b23d51 video: move handling of brightness and deinterlacing control
Handling of brightness/gamma/saturation/etc. and deinterlacing is moved
from vf_vo.c to dec_video.c.
2013-12-10 20:07:39 +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
66e20ef8ad video: remove --flip
The --flip option flipped the image upside-down, by trying to use VO
support, or if not available, by inserting a video filter. I'm not sure
why it existed. Maybe it was important in ancient times when VfW based
decoders output an image this way (but even then, flipping an image is a
free operation by negating the stride).

One nice thing about this is that it provided a possible path for
implementing video orientation, which is a feature we should probably
support eventually. The important part is that it would be for free for
VOs that support it, and would work even with hardware decoding.

But for now get rid of it. It's useless, trivial, stands in the way, and
supporting video orientation would require solving other problems first.
2013-12-05 22:58:54 +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
Stefano Pigozzi
a74d9c1803 vo_opengl: support for vda hardware decoding
The harder work was done in the previous commits. After that this feature comes
out almost for free.

The only problem is I can't get the textures created with CGLTexImageIOSurface2D
to download properly, thus the code performs download using some CoreVideo APIs.

If someone knows why download of textures created with CGLTexImageIOSurface2D
doesn't work please contact me :)
2013-12-02 09:03:31 +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
2a316c3506 vdpau: always let decoder output IMGFMT_VDPAU
The old ffmpeg vdpau support code uses separate vdpau pixel formats for
each decoder (pretty much because mplayer's architecture sucked), which
just gets into the way. Force the old decoder's output to IMGFMT_VDPAU,
and remove IMGFMT_IS_VDPAU() where we can remove it.

This should completely remove the differences betwene the old and new
vdpau decoder outside of the decoder.
2013-11-29 14:19:44 +01:00
wm4
60cd300558 vaapi: remove unused hw image formats, simplify
PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not
sure why they were even added, and they sound like they are just for
compatibility with XvMC-style decoding, which sucks anyway.

Now that there's only a single vaapi format, remove the
IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was
unused.
2013-11-29 14:19:29 +01:00
wm4
0d255f07bf build: make pthreads mandatory
pthreads should be available anywhere. Even if not, for environment
without threads a pthread wrapper could be provided that can't actually
start threads, thus disabling features that require threads.

Make pthreads mandatory in order to simplify build dependencies and to
reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe
we will use pthreads more in the future, and then it'd become a real
bother.)
2013-11-28 19:28:38 +01:00
wm4
dc0b2046cd video: add insane hack to work around FFmpeg/Libav insanity
So, FFmpeg/Libav requires us to figure out video timestamps ourselves
(see last 10 commits or so), but the methods it provides for this aren't
even sufficient. In particular, everything that uses AVI-style DTS (avi,
vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal
frame delay is broken. In this case, libavcodec will shift the packet-
to-image correspondence by the codec delay, meaning that with a delay=1,
the first AVFrame.pkt_dts is not 0, but that of the second packet. All
timestamps will appear shifted. The start time (e.g. the time displayed
when doing "mpv file.avi --pause") will not be exactly 0.

(According to Libav developers, this is how it's supposed to work; just
that the first DTS values are normally negative with formats that use
DTS "properly". Who cares if it doesn't work at all with very common
video formats? There's no indication that they'll fix this soon,
either. An elegant workaround is missing too.)

Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV.
Since these timestamps are not reorderd, we wouldn't need to sort them,
but it's less code this way (and possibly more robust, should a demuxer
unexpectedly output PTS).

The original intention of all the timestamp changes recently was
actually to get rid of demuxer-specific hacks and the old timestamp
sorting code, but it looks like this didn't work out. Yet another case
where trying to replace native MPlayer functionality with FFmpeg/Libav
led to disadvantages and bugs. (Note that the old PTS sorting code
doesn't and can't handle frame dropping correctly, though.)

Bug reports:

 https://trac.ffmpeg.org/ticket/3178

 https://bugzilla.libav.org/show_bug.cgi?id=600
2013-11-28 15:20:33 +01:00
wm4
d9b5dedfe9 video: warn against non-monotonic PTS instead of decreasing PTS
And by non-monotonic, we mean "strictly non-monotonic".
2013-11-28 15:20:33 +01:00
wm4
3bed78fdfd video: add heuristic to prevent framedrop during hrseek if pts broken
Using --start with files that use DTS only, or which simply have broken
PTS timestamps, would incorrectly drop frames and possibly not execute
the seek correctly.

Add yet another heuristic to detect this. The intent is that --start and
hr-seeks in general should work correctly, but in order to keep things
fast, we still want to allow frame dropping during hr-seek if there are
no problems doing so. Do this by disabling frame dropping by default,
but re-enabling it if there are no problems found for a while. As a
consequence, --start might be somewhat slower, but normal user
interaction should remain as fast as before.

Note that there's something subtle about the added code: the
has_broken_packet_pts field is checked even before the first packet is
fed to dec_video.c, so the field must not be set to 0 right on start.
It's not initially set to 0 anyway, because the heuristic requires
decoding some images before enabling frame drop anyway.

Note 2: it's not clear whether frame dropping during hr-seek really
helps; I didn't benchmark it.
2013-11-28 15:20:33 +01:00
wm4
aa73ac8db8 video: replace d_video->pts field, change PTS jump checks
The d_video->pts field was a bit strange. The code overwrote it multiple
times (on decoding, on filtering, then once again...), and it wasn't
really clear what purpose this field had exactly. Replace it with the
mpctx->video_next_pts field, which is relatively unambiguous.

Move the decreasing PTS check to dec_video.c. This means it acts on
decoder output, not on filter output. (Just like in the previous commit,
assume the filter chain is sane.) Drop the jitter vs. reset semantics;
the dec_video.c determined PTS never goes backwards, and demuxer
timestamps don't "jitter".
2013-11-27 21:14:39 +01:00
wm4
5d97ac229a video: if PTS is missing, make something up using the framerate
Also get rid of the PTS check _after_ filters. This means if there's a
video filter which unsets PTS, no warning will be printed. But we assume
that all filters are well-behaved enough by now.
2013-11-27 21:14:39 +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
1e96f5bcd9 Move some code from player to audio/video reset functions 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
f2b5267e88 video: remove commented code 2013-11-27 21:14:39 +01:00
wm4
55070ea85f video: use dts as fallback when determining pts by sorting
This makes the new code equivalent with the old one, which often passed
dts as pts. Also rename some variables to clear up things.
2013-11-27 21:13:42 +01:00
wm4
7a0299478e video: unbreak --no-correct-pts with demuxers that use DTS 2013-11-26 23:43:56 +01:00
wm4
56d3ff33f1 video: move timestamp determination code to dec_video
This means the code that tries to figure out the timestamp from
demuxer and decoder output is now all in dec_video.c. We set the
final timestamp on the returned image (mp_image.pts), as well as
the d_video->pts field.

The way the player uses d_video->pts field is still a bit messy. Maybe
this could be cleaned up later.
2013-11-25 23:16:22 +01:00
wm4
b5b1692593 video: disable PTS sorting fallback by default
It appears PTS sorting was useful only for avi files (and VfW-muxed
mkv). Maybe it was historically also important for decoders with broken
or non-existent PTS reordering (win32 codecs?). But now that we handle
demuxers which outputs DTS only correctly, it just seems dead weight.

Disable it by default. The --pts-association-mode option is now forced
to always use the decoder's PTS value. You can still enable the old
default (auto) or force sorting. But we will probably remove this option
entirely at some point.

Make demux_mkv export timestamps at DTS when it's in VfW mode. This is
needed to get correct timestamps with the new default mode. demux_lavf
already does that.
2013-11-25 23:14:54 +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
d8b59aa17f player: merge no-correct-pts with correct-pts code
Now the --no-correct-pts mode is like the normal mode, just with
different timestamp calculations. The semantics should be about the
same as before this commit.
2013-11-25 23:12:18 +01:00
wm4
88fa420b20 player: change semantics of --no-correct-pts
Before this commit, this mode estimated the frame time by subtracting
successive packet PTS values. This is complete non-sense for video
codecs which use reordering. The code compensated frame times for these
non-sense using the FPS value, but confused the rest of the player with
non-sense jumping around timestamps. So, all in all this mode is not
very useful.

Repurpose this mode for fixed frame rate playback. This gives almost the
same behavior as the old mode with forced framerate (--fps option). The
result is simpler and often more robust.
2013-11-25 23:10:18 +01:00
wm4
83dc3a81f1 dec_video: fix function signature
Just why...? And why did this take 7 years?
2013-11-25 23:09:40 +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
36744a30fb Attempt to fix build on older libavcodec versions 2013-11-23 22:08:18 +01:00
wm4
f90e7ef7ea video: don't overwrite demuxer FPS value
If the --fps option was given (MPOpts->force_fps), the demuxer FPS value
was overwritten with the forced value. This was fine, since the demuxer
value wasn't needed anymore. But with the recent changes not to write to
the demuxer stream headers, we don't want to do this anymore. So
maintain the (forced/updated) FPS value in dec_video->fps.

The removed code in loadfile.c is probably redundant, and an artifact
from past refactorings.

Note that sub.c will now always use the demuxer FPS value, instead of
the user override value. I think this is fine, because it used the
demuxer's video size values too. (And it's rare that these values are
used at all.)
2013-11-23 21:41:40 +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
02f96efc50 dec_video: remove "initialized" field
It's redundant.
2013-11-23 21:38:39 +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
25855059af video: remove vf_pp auto-insertion
This drops the --pp option, which was probably broken for a while. The
option automatically inserted the "pp" filter. The value passed to it
was ignored (which is probably broken, it always selected maximal
quality).

Inserting this filter can be done simply with --vf=pp, so this is not
needed anymore.
2013-11-23 21:30:56 +01:00
wm4
acfeb869a3 video: merge vd.c into dec_video.c
I don't feel like the separation ever made sense, and it was hard to
tell which file a function you were looking for was in.
2013-11-23 21:28:28 +01:00
wm4
4fa2babacc video: move struct mp_hwdec_info into its own header file
This means most code accessing this struct must now include hwdec.h
instead of dec_video.h. I just put it into dec_video.h at first because
I thought a separate file would be a waste, but it's more proper to do
it this way, as there are too many files which include dec_video.h only
to get the mp_hwdec_info definition.
2013-11-23 21:26:31 +01:00
wm4
de22d2b1ba vf_vavpp: make it work with vo_opengl and software decoding
vo_opengl always loads the hwdec backend lazily, so hwdec_request_api()
has to be called to possibly load it. This makes vf_vavpp work with
software decoding. (Hardware decoding loads the backend before the
filter is initialized, so this case is different.)

Also, the VFCTRL_GET_HWDEC_INFO call doesn't need to be checked. If it
fails, the info will be left blank.
2013-11-22 18:06:34 +01:00
wm4
16233bc546 vdpau_old: enable OpenGL interop
OpenGL interop was essentially disabled, because the decoder didn't
request vdpau device creation from vo_opengl.
2013-11-19 22:15:28 +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
782c8e72ff vdpau: unbreak
Obviously I didn't test commit 1b8cd01, and it just crashed. Oops.
2013-11-09 01:27:03 +01:00
wm4
1b8cd01b1a vdpau: drop dummy render function
This was supposed to handle preemption better. I still think the current
state isn't very nice, since the decoder can "accidentally" call the
previous render function after preemption (instead of calling the
reloaded function), so there might be issues. But all in all, this
dummy_render function is a bit confusing, and still not entirely
correct, so it's not worth it.
2013-11-07 22:17:35 +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
db6a4eec0a vo_opengl: support for vdpau hardware decoding
This uses vdpau OpenGL interop to convert a vdpau surface to a texture.

Note that this is a bit weak and primitive. Deinterlacing (or any other
form of vdpau postprocessing) is not supported. vo_opengl chroma scaling
and chroma sample position are not supported. Internally, the vdpau
video surfaces are converted to a RGBA surface first, because using the
video surfaces directly is too complicated. (These surfaces are always
split into separate fields, and the vo_opengl core expects progressive
frames or frames with weaved fields.)
2013-11-05 22:28:15 +01:00
wm4
2826dcff8f vdpau: drop required/deprecated access to a libavcodec struct field
Before the bitstream_buffers field was deprecated, you had to free it,
otherwise you would leak memory.

(Although vdpau.c uses a new API, they managed to introduce a new
deprecation this quickly. This is a complaint.)

This introduces a memory leak of 12 bytes per file on every file on some
_older_ libavcodec versions. This is minor enough that I don't care.
2013-11-04 19:59:03 +01:00
wm4
f7b2d644ef Merge branch 'master' into have_configure
Conflicts:
	configure
2013-11-04 00:43:06 +01:00
wm4
2d58fb3b8e vo_opengl: add support for VA-API OpenGL interop
VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a
X11 pixmap into a FBO, and has to go over X11, probably involves one or
more copies), and this code serves more as an example, rather than for
serious use. On the other hand, this might be work much better than
vo_vaapi, even if slightly slower.
2013-11-04 00:11:43 +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
ee2ba635f2 dec_video: remove unused declaration of a former global variable 2013-10-31 18:17:13 +01:00
wm4
d7287d60dd vdpau_old: restore hardware decoding with old API
--hwdec=vdpau did nothing with older ffmpeg/libav versions. Oops.
2013-10-19 20:57:43 +02:00
wm4
ef9c5300ef cosmetics: replace "CTRL" defines by enums
Because why not.
2013-10-02 21:19:16 +02: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
5b3ae5aaac vaapi: remove non-VLD entrypoints
These probably don't work. libavcodec doesn't seem to support them,
and neither did the original mplayer-vaapi patch.
2013-09-29 13:52:09 +02:00
wm4
60e7926248 vaapi: fix non-sense condition
Attempting signed comparison on unsigned value.
2013-09-29 13:45:49 +02:00