summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vd_lavc: when falling back to software, revert filter error statuswm42013-11-231-0/+2
| | | | | | | | | | | | | | | | | | | When mpv is started with some video filters set (--vf is used), and hardware decoding is requested, and hardware decoding would be possible, but is prevented due to video filters that accept software formats only, the fallback didn't work properly sometimes. This fallback works rather violently: it tries to initialize the filter chain, and if it fails it throws away the frame decoded using the hardware, and retries with software. The case that didn't work was when decoding the current packet didn't immediately lead to a new frame. Then the filter chain wouldn't be reinitialized, and the playloop would stop playback as soon as it encounters the error flag. Fix this by resetting the filter error flag (back to "uninitialized"), which is a rather violent, but somewhat working solution. The fallback in general should perhaps be cleaned up later.
* Attempt to fix build on older libavcodec versionswm42013-11-232-0/+2
|
* video: don't overwrite demuxer FPS valuewm42013-11-231-1/+1
| | | | | | | | | | | | | | | | If the --fps option was given (MPOpts->force_fps), the demuxer FPS value was overwritten with the forced value. This was fine, since the demuxer value wasn't needed anymore. But with the recent changes not to write to the demuxer stream headers, we don't want to do this anymore. So maintain the (forced/updated) FPS value in dec_video->fps. The removed code in loadfile.c is probably redundant, and an artifact from past refactorings. Note that sub.c will now always use the demuxer FPS value, instead of the user override value. I think this is fine, because it used the demuxer's video size values too. (And it's rare that these values are used at all.)
* video: move handling of container vs. stream AR out of vd_lavc.cwm42013-11-234-39/+34
| | | | | | | Now the actual decoder doesn't need to care about this anymore, and it's handled in generic code instead. This simplifies vd_lavc.c, and in particular we don't need to detect format changes in the old way anymore.
* dec_video: make vf_input and hwdec_info statically allocatedwm42013-11-233-7/+5
| | | | | | | | | | | The only reason why these structs were dynamically allocated was to avoid recursive includes in stheader.h, which is (or was) a very central file included by almost all other files. (If a struct is referenced via a pointer type only, it can be forward referenced, and the definition of the struct is not needed.) Now that they're out of stheader.h, this difference doesn't matter anymore, and the code can be simplified. Also sneak in some sanity checks.
* dec_video: remove "initialized" fieldwm42013-11-232-13/+8
| | | | It's redundant.
* demux: remove gsh field from sh_audio/sh_video/sh_subwm42013-11-231-3/+3
| | | | | | | | | This used to be needed to access the generic stream header from the specific headers, which in turn was needed because the decoders had access only to the specific headers. This is not the case anymore, so this can finally be removed again. Also move the "format" field from the specific headers to sh_stream.
* video: move decoder context from sh_video into new structwm42013-11-236-187/+216
| | | | | | | | | | This is similar to the sh_audio commit. This is mostly cosmetic in nature, except that it also adds automatical freeing of the decoder driver's state struct (which was in sh_video->context, now in dec_video->priv). Also remove all the stheader.h fields that are not needed anymore.
* options: print lavfi filter list with --vf=lavfi=helpwm42013-11-231-0/+40
|
* options: implement --pphelp differentlywm42013-11-233-0/+8
| | | | Make it work via --vf=pp:help instead.
* video: remove vf_pp auto-insertionwm42013-11-234-34/+0
| | | | | | | | | | This drops the --pp option, which was probably broken for a while. The option automatically inserted the "pp" filter. The value passed to it was ignored (which is probably broken, it always selected maximal quality). Inserting this filter can be done simply with --vf=pp, so this is not needed anymore.
* video: merge vd.c into dec_video.cwm42013-11-232-175/+138
| | | | | I don't feel like the separation ever made sense, and it was hard to tell which file a function you were looking for was in.
* video: move struct mp_hwdec_info into its own header filewm42013-11-2312-23/+30
| | | | | | | | This means most code accessing this struct must now include hwdec.h instead of dec_video.h. I just put it into dec_video.h at first because I thought a separate file would be a waste, but it's more proper to do it this way, as there are too many files which include dec_video.h only to get the mp_hwdec_info definition.
* vo_opengl: fix compilationwm42013-11-221-2/+2
| | | | Never do a trivial change while drunk and without actually testing it.
* vf_vavpp: make it work with vo_opengl and software decodingwm42013-11-223-5/+5
| | | | | | | | | | vo_opengl always loads the hwdec backend lazily, so hwdec_request_api() has to be called to possibly load it. This makes vf_vavpp work with software decoding. (Hardware decoding loads the backend before the filter is initialized, so this case is different.) Also, the VFCTRL_GET_HWDEC_INFO call doesn't need to be checked. If it fails, the info will be left blank.
* vo_opengl: initialize all fields for VFCTRL_GET_HWDEC_INFOwm42013-11-221-4/+8
| | | | | | This initialized only the load_api and load_api_ctx fields, and left the other fields as they were. This failed with vf_vavpp, which assumed all fields are initialized.
* cocoa: use window-scale to support video scaling functionalityStefano Pigozzi2013-11-223-6/+10
| | | | | In the cocoa backend you can use cmd+0/1/2 to scale the window. This commit makes it use the new window-scale functionality.
* cocoa: implement window-scaleStefano Pigozzi2013-11-221-0/+20
|
* switch the build system to wafStefano Pigozzi2013-11-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a new build system based on waf. configure and Makefile are deprecated effective immediately and someday in the future they will be removed (they are still available by running ./old-configure). You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`. TL;DR: we couldn't get the same level of abstraction and customization with other build systems we tried (CMake and autotools). For guidance on how to build the software now, take a look at README.md and the cross compilation guide. CREDITS: This is a squash of ~250 commits. Some of them are not by me, so here is the deserved attribution: - @wm4 contributed some Windows fixes, renamed configure to old-configure and contributed to the bootstrap script. Also, GNU/Linux testing. - @lachs0r contributed some Windows fixes and the bootstrap script. - @Nikoli contributed a lot of testing and discovered many bugs. - @CrimsonVoid contributed changes to the bootstrap script.
* vdpau_old: enable OpenGL interopwm42013-11-191-0/+1
| | | | | OpenGL interop was essentially disabled, because the decoder didn't request vdpau device creation from vo_opengl.
* demux: rename demux_packet.h to packet.hwm42013-11-182-2/+2
| | | | This always bothered me.
* vo_vdpau: don't calculate destination alpha when drawing OSDwm42013-11-181-2/+2
| | | | | | Same as MPlayer svn commit r36515 "Chose cheaper alpha blend equation." No idea if this is actually faster, but can't hurt.
* gl_common: print SW renderer warning only if it was the only reason we ↵wm42013-11-141-1/+1
| | | | rejected it
* vd_lavc: select correct hw decoder profile for constrained baseline h264wm42013-11-141-2/+4
| | | | | | | | | | | | | | | | | | | | The existing code tried to remove the "extra" profile flags for h264. FF_PROFILE_H264_INTRA doesn't matter for us at all, because it's set only for profiles the vdpau/vaapi APIs don't support. The FF_PROFILE_H264_CONSTRAINED flag on the other hand is added to H264_BASELINE, except that it makes the file a real subset of H264_MAIN and H264_HIGH. Removing that flag would select the BASELINE profile, which appears to be rarely supported by hardware decoders. This means we accidentally rejected perfectly hardware decodable files. Use MAIN for it instead. (vaapi has explicit support for CONSTRAINED_BASELINE, but it seems to be a new thing, and is not reported as supported where I tried. So don't bother to check it, and do the same as on vdpau.) See github issue #204.
* gl_common: remove unneeded callbackwm42013-11-144-4/+0
| | | | We got rid of this some time ago, but apparently not completely.
* wayland: create xkbcommon keymap from stringAlexander Preisinger2013-11-131-2/+1
| | | | Fixes a problem where the passed size doesn't match the actuall string.
* waylad: implement functionality for window-scalingAlexander Preisinger2013-11-121-0/+12
|
* vo_lavc: fix -ovoffset.Rudolf Polzer2013-11-111-1/+3
| | | | Previously, using it led to no single frame being output, ever.
* vo_opengl: fix alpha values written to the framebufferwm42013-11-103-5/+16
| | | | | | | | | | | | | | | | | | | | | | | When blending OSD and subtitles onto the video, we write bogus alpha values. This doesn't normally matter, because these values are normally unused and discarded. But at least on Wayland, the alpha values are used by the compositor and leads to transparent windows even with opaque video on places where the OSD happens to use transparency. (Also see github issue #338.) Until now, the alpha basically contained garbage. The source factor GL_SRC_ALPHA meant that alpha was multiplied with itself. Use GL_ONE instead (which is why we have to use glBlendFuncSeparate()). This should give correct results, even with video that has alpha. (Or at least it's something close to correct, I haven't thought too hard how the compositor will blend it, and in fact I couldn't manage to test it.) If glBlendFuncSeparate() is not available, fall back to glBlendFunc(), which does the same as the code did before this commit. Technically, we support GL 1.1, but glBlendFuncSeparate is 1.4, and I guess we should try not to crash if vo_opengl_old runs on a system with GL 1.1 drivers only.
* gl_hwdec_vdpau: silence warning caused by buggy GL_NV_vdpau_interop specwm42013-11-091-2/+6
| | | | | VDPAU handles are integers, but for some reasons the VDPAU GL extension expects them as void*.
* vdpau: unbreakwm42013-11-091-0/+1
| | | | Obviously I didn't test commit 1b8cd01, and it just crashed. Oops.
* vdpau: drop dummy render functionwm42013-11-071-14/+2
| | | | | | | | | This was supposed to handle preemption better. I still think the current state isn't very nice, since the decoder can "accidentally" call the previous render function after preemption (instead of calling the reloaded function), so there might be issues. But all in all, this dummy_render function is a bit confusing, and still not entirely correct, so it's not worth it.
* memcpy_pic: reformatwm42013-11-061-27/+17
| | | | | Besides cosmetic changes, also change memcpy_pic return type and remove config.h include.
* vd_lavc: remove explicit crystalhd supportwm42013-11-061-14/+0
| | | | | | | | | | | | | | | | This removes "--hwdec=crystalhd". I doubt anyone even tried to use this. But even if someone wants to use it, the decoders can still be explicitly invoked with e.g.: --vd=lavc:h264_crystalhd The only advantage our special code provided was fallback to software decoding. (But I'm not sure how the ffmpeg crystalhd pseudo-decoder actually behaves.) Removing this will allow some simplifications as soon as we don't need vdpau_old.c anymore.
* gl_header_fixes: fix inverted conditionwm42013-11-051-1/+1
| | | | | Could possibly leading to failing compilation on systems with headers that miss the vdpau extension.
* vo_opengl: support for vdpau hardware decodingwm42013-11-055-0/+294
| | | | | | | | | | | | This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
* vdpau: move device and video surface management from vo_vdpau.c to vdpau.cwm42013-11-053-220/+271
| | | | | The goal is being able to use vdpau decoding independently from vo_vdpau.c.
* vo_opengl: redo aspects of initialization, change hwdec APIwm42013-11-053-38/+38
| | | | | | | | | | | Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
* vo_opengl/vaapi: use IMGFMT_RGB0wm42013-11-051-1/+1
| | | | | More correct, might make things slightly faster (probably insignificant).
* video: make IMGFMT_RGB0 etc. exist even if libavutil doesn't support itwm42013-11-053-27/+36
| | | | | | | | These formats are helpful for distinguishing surfaces with and without alpha. Unfortunately, Libav and older version of FFmpeg don't support them, so code will break. Fix this by treating these formats specially on the mpv side, mapping them to RGBA on Libav, and unseting the alpha bit in the mp_imgfmt_desc struct.
* vo_xv: fix compilation of SHM not availablewm42013-11-051-1/+1
|
* Adjust wayland definesPaweł Forysiuk2013-11-041-1/+1
|
* vdpau: drop required/deprecated access to a libavcodec struct fieldwm42013-11-041-3/+0
| | | | | | | | | | | Before the bitstream_buffers field was deprecated, you had to free it, otherwise you would leak memory. (Although vdpau.c uses a new API, they managed to introduce a new deprecation this quickly. This is a complaint.) This introduces a memory leak of 12 bytes per file on every file on some _older_ libavcodec versions. This is minor enough that I don't care.
* vo_opengl: cosmetics/fix typoswm42013-11-042-2/+2
|
* vo_opengl: reserve 4 texture units for video instead of 3wm42013-11-041-5/+5
| | | | | | | | | | Video has up to 4 textures, if you include obscure formats with alpha. This means alpha formats could always overwrite the first scaler texture, leading to corrupted video display. This problem was recently brought to light, when commit 571e697 started to explicitly unbind all 4 video textures, which broke rendering for non-alpha formats as well. Fix this by reserving the correct number of texture units.
* Merge remote-tracking branch 'origin/have_configure'Stefano Pigozzi2013-11-0417-73/+72
|\
| * fix weird DPMS->EXT replacementwm42013-11-041-3/+3
| |
| * Merge branch 'master' into have_configurewm42013-11-0412-32/+396
| |\ | | | | | | | | | | | | Conflicts: configure
| * | configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-0317-72/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* | | vo_opengl: fix use of uninitialized memorywm42013-11-041-1/+1
| |/ |/| | | | | | | Pretty bad, although it should actually not cause any misbehavior. Comes from the hardware decoding interop commit.
* | vo_opengl: add support for VA-API OpenGL interopwm42013-11-044-0/+147
| | | | | | | | | | | | | | | | VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower.
* | vo_opengl: add infrastructure for hardware decoding OpenGL interopwm42013-11-048-32/+224
| | | | | | | | | | | | | | | | | | | | | | | | Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
* | mp_image: add helper for copying image attributeswm42013-11-032-0/+25
|/ | | | | This enw function is similar to mp_image_set_params(), but doesn't force setting "hard" parameters like image size and format.
* w32: implement functionality required for window-scalewm42013-11-021-0/+23
| | | | Same semantics with respect to fullscreen as x11.
* x11: make window-scale use windowed size in fullscreen modewm42013-11-021-2/+2
| | | | | | This is a bit more intuitive, since before, the window size was just set to something random when setting the window-scale property during fullscreen.
* demux: rename Windows symbolswm42013-11-021-10/+10
| | | | | | | | | | | | | | | | | | | | There are some Microsoft Windows symbols which are traditionally used by the mplayer core, because it used to be convenient (avi was the big format, using binary windows decoders made sense...). So these symbols have the exact same definition as the Windows one, and if mplayer is compiled on Windows, the symbols from windows.h are used. This broke recently just because some files were shuffled around, and the symbols defined in ms_hdr.h collided with windows.h ones. Since we don't have windows binary decoders anymore, there's not the slightest reason our symbols should have the same names. Rename them to reduce the risk for collision, and to fix the recent regression. Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines its own version if the windows headers don't define it, and ao_wasapi is not available on systems where this symbol is missing. Also reindent ms_hdr.h.
* Fix some more -Wshadow warningswm42013-11-015-19/+19
| | | | | | These aren't printed with newer gcc or clang versions for some reason. All of them seem to be about local variables shadowing global functions.
* video: check profiles with hardware decodingwm42013-11-015-72/+131
| | | | | | | | | | | | | | | We had some code for checking profiles earlier, which was removed in commits 2508f38 and adfb71b. These commits mentioned that (working) hw decoding was sometimes prevented due to profile checking, but I can't find the samples anymore that showed this behavior. Also, I changed my opinion, and I think checking the profiles is something that should be done for better fallback to software decoding behavior. The checks roughly follow VLC's vdpau profile checks, although we do not check codec levels. (VLC's profile checks aren't necessarily completely correct, but they're a welcome help anyway.) Add a --vd-lavc-check-hw-profile option, which skips the profile check.
* Enable -Wshadowwm42013-11-013-9/+8
| | | | | | | | | This one really did bite me hard (see previous commit), so enable it by default. Fix some cases of shadowing throughout the codebase. None of these change behavior, and all of these were correct code, and just tripped up the warning.