summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo: remove unused VOCTRL_GET_PANSCANwm42016-09-0812-25/+1
| | | | | | It was used to determine whether the VO supports VOCTRL_SET_PANSCAN. With all those changes to property semantics this became unnecessary, and its only use was dropped at some point.
* vo: don't access global options unsynchronizedwm42016-09-081-6/+10
| | | | | And since there's no proper fine-grained option change notification mechanism yet, intercept updates to "framedrop" manually.
* vo_opengl: use dedicated image unref function in config casewm42016-09-081-1/+1
| | | | | | | Just another corner-caseish potential issue. Unlike unreffing the image manually, unref_current_image() also takes care of properly unmapping hwdec frames. (The corner-case part of this is that it's probably never mapped at this point, but it's apparently not entirely guaranteed.)
* vo_opengl: simplify a conditionwm42016-09-081-2/+1
| | | | | | | | | | | The " || vimg->mpi" part virtually never seems to trigger, but on the other hand could possibly create unintended corner cases (for example by trying to upload a NULL image, which would then be marked as an error and render a blue screen). I guess it's a leftover from over times, where a NULL image meant "redraw the current frame". This is now handled by actually passing along the current frame.
* hwdec/opengl: Add support for CUDA and cuvid/NvDecodePhilip Langdale2016-09-087-1/+421
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nvidia's "NvDecode" API (up until recently called "cuvid" is a cross platform, but nvidia proprietary API that exposes their hardware video decoding capabilities. It is analogous to their DXVA or VDPAU support on Windows or Linux but without using platform specific API calls. As a rule, you'd rather use DXVA or VDPAU as these are more mature and well supported APIs, but on Linux, VDPAU is falling behind the hardware capabilities, and there's no sign that nvidia are making the investments to update it. Most concretely, this means that there is no VP8/9 or HEVC Main10 support in VDPAU. On the other hand, NvDecode does export vp8/9 and partial support for HEVC Main10 (more on that below). ffmpeg already has support in the form of the "cuvid" family of decoders. Due to the design of the API, it is best exposed as a full decoder rather than an hwaccel. As such, there are decoders like h264_cuvid, hevc_cuvid, etc. These decoders support two output paths today - in both cases, NV12 frames are returned, either in CUDA device memory or regular system memory. In the case of the system memory path, the decoders can be used as-is in mpv today with a command line like: mpv --vd=lavc:h264_cuvid foobar.mp4 Doing this will take advantage of hardware decoding, but the cost of the memcpy to system memory adds up, especially for high resolution video (4K etc). To avoid that, we need an hwdec that takes advantage of CUDA's OpenGL interop to copy from device memory into OpenGL textures. That is what this change implements. The process is relatively simple as only basic device context aquisition needs to be done by us - the CUDA buffer pool is managed by the decoder - thankfully. The hwdec looks a bit like the vdpau interop one - the hwdec maintains a single set of plane textures and each output frame is repeatedly mapped into these textures to pass on. The frames are always in NV12 format, at least until 10bit output supports emerges. The only slightly interesting part of the copying process is that CUDA works by associating PBOs, so we need to define these for each of the textures. TODO Items: * I need to add a download_image function for screenshots. This would do the same copy to system memory that the decoder's system memory output does. * There are items to investigate on the ffmpeg side. There appears to be a problem with timestamps for some content. Final note: I mentioned HEVC Main10. While there is no 10bit output support, NvDecode can return dithered 8bit NV12 so you can take advantage of the hardware acceleration. This particular mode requires compiling ffmpeg with a modified header (or possibly the CUDA 8 RC) and is not upstream in ffmpeg yet. Usage: You will need to specify vo=opengl and hwdec=cuda. Note that hwdec=auto will probably not work as it will try to use vdpau first. mpv --hwdec=cuda --vo=opengl foobar.mp4 If you want to use filters that require frames in system memory, just use the decoder directly without the hwdec, as documented above.
* vo_opengl: fix incorrect video rendering after vdpau preemption recoverywm42016-09-071-0/+1
| | | | | This could also trigger in certain other cases, whenever it falls back to dumb mode.
* vo_opengl: fix another potential vdpau preemption issuewm42016-09-071-1/+2
| | | | | | reinit() will change the image params fields, so give it a copy. Will fix potential crashes if preemption happens more than once.
* osdep: rename atomics.h to atomic.hwm42016-09-074-4/+3
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* vo_vdpau: rename some sub-optionswm42016-09-061-3/+6
| | | | | Since the sub-options have been deprecated very recently, and are redirected to global options, we don't need to document this change.
* vo_opengl: simplify option handlingwm42016-09-063-45/+37
| | | | | | | | | | | | | Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
* vo_opengl: fix --icc-profile initial behaviorwm42016-09-061-0/+1
| | | | | | | | | Setting --icc-profile had no effect, until a vo_opengl option was changed at runtime. We must initialize the renderer for the initial option state too. For some reason, the ICC profile gets loaded twice. The next commit happens to fix this.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-059-1/+10
|
* options: add automagic hack for handling sub-option deprecationswm42016-09-052-0/+7
| | | | | | | | | | | | | | | | | I decided that it's too much work to convert all the VO/AOs to the new option system manually at once. So here's a shitty hack instead, which achieves almost the same thing. (The only user-visible difference is that e.g. --vo=name:help will list the sub-options normally, instead of showing them as deprecation placeholders. Also, the sub-option parser will verify each option normally, instead of deferring to the global option parser.) Another advantage is that once we drop the deprecated options, converting the remaining things will be easier, because we obviously don't need to add the compatibility hacks. Using this mechanism is separate in the next commit to keep the diff noise down.
* vo_direct3d: deprecate direct3d_shaders aliaswm42016-09-052-24/+2
| | | | | And remove the difference between the aliases. This is needed to make the sub-option changes less painful.
* vo_image: move to global optionswm42016-09-053-25/+52
| | | | | This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
* options: add a mechanism to make sub-option replacement slightly easierwm42016-09-053-1/+7
| | | | | | | | Instead of requiring each VO or AO to manually add members to MPOpts and the global option table, make it possible to register them automatically via vo_driver/ao_driver.global_opts members. This avoids modifying options.c/options.h every time, including having to duplicate the exact ifdeffery used to enable a driver.
* w32_common: initialize playback status as soon as possiblewm42016-09-021-16/+25
| | | | | | | | On a VOCTRL_UPDATE_PLAYBACK_STATE store the state, and use it to initialize the next time the task list becomes available. This actually fixes #3482. Revert commit f2e25e9e because it's not needed anymore.
* command: remove vo-cmdlinewm42016-09-021-1/+0
| | | | | | With the recent vo_opengl changes it doesn't do anything anymore. I don't think a deprecation period is necessary, because the command was always marked as experimental.
* vo_opengl: deprecate sub-options, add them as global optionswm42016-09-026-242/+207
| | | | | | | | | | | | | | | | | | | | | | | | vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
* vo_opengl: rename 3dlut-size to icc-3dlut-sizewm42016-09-021-1/+2
| | | | | Not documenting this yet, because a later commit will change all the options anyway.
* vo: use new option update mechanismwm42016-09-023-3/+23
| | | | | | | | | | | | | | | | This is still rather basic. run_reconfig() and run_control() update the options because it's needed for panscan (and other video scaling options), and fullscreen, border, ontop updates. In the old model, these options could be accessed only while both playback thread and VO threads were locked (i.e. during synchronous calls like vo_control()), so this should be sufficient in order not to miss any updates. In the future, a more fine-grained update mechanism could be added to handle these updates "exactly". x11_common.c contains an evil hack, as I see no reasonable way to handle this properly. The VO thread can't "lock" the main thread, so this is not simple.
* vo_opengl: minor renderer option access refactorwm42016-09-023-5/+17
| | | | | | | | | | | | | Reduce accesses to the renderer opts in vo_opengl.c, and instead add accessors for them to video.c. I suppose gamma and maybe icc-auto could be moved to vo_opengl.c options. Also, the output colorspace could probably be adjusted to what is really used, not just the options (although it's possible that this commit changes this, due to video.c mutating its own copy of the options according to actual renderer capapbilities). But don't deal with this now.
* m_config: add helper function for initializing af/ao/vf/vo suboptionswm42016-09-022-8/+7
| | | | | | | | Normally I'd prefer a bunch of smaller functions with fewer parameters over a single function with a lot of parameters. But future changes will require messing with the parameters in a slightly more complex way, so a combined function will be needed anyway. The now-unused "global" parameter is required for later as well.
* vo_opengl: remove pre/post/scale-shadersNiklas Haas2016-09-022-70/+3
| | | | | | | | | | Deprecated in favor of user-shaders, which are functionally equivalent but superior. (Except in the case of scaler-shader, which has no direct replacement, but it turned out to be a very unpopular feature either way - most custom scalers don't fit into the mpv kernel infrastructure and are therefore implemented as user shaders either way) Signed-off-by: wm4 <wm4@nowhere>
* vo, ao: disable positional parameter suboptionswm42016-09-011-0/+1
| | | | | | | | | | | | | | | | Positional parameters cause problems because they can be ambiguous with flag options. If a flag option is removed or turned into a non-flag option, it'll usually be interpreted as value for the first sub-option (as positional parameter), resulting in very confusing error messages. This changes it into a simple "option not found" error. I don't expect that anyone really used positional parameters with --vo or --ao. Although the docs for --ao=pulse seem to encourage positional parameters for the host/sink options, which means it could possibly annoy some PulseAudio users. --vf and --af are still mostly used with positional parameters, so this must be a configurable option in the option parser.
* vo: update w32_common left out by 4d75514quilloss2016-08-311-3/+0
|
* vo_xv: remove an aliased optionwm42016-08-311-4/+7
| | | | | Trying to get rid of them, and no-colorkey is an instance of it. Kill it.
* vo: change messy handling of fullscreen and other flagswm42016-08-305-10/+2
| | | | | | | | | | | | | | Before this commit, all VOs had to toggle the option flag themselves, now command.c does it. I can't really comprehend why it required every VO to do this manually. Maybe it was for rejecting the property/option change if the VO didn't support a specific capability. But then it could have checked the VOCTRL result. In any case, I don't care, and successfully changing the property without doing anything (With some VOs) is fine too. Many things work this way now, and it's simpler overall. This change will be useful for cleaning up VO option handling.
* options: make mp_vo_opts options an actual sub-option groupwm42016-08-303-4/+4
| | | | | | | | | | | Just a minor refactor along the planned option change. This commit will make it easier to update (i.e. copy) the VO options without copying _all_ options. For now, behavior should be equivalent, though. (The VO options were put into a separate struct quite early - when all global variables were removed from the source code. It wasn't clear whether the separate struct would have any actual purpose, but it seems it will now. Awesome, huh.)
* wayland: reject resize events with either dimension being 0Rostislav Pehlivanov2016-08-291-0/+2
| | | | Newer versions of mutter/gnome now ask mpv to resize to 0 by 0 pixels.
* vo_opengl: explicitly check for GL errors around framebuffer depth checkwm42016-08-291-0/+4
| | | | | | | | It seems like many GL implementations (including Mesa) choke on this, while others are fine. We still think that this use of the GL API is allowed by the standard (at least in the Mesa case), so to reduce confusion, explicitly check the "controversial" calls, and use an appropriate error message.
* vd_lavc: always force milliseconds for MMALwm42016-08-291-0/+5
| | | | | This libavcodec wrapper should rescale the API timestamps to whatever it internally needs, but it doesn't yet. So restore this code.
* vd_lavc, ad_lavc: set pkt_timebase, not time_basewm42016-08-291-1/+4
| | | | | | | | | These are different AVCodecContext fields. pkt_timebase is the correct one for identifying the unit of packet/frame timestamps when decoding, while time_base is for encoding. Some decoders also overwrite the time_base field with some unrelated codec metadata. pkt_timebase does not exist in Libav, so an #if is required.
* x11, wayland: always round up wait timeswm42016-08-262-2/+2
| | | | | If wait_us is >0 and <500, the wait time gets rounded down 0, effectively turning this into busy waiting. Round it up instead.
* vo: remove redundant wakeupwm42016-08-261-1/+3
| | | | | Shouldn't matter. Was pointed out by someone. The change should help avoiding extra unneeded wakeups on the VO thread.
* w32_common: use hooks to detect parent window resizeJames Ross-Gowan2016-08-261-35/+117
| | | | | | | | | | | | | | | | | | | | | | | Because VOCTRL_CHECK_EVENTS is processed asynchronously (as of 088a007,) the GUI thread no longer gets regular wakeups, so the old check that made sure the video window matched the parent window's size in --wid embedding mode did not run very often. This made --wid embedding not very usable. Instead of polling for window size changes, use Windows hooks to react to them when they happen. When the parent window is owned by the same process as the video window, use a WH_CALLWNDPROC hook. When the parent window is not owned by the same process, WinEvents must be used, which are not as smooth, but still work for this purpose. Since neither SetWindowsHookEx nor SetWinEventHook take a context parameter to send data to the hook function, the hook functions must find the child window by its class instead, so there are a few changes to ensure this is fast and the class is unique. This also fixes up the logic to handle window destruction. When a parent window is destroyed, its children are also destroyed, so this gives us a way to react to parent window destruction without polling.
* vo_opengl: angle: new opengl flag to control DirectCompositionAvi Halachmi (:avih)2016-08-253-2/+13
| | | | | On some systems DirectComposition might behave poorly. Add an opengl suboption flag 'dcomposition' (default=yes) which can disable it.
* x11: work around mutter fullscreen issuewm42016-08-251-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | If the video has the same size as the screen, starting with --fs and then leaving fullscreen doesn't actually leave fullscreen. The reason is that mpv tries to restore the previous window size if necessary (otherwise, you'd end up with a Window of nearly the same size as the screen with some WMs). It will typically restore with the rectangle set exactly to the screen if no other position or size is forced. This triggers pre-EWMH fullscreen mode, which WMs detect using various heuristics. Apparently we triggered this with mutter (but strangely no other WMs). It's possible that pre-EWMH fullscreen mode actually requires removing decorations, and mutter either ignores this. But this is speculation and I haven't checked. Work this around by reducing the requested size by 1 pixel if it happens. This was observed with mutter 3.18.2. Fixes #2072.
* vd_lavc: minor simplificationwm42016-08-231-3/+1
| | | | The timebase is now always valid.
* vo: be more trusting to estimated display FPSwm42016-08-201-8/+5
| | | | | | | | | | | | | | | This should actually be rather safe - we already check whether the estimated value jitters less than the (possibly untrustworthy) nominal one. Remove a "safety" check that disabled this code for small deviations, and make it trigger sooner into playback. Also lower the log level of messages about using the estimated display FPS down to verbose. Normally there's another mechanism for smoothing out minor estimation differences, but that is not good enough here. This possibly improves behavior as reported in #3433, which can be reproduced with --vo=null:fps=48.426 --display-fps=48 (though it doesn't consider the jitter introduced by a real VO).
* player: update Windows playback state asynchronouslywm42016-08-202-6/+31
| | | | | | | | | | | | | | | | | | Doing this required synchronizing with the VO thread, which could lead to audio dropouts if the VO was frozen (which can happen in practice if e.g. an opengl_cb user is not doing what the API demands). Add a way to send asynchronous VOCTRLs, and use that for the playback state. In theory, it would be better to make this status update a several function and to "merge" several queued update, but that would be slightly more effort/code, and the update is so infrequent that the merging would never happen anyway. The change to vo_destroy() is to make sure all queued asynchronous reuqests are finished before making the vo_thread exit. Even though it's only used on MS Windows, it's run on any platform with any VO, which makes this worse.
* vo: fix mismatching types in pointer operationwm42016-08-202-3/+3
| | | | | | | run_control() dereferences an uint32_t as int. Whether this is allowed depends on what uint32_t is typedefed to (dereferencing an unsigned int as int should be fine). Fix it by always using int. The uint32_t type never really made sense.
* aspect: add --video-unscaled=downscale-bigrr-2016-08-191-3/+7
|
* vd_lavc: remove unnecessary initializationwm42016-08-191-1/+0
| | | | This is already the default value.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-191-4/+1
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* vf_rotate: allow arbitrary rotationwm42016-08-191-2/+9
| | | | | | | vf_rotate selects the correct filter for 90° rotation, but it can be extended to use lavfi's vf_rotate as fallback. See #3434.
* video: don't discard video frames after endptswm42016-08-182-0/+8
| | | | | | | | | | | | Instead of letting it keep decoding by trying to find a new frame, "plug" the frame queue by not removing it. (Or actually, by putting it back instead of discarding it.) Matters for seamless looping (following commits), and possibly some other corner cases. The added function vf_unread_output_frame() is a bit of a sin, but still reasonable, since its implementation is trivial.
* vo_direct3d: add missing headerPaul B Mahol2016-08-141-0/+1
| | | | | | Fixes build under cygwin. Signed-off-by: wm4 <wm4@nowhere>
* w32_common: update window size on resize eventswm42016-08-071-0/+6
| | | | | | Fixes a regression introduced by commit 088a0075. Fixes #3400.
* player: fix display-sync timing if audio take long on resumewm42016-08-072-0/+9
| | | | | | | | | | | | | | | | | In display-sync mode, the very first video frame is idiotically fully timed, even though audio has not been synced yet at this point, and the video frame is more like a "preview" frame. But since it's fully timed, an underflow is detected if audio takes longer than the display time of the frame (we send the second frame only after audio is done). The timing code will try to compensate for the determined desync, but it really shouldn't. So explicitly discard the timing info in this specific case. On the other hand, if the first frame still hasn't finished display, we can pretend everything is ok. This is a hack - ideally, we either would send a frame without timing info (and then send it again or so when playback starts properly), or we would add real pause support to the VO, and pause it during syncing.
* w32_common: don't wait for GUI thread when polling for eventswm42016-08-051-8/+12
| | | | | | | | | |