mpv/video/vdpau.h

112 lines
3.4 KiB
C
Raw Normal View History

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-27 23:49:45 +00:00
#ifndef MPV_VDPAU_H
#define MPV_VDPAU_H
#include <stdbool.h>
#include <inttypes.h>
vdpau: make mp_vdpau_ctx thread-safe Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
2014-05-09 19:49:42 +00:00
#include <pthread.h>
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-27 23:49:45 +00:00
#include <vdpau/vdpau.h>
#include <vdpau/vdpau_x11.h>
#include "common/msg.h"
#include "hwdec.h"
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-27 23:49:45 +00:00
#include "config.h"
#if !HAVE_GPL
#error GPL only
#endif
#define CHECK_VDP_ERROR_ST(ctx, message, statement) \
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-27 23:49:45 +00:00
do { \
if (vdp_st != VDP_STATUS_OK) { \
2013-12-21 17:05:23 +00:00
MP_ERR(ctx, "%s: %s\n", message, vdp->get_error_string(vdp_st)); \
statement \
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-27 23:49:45 +00:00
} \
} while (0)
#define CHECK_VDP_ERROR(ctx, message) \
CHECK_VDP_ERROR_ST(ctx, message, return -1;)
#define CHECK_VDP_ERROR_NORETURN(ctx, message) \
CHECK_VDP_ERROR_ST(ctx, message, ;)
2013-12-21 17:05:23 +00:00
#define CHECK_VDP_WARNING(ctx, message) \
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-27 23:49:45 +00:00
do { \
if (vdp_st != VDP_STATUS_OK) \
2013-12-21 17:05:23 +00:00
MP_WARN(ctx, "%s: %s\n", message, vdp->get_error_string(vdp_st)); \
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-27 23:49:45 +00:00
} while (0)
struct vdp_functions {
#define VDP_FUNCTION(vdp_type, _, mp_name) vdp_type *mp_name;
#include "video/vdpau_functions.inc"
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-27 23:49:45 +00:00
#undef VDP_FUNCTION
};
#define MAX_VIDEO_SURFACES 50
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-27 23:49:45 +00:00
// Shared state. Objects created from different VdpDevices are often (always?)
// incompatible to each other, so all code must use a shared VdpDevice.
struct mp_vdpau_ctx {
vdpau: make mp_vdpau_ctx thread-safe Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
2014-05-09 19:49:42 +00:00
struct mp_log *log;
Display *x11;
vdpau: make mp_vdpau_ctx thread-safe Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
2014-05-09 19:49:42 +00:00
struct mp_hwdec_ctx hwctx;
struct AVBufferRef *av_device_ref;
vdpau: make mp_vdpau_ctx thread-safe Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
2014-05-09 19:49:42 +00:00
// These are mostly immutable, except on preemption. We don't really care
// to synchronize the preemption case fully correctly, because it's an
// extremely obscure corner case, and basically a vdpau API design bug.
// What we do will sort-of work anyway (no memory errors are possible).
struct vdp_functions vdp;
VdpGetProcAddress *get_proc_address;
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-27 23:49:45 +00:00
VdpDevice vdp_device;
vdpau: make mp_vdpau_ctx thread-safe Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
2014-05-09 19:49:42 +00:00
pthread_mutex_t preempt_lock;
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-27 23:49:45 +00:00
bool is_preempted; // set to true during unavailability
uint64_t preemption_counter; // incremented after _restoring_
bool preemption_user_notified;
double last_preemption_retry_fail;
vdpau: force driver to report preemption early Another fix for the crazy and insane nvidia preemption behavior. This time, the situation is that we are using vo_opengl with vdpau interop, and that vdpau got preempted in the background while mpv was sitting idly. This can be e.g. reproduced by using: --force-window=immediate --idle --hwdec=vdpau and switching VTs. Then after switching back, load a video file. This will not let mp_vdpau_handle_preemption() perform preemption recovery, simply because it will do so only once vdp_decoder_create() has been called. There are some other API calls which trigger preemption, but many don't. Due to the way the libavcodec API works, vdp_decoder_create() is way too late. It does so when get_format returns. It notices creating the decoder fails, and continues calling get_format without the vdpau format. We could perhaps force it to reinit again (by adding a call to vdpau.c, that checks for preemption, and sets hwdec_request_reinit), but this seems too much of a mess. Solve it by calling API in mp_vdpau_handle_preemption() that empirically does trigger preemption: output_surface_put_bits_native(). This call is useless, and in fact should be doing nothing (empty update VdpRect). There's the slight chance that in theory it will slow down operation, but in practice it's bound to be harmless. It's the likely cheapest and simplest API call I've found that can trigger the fallback this way. (The driver is closed source, so it was up to trial & error.) Also, when initializing decoding, allow initial preemption recovery, which is needed to pass the test mention above.
2016-01-25 15:42:54 +00:00
VdpOutputSurface preemption_obj; // dummy for reliable preempt. check
// Surface pool
vdpau: make mp_vdpau_ctx thread-safe Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
2014-05-09 19:49:42 +00:00
pthread_mutex_t pool_lock;
int64_t age_counter;
struct surface_entry {
VdpVideoSurface surface;
VdpOutputSurface osurface;
bool allocated;
int w, h;
VdpRGBAFormat rgb_format;
VdpChromaType chroma;
bool rgb;
bool in_use;
int64_t age;
} video_surfaces[MAX_VIDEO_SURFACES];
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-27 23:49:45 +00:00
};
struct mp_vdpau_ctx *mp_vdpau_create_device_x11(struct mp_log *log, Display *x11,
bool probing);
void mp_vdpau_destroy(struct mp_vdpau_ctx *ctx);
struct mpv_global;
struct mp_hwdec_ctx *vdpau_create_standalone(struct mpv_global *global,
struct mp_log *plog, bool probing);
int mp_vdpau_handle_preemption(struct mp_vdpau_ctx *ctx, uint64_t *counter);
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-27 23:49:45 +00:00
struct mp_image *mp_vdpau_get_video_surface(struct mp_vdpau_ctx *ctx,
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-27 23:49:45 +00:00
VdpChromaType chroma, int w, int h);
bool mp_vdpau_get_format(int imgfmt, VdpChromaType *out_chroma_type,
VdpYCbCrFormat *out_pixel_format);
bool mp_vdpau_get_rgb_format(int imgfmt, VdpRGBAFormat *out_rgba_format);
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-27 23:49:45 +00:00
struct mp_image *mp_vdpau_upload_video_surface(struct mp_vdpau_ctx *ctx,
struct mp_image *mpi);
bool mp_vdpau_guess_if_emulated(struct mp_vdpau_ctx *ctx);
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-27 23:49:45 +00:00
#endif