summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* encode: fix PTS unit mismatchwm42014-05-101-6/+6
| | | | | | This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS values. This probably happened to work, because both constants use the same value.
* vdpau: make mp_vdpau_ctx thread-safewm42014-05-102-21/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vdpau: remove some codewm42014-05-101-7/+3
| | | | | There's no reason why we should treat the preemption case differently here.
* vo_vdpau, vo_opengl: handle vdpau preemption differentlywm42014-05-104-64/+29
| | | | | | | | | | | | | | | | | | | | Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
* vdpau: handle display preemption during decodingwm42014-05-103-38/+39
| | | | | | | | | | | | 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.
* w32_common: fix typowm42014-05-101-2/+3
| | | | Also, reset rc completely, instead of assuming things.
* player: remove VO from seeking code pathwm42014-05-072-6/+0
| | | | | | | | | | | | | | | Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
* video/out: remove unused config() parameterswm42014-05-079-29/+17
| | | | This was cleaned up yesterday.
* vo: remove old stuffwm42014-05-062-24/+0
|
* vo_wayland: always assume resize on reconfigurewm42014-05-061-2/+1
| | | | | | It doesn't look like vo_wayland_config() necessarily sets this flag, so it seems safer to trigger an explicit resize. This accounts for the case when playing a new file with different size than the one before.
* wayland: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-064-27/+28
| | | | Not very tested. Appears to work.
* win32: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-064-70/+46
| | | | Not very tested. At least it compiles.
* cocoa: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-063-22/+25
|
* vo_sdl: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-29/+33
|
* x11: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-067-36/+36
| | | | See previous commit.
* video/out: separate out code to compute window sizewm42014-05-063-85/+171
| | | | | | | | | | | | | | | | | | | Currently, vo_reconfig() calculates the requested window size and sets the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is implemented by the VO or the windowing backend. The window size can be different from the display size if e.g. the --geometry option is used. It will also set the vo->dx/dy fields and read vo->xinerama_x/y. It turned out that this is very backwards and actually requires the windowing backends to workaround these things. There's also MPOpts.screenwidth/screenheight, which used to map to actual options, but is now used only to communicate the screen size to the vo.c code calculating the window size and position. Change this by making the window geometry calculations available as separate functions. This commit doesn't change any VO code yet, and just emulates the old way using the new functions. VO code will remove its usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
* Fix bogus copyright textwm42014-05-061-2/+0
| | | | | This file was copied from gl_hwdec_vaglx.c to have a basic skeleton, but no actual code is left from it.
* vo: fix previous commitwm42014-05-061-1/+1
| | | | | | Commit 433161 actually broke vo_opengl (and maybe others), because config_ok is not necessarily set correctly yet _during_ reconfig. So a vo_get_src_dst_rects() call during reconfig did nothing.
* vo: don't crash when changing panscan before first configurationwm42014-05-061-0/+2
| | | | | | | | | | When the VO was not initialized with vo_reconfig(), or if the last vo_reconfig() failed, changing panscan would cause a crash due to vo_get_src_dst_rects() dereferencing vo->params (NULL if not configured). Just do nothing if that happens, as there is no video that could be displayed anyway.
* vo: get rid of config_count fieldwm42014-05-064-8/+4
| | | | | | | | Doesn't really seem to be much of use. Get rid of the remaining uses of it. Concerning vo_opengl_old, it seems uninitGl() works fine even if called before initialization.
* vf: print for which filter initialization failedwm42014-05-042-4/+11
|
* vf_vdpaupp: make code clarity improvementswm42014-05-041-8/+8
| | | | | This shouldn't change anything functionally, except that it buffers 1 frame less in the first-field deinterlacing mode.
* vdpau: deduplicate video surface upload codewm42014-05-044-54/+48
| | | | | | | This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c. (In theory, we could always require using vf_vdpaupp with vo_vdpau, but I think it's better if vo_vdpau can work standalone.)
* options: remove deprecated --identifyMartin Herkt2014-05-041-1/+0
| | | | | | | 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.
* options: remove obsolete --fsmode-dontuseMartin Herkt2014-05-041-8/+2
|
* options: rename video-related options/propertiesMartin Herkt2014-05-041-2/+2
| | | | | | | | | | | Renamed options: --aspect → --video-aspect --fstype → --x11-fstype --native-fs → --fs-missioncontrol --name → --x11-name Renamed properties: aspect → video-aspect
* vf_vapoursynth: fix aspect ratio passed to vapoursynthwm42014-05-031-2/+8
| | | | | | This was recently either changed or clarified in vapoursynth. Pass the aspect ratio as pixel aspect to VS.
* video: removed unused stuffwm42014-05-022-7/+0
|
* video: change everythingwm42014-05-024-40/+33
| | | | | | | 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.
* video: handle colorspace and aspect overrides separatelywm42014-05-023-9/+24
| | | | | Now the video filter code handles these explicitly, which should increase robustness (or at least find bugs earlier).
* vf: sanitize filter input, instead of overriding itwm42014-05-021-1/+2
| | | | | | | | | vf_fix_img_params() takes care of overwriting image parameters that are normally not set correctly by filters. But this makes no sense for input images. So instead, check that the input is correct. It still has to be done for the first input image, because that's used to handle some overrides (see video_reconfig_filters()).
* vf: add alternate functions for retrieving filter outputwm42014-05-022-13/+57
| | | | | | | These replace vf_read_output_frame(), although we still emulate that function. This change is preparation for another commit (and this is basically just to reduce the diff and signal/noise ratio in that commit).
* vf: expose input parameters; clear parameters on failurewm42014-05-022-2/+3
| | | | Preparation (and simplification) for following commits.
* vf: mark auto-inserted conversion filters in verbose outputwm42014-05-021-0/+2
| | | | | Nota that this flag is not set for other auto-inserted filters (like deinterlacing or rotation).
* vf_lavfi: reinit after libavfilter EOFwm42014-05-021-13/+25
| | | | | | Basically, if we feed the filter a new image even after the EOF state has been reached (e.g. because the input stream "recovered"), we want the filter to restart, instead of returning an error forever.
* vo: verify format of queued imagewm42014-05-021-0/+1
| | | | | Currently, only the configured format is accepted, so assert that the playback core code (which handles format changes) is correct.
* video: fix screenshots with anamorphic videowm42014-05-021-2/+2
| | | | | | | (Again.) This was caused by mp_image_set_params() not properly copying d_w/d_h, because mp_image_set_size() resets them.
* vf_vdpaupp: always provide past and future fieldswm42014-05-021-1/+1
| | | | | | | | | | | Some non-deinterlacing filters (potentially denoising) also use additional frames for filtering. The vdpau docs suggest providing at least 1 future and 2 past _fields_, which means we need to provide 1 past frame (the future field is already the other field of the current field, and both fields are in the same frame). We can easily achieve this by buffering an additional frame in the non- deint case.
* vo_vdpau: keep colorspace flagswm42014-05-021-1/+2
| | | | | Since vdpau_mixer.c initializes the YUV conversion using the mp_image flags, these images should have all flags set properly.
* video: move video frame queue from vo_vdpau.c to vo.cwm42014-05-023-145/+102
| | | | | | | | | | | | | | | | | | | | | Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
* vo_vdpau: always use mp_image for internal buffer queuewm42014-05-021-44/+39
|
* command, vo_vdpau: respect vdpau deint sub-optionwm42014-05-022-0/+5
| | | | | This is a horrible hack to keep compatibility with the vo_vdpau deint sub-option.
* vf_vdpaupp: allow toggling deinterlacewm42014-05-021-4/+19
| | | | | Basically makes the 'D' key work again. (But only if the filter is already inserted.)
* vo_vdpau: apply vo_vdpau postprocessing optionswm42014-05-021-2/+16
| | | | | | | | | | | | | The previous commits changed vo_vdpau so that these options are set by vf_vdpaupp, and the corresponding vo_vdpau were ignored. But for compatibility, keep the "old" options working. The value of this is questionable - maybe the vo_vdpau options should just be removed. For now, at least demonstrate that it's possible. The "deint" suboption still doesn't work, because the framerate doubling logic required for some deint modes was moved to vf_vdpaupp. This requires more elaborate workarounds.
* vdpau_mixer: allow overriding frame optswm42014-05-024-4/+10
| | | | So a caller can override the filter options dictated by vf_vdpaupp.
* vo_vdpau: support vf_vdpauppwm42014-05-021-248/+43
| | | | | | | | | | This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
* vo_opengl: make it work with vf_vdpauppwm42014-05-021-50/+8
| | | | | | | This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau deinterlacing just work. One additional minor advantage is that the video mixer creation code is factored out (although that is a double- edged sword).
* vf_vdpaupp: allow non-vdpau inputwm42014-05-021-5/+42
| | | | | | | So you can use vdpau deinterlacing without using vdpau hardware decoding. vf_vavpp does something similar.
* vdpau: add a postprocessing pseudo-filterwm42014-05-024-0/+550
| | | | | | | | | | | This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
* vo: document draw_imagewm42014-04-301-0/+6
|
* vo_lavc: remove code with no effectwm42014-04-301-1/+0
| | | | This field will also removed in the future.
* video: improve error messageswm42014-04-301-1/+1
|
* vf: print error if filtering a frame failswm42014-04-301-1/+4
| | | | | The filters don't always print an error on their own, and printing an error is better than silently dropping the frame.
* vf_lavfi: reset metadata in reset()Kevin Mitchell2014-04-291-0/+4
| | | | | | It might have been nice not to do this so that metadata could accumulate accross seeks, but it seems libavfilter looses its copy anyway on recreate_graph.
* vf-metadata: fix handling of NULL metadataKevin Mitchell2014-04-291-4/+7
| | | | | | lavfi would segfault due to a NULL dereference if it was asked for its metadata and none had been allocated (oops). This happens for libav which has no concept of filter metadata.
* video: remove redundant mp_image display_w/_h memberswm42014-04-293-18/+6
| | | | | | | | | | | | | | | | | Commit 5e4e248 added a mp_image_params field to mp_image, and moved many parameters to that struct. display_w/h was left redundant with mp_image_params.d_w/d_h. These fields were supposed to be always in sync, but it seems some code forgot to do this correctly, such as vf_fix_img_params() or mp_image_copy_attributes(). This led to the problem in github issue #756, because display_w/_h could become incorrect. It turns out that most code didn't use the old fields anyway. Just remove them. Note that mp_image_params.d_w/d_h are supposed to be always valid, so the additional checks for 0 shouldn't be needed. Remove these checks as well. Fixes #756.
* vo_vdpau: let vdpau scale anamorphic screenshotswm42014-04-291-8/+4
| | | | | | | In theory, returning the screenshot with original pixel aspect would allow avoiding scaling them with image formats that support non-square pixels, but in practice this isn't used anyway (nothing seems to understand e.g. jpeg aspect ratio tags).
* vf_vapoursynth: add more VS frame propertieswm42014-04-281-0/+26
| | | | | | | We only support them for input. The frame properties of output frames are ignored (except frame durations). Properties not set for now: _ChromaLocation, _Field, _FieldBased
* vf_vapoursynth: use frame durations instead of _AbsoluteTimewm42014-04-281-6/+25
| | | | | | | | | | | | | Set _DurationNum/_DurationDen on each VS frame, instead of _AbsoluteTime. The duration is the difference between the timestamp of the frame and the next frame, and when receiving filtered VS frames, we convert them back to an absolute PTS by summing them. We pass the timestamps with microsecond resolution. mpv uses double for timestamps internally, so we don't know the "real" timebase or FPS. VS on the other hand uses fractions for frame durations. We can't pass through the numbers exactly, but microseconds ought to be enough to be even safe from accumulating rounding errors.
* vf_vapoursynth: fix memory leak on errorwm42014-04-281-1/+3
| | | | | | Since this leaks video images, and the player keeps feeding new images to the fitler even if it fails, this would probably have disastrous consequences.
* vf_vapoursynth: remove incorrect copyright noticewm42014-04-281-2/+0
| | | | | This file merely started out by copy&pasting vf_lavfi.c and removing everything to have a basic skeleton.
* vf_lavfi: distinguish real errors from other stateswm42014-04-281-2/+11
| | | | Don't just hide real errors, should a filter return them.
* video: don't drop last frame when deinterlacing with yadifwm42014-04-287-6/+32
| | | | | | | | | | | | | | | | | | Or in other words, add support for properly draining remaining frames from video filters. vf_yadif is buffering at least one frame, and the buffered frame was not retrieved on EOF. For most filters, ignore this for now, and just adjust them to the changed semantics of filter_ext. But for vf_lavfi (used by vf_yadif), real support is implemented. libavfilter handles this simply by passing a NULL frame to av_buffersrc_add_frame(), so we just have to make mp_to_av() handle NULL arguments. In load_next_vo_frame(), we first try to output a frame buffered in the VO, then the filter, and then (if EOF is reached and there's still no new frame) the VO again, with draining enabled. I guess this was implemented slightly incorrectly before, because the filter chain still could have had remaining output frames.
* </