Commit Graph

13 Commits

Author SHA1 Message Date
wm4 0112143fda Split mpvcore/ into common/, misc/, bstr/ 2013-12-17 02:39:45 +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 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 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 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 adfb71b79e vdpau: don't try to match codec profiles
Instead, do what MPlayer did all these years. It worked for them, so
there's probably no reason to change this.

Apparently fixes playback with some files, where the VDPAU decoder does
not formally support a profile, but decoding works with a more powerful
profile anyway.

Though note that MPlayer did this because it couldn't do it in a better
way (no decoder reported profiles available when creating the VDPAU
decoder), so it's not entirely clear whether this is a good idea. An
alterbative implementation might try to map the profiles exactly, and
do some fall backs if the exact profile is not available. But this
hack-solution works too.
2013-08-19 01:05:48 +02:00
wm4 04bc16f6ea vdpau: fix compilation on Libav
Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without
forward-declaring them and without including the headers declaring them.
FFmpeg's header for this is fine.
2013-08-15 23:40:02 +02:00
wm4 0da9638576 video/decode: pass parameters directly to hwdec allocate_image callback
Instead of passing AVFrame. This also moves the mysterious logic about
the size of the allocated image to common code, instead of duplicating
it everywhere.
2013-08-15 23:40:02 +02:00
wm4 8fe4790ec8 video: redo hw decoding initialization, add --hwdec=auto
Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.

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

What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
2013-08-11 23:59:18 +02:00
Stefano Pigozzi 406241005e core: move contents to mpvcore (2/2)
Followup commit. Fixes all the files references.
2013-08-06 22:52:31 +02:00
wm4 5accc5e7c1 vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").

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

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

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

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

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

Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
2013-07-28 19:25:07 +02:00