summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.18.1v0.18.1Martin Herkt2016-07-102-2/+82
|
* Merge branch 'master' into release/currentMartin Herkt2016-07-10106-1960/+2095
|\
| * audio: insert audio-inserted filters at end of chainwm42016-07-091-34/+1
| | | | | | | | | | | | This happens to be better for the af_volume filter (for softvol), and saves some code too. It's "better" because you want to affect the final filtered audio, such as after a manually inserted drc filter.
| * audio: don't crash when changing volume if no audio is initializedwm42016-07-091-0/+3
| | | | | | | | Oversight.
| * man: fix typowm42016-07-091-1/+1
| |
| * audio: drop --softvol=no and --softvol=autowm42016-07-0910-363/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
| * man: fix typosJakub Wilk2016-07-095-11/+11
| |
| * vo_xv, vo_x11: fix typos in warningsJakub Wilk2016-07-092-3/+3
| |
| * man: fix botched sentencewm42016-07-081-3/+3
| | | | | | | | Fixes #3323.
| * vd_d3d11vpp: remove nonsensical flush callwm42016-07-081-5/+0
| | | | | | | | | | | | | | | | I made this call up because I sort of thought this makes senssssse. I'm now convinced that it does not, and even is actively harmful. I'm still quite in the dark how the DirectD 11 video API is supposed to work with synchronization, but at least for normal graphics this call would not make much sense.
| * x11: add missing FocusChangeMaskwm42016-07-081-1/+1
| | | | | | | | | | So we actually get FocusOut events. Disables key repeat when losing focus while a key is down.
| * ao_coreaudio: error out when selecting invalid devicewm42016-07-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When selecting a device that simply doesn't exist with --audio-device, AudioUnit will still initialize and start playback without complaining. But it will never call the audio render callback, which leads to audio playback simply not progressing. I couldn't find a way to get AudioUnit to report an error at all, so here's a crappy hack that takes care of this in most cases. We assume that all devices have a kAudioDevicePropertyDeviceIsAlive property. Invalid devices will error when querying the property (with 'obj!' as status code). This is not the correct fix, because we try to double-guess AudioUnit's behavior by accessing a lower label API. Suggestions welcome.
| * client API: remove "status" log level from mpv_request_event docswm42016-07-082-1/+5
| | | | | | | | | | | | Although it appears to be accepted by the function, MSGL_STATUS messages are never passed to the client API. Consequently "status" has the same meaning as "v" and is useless.
| * command: don't delay progress updates to next video framewm42016-07-081-0/+1
| |
| * video: fix midstream video configuration changeswm42016-07-081-0/+1
| | | | | | | | | | | | | | Commit 771a8bf5 added code to avoid unnecessary vf_reconfig() calls for unrelated reasons, but forget to consider that it has to be called at least once if the input format changes. As a consequence it got "stuck" due to not being able to decode more frames.
| * vo_vdpau: minor simplificationwm42016-07-071-19/+9
| | | | | | | | Remove some indirections that aren't needed anymore.
| * video: limit number of frames sent to VO to the VO requested amountwm42016-07-071-1/+3
| | | | | | | | | | | | | | | | | | | | vo_frame can have more than 1 frame - the extra frames are future references, which are sometimes useful for filtering (vo_opengl interpolation). There's no harm in reducing the number of frames sent to the VO requested amount of future frames, so do that. Doesn't actually reduce the number of concurrently in use frames in practice.
| * player: cut off status line on terminal widthwm42016-07-061-0/+6
| | | | | | | | | | | | | | | | | | | | If the status line is wider than the reported terminal size, then cut it off instead of causing the terminal to scroll down for the next line. This is done in the most primitive way possible, assuming ASCII. This was actually done in the past as far as I'm aware; do it again. (Probably differently.)
| * vf, af: print filter labels in verbose modewm42016-07-062-0/+4
| |
| * video: fix deinterlace filter handling for VFCTRL_SET_DEINTERLACE filterswm42016-07-061-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some filters support VFCTRL_SET_DEINTERLACE. This affects most hardware deinterlace filters. They can be inserted by the user manually, or auto- inserted by vf.c itself as conversion filter (vf_d3d11vpp). In these cases, we shouldn't insert or remove filters outselves, and instead VFCTRL_SET_DEINTERLACE should be invoked to switch the mode. This wasn't done correctly in the recently refactored code and could have broken with --deinterlace. (The refactor only considered switching via property in this case.) Fix it by making it a proper part of the filter_reconfig() function, and making set_deinterlacing() (which is called by the property handler) merely call filter_reconfig() in all cases to do the real work. We can even avoid rebuilding the filter chain - though only if no other auto-filters are inserted. It probably also provides a slightly cleaner way to implement functionality in the VO while still inserting video filter fallbacks correctly if required.
| * vf: mark filter chain as uninitialized when mutating itwm42016-07-061-0/+2
| | | | | | | | | | Sounds fair. Can be used to determine if the filter chain was mutated at all, and avoiding unconditional reinit if it wasn't.
| * video: fix deinterlace filter handling on pixel format changeswm42016-07-061-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test scenario at hand was hardware decoding a file with d3d11 and with deinterlacing enabled. The file switches to a non-hardware dedocdeable format mid-stream. This failed, because it tried to call vf_reconfig() with the old filters inserted, with was fatal due to vf_d3d11vpp accepting only hardware input formats. Fix this by always strictly removing all auto-inserted filters (including the deinterlacing one), and reconfiguring only after that. Note that this change is good for other situations too, because we generally don't want to use a hardware deinterlacer for software decoding by default. They're not necessarily optimal, and VAAPI VPP even has incomprehensible deinterlacer bugs specifically with software frames not coming from a hardware decoder.
| * vf: don't clobber input params on reconfigure failurewm42016-07-061-1/+1
| | | | | | | | I think this is more robust, and future commits will rely on it.
| * player: it's not --force-seeking but --force-seekablewm42016-07-061-1/+1
| | | | | | | | Oops. Fuck.
| * player: rewrite deinterlace filter auto-insertionwm42016-07-054-107/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using the "vf" command code (which changes filters at runtime on user input), use the general filter-insertion code. The latter was added later, and is more suitable for automatically inserted filters. The old code failed in particular when using watch-later saving, which stored the filter list in the resume config file. If a user changed the hardware decoding mode via command line, the stored filter chain was out of date and could cause failure due to not working with hardware or software decoding mode. Storing the deinterlace filter in the filter list was unavoidable, because it was part of the user state. (The new code only edits the actually instantiated filters.)
| * csp: document deviations from the references where they occurNiklas Haas2016-07-052-3/+27
| | | | | | | | | | | | | | | | | | | | These mostly happen in situations where the correct behavior is relatively new and not found in the wild (therefore not worth implementing) and/or extremely complicated (and thus not worth worrying about the potential edge cases and UI changes). Still, it's best to document these where they happen to guide the poor souls maintaining these files in the future.
| * x11_common: silence xdg-screensaverBen Boeckel2016-07-051-1/+1
| | | | | | | | | | Some screen lockers have a habit of dumping output to the terminal when their output is reset. Ignore its output to keep the TTY output clean.
| * subprocess: add a callback to ignore outputBen Boeckel2016-07-052-0/+6
| | | | | | | | This callback is equivalent to shoving data into /dev/null.
| * vo_opengl: angle: update the swapchain on resizeJames Ross-Gowan2016-07-041-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | This uses eglPostSubBufferNV to trigger ANGLE to check the window size and update the size of the swapchain to match, which is recommended here: https://groups.google.com/d/msg/angleproject/RvyVkjRCQGU/gfKfT64IAgAJ With the D3D11 backend, using eglPostSubBufferNV with a 0-sized update region will even skip the Present() call, meaning it won't block for a vsync period. Hopefully ANGLE will have a less hacky way of doing this in future. See the relevant ANGLE issue: http://anglebug.com/1438 Fixes #3301
| * vo_opengl: error out gracefully when trying to use FBOs without FBO APIwm42016-07-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | This can for example happen with vo_opengl_cb, if it is used with a GL implementation that does not supports FBOs. (mpv itself should never attempt to use FBOs if they're not available.) Without this check it would trigger an assert() in our dummy glBindFramebuffer wrapper. Suspected cause of #3308, although it's still unlikely.
| * vf_d3d11vpp: fix output image format if not doing any filteringwm42016-07-041-2/+5
| | | | | | | | | | | | | | For example it should be set to IMGFMT_D3D11NV12 if it isn't already. Otherwise, an assertion in vf.c could trigger. This probably couldn't be provoked yet.
| * input: remove redundant log messagewm42016-07-041-4/+1
| |
| * vo_opengl: move eval_szexpr to user_shaders.cNiklas Haas2016-07-033-102/+124
| | | | | | | | | | | | This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
| * vd_lavc: expose mastering display side data reference peakNiklas Haas2016-07-033-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This greatly improves the result when decoding typical (ST.2084) HDR content, since the job of tone mapping gets significantly easier when you're only mapping from 1000 to 250, rather than 10000 to 250. The difference is so drastic that we can now even reasonably use `hdr-tone-mapping=linear` and get a very perceptually uniform result that is only slightly darker than normal. (To compensate for the extra dynamic range) Due to weird implementation details, this only seems to be present on keyframes (or something like that), so we have to cache the last seen value for the frames in between. Also, in some files the metadata is just completely broken / nonsensical, so I decided to apply a simple heuristic to detect completely broken metadata.
| * vo_opengl: generalize HDR tone mapping mechanismNiklas Haas2016-07-038-91/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
| * mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-0322-151/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
| * vo_opengl: don't constantly resize the output FBONiklas Haas2016-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | Commit 883d3114 seems to have (accidentally?) dropped the FBOTEX_FUZZY from the output_fbo resize, which means that current master will keep resizing and resizing the FBO as you change the window size, introducing severe memory leaking after a while. (Not sure why that would cause memory leaks, but I blame nvidia) Either way, it's bad for performance too, so it's worth fixing.
| * sub: remove unused sub_bitmaps.scaled fieldwm42016-07-032-5/+0
| |
| * sub: move RGBA scaling to vo_vaapiwm42016-07-033-73/+25
| | | | | | | | | | | | | | | | | | vo_vaapi is the only thing which can't scale RGBA on the GPU. (Other cases of RGBA scaling are handled in draw_bmp.c for some reason.) Move this code and get rid of the osd_conv_cache thing. Functionally, nothing changes.
| * sub: change how libass output is converted to RGBA in some caseswm42016-07-035-132/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This affects VOs (or other code which render OSD) which does not support the LIBASS format, but only RGBA. Instead of having a converter stage in osd.c, make mp_ass_packer_pack() output directly in RGBA. In general, this is work towards refcounted subtitle images. Although we could keep the "converter" design, doing it this way seems simpler, at least considering the current situation with only 2 OSD formats. It also prevents copying & packing the data twice, which will lead to better performance. (Although I guess this case is not important at all.) It also fixes --force-rgba-osd-rendering when used with vo_opengl, vo_vdpau, and vo_direct3d.
| * sub: move around some codewm42016-07-031-39/+60
| | | | | | | | | | Put the packing code into separate functions. Preparation for the following commit.
| * sub: pass preferred OSD format to subtitle rendererswm42016-07-039-18/+22
| | | | | | | | | | | | | | | | The intention is to let mp_ass_packer_pack() produce different output for the RGBA and LIBASS formats. VOs (or whatever generates the OSD) currently do not signal a preferred format, and this mechanism just exists to switch between RGBA and LIBASS formats correctly, preferring LIBASS if the VO supports it.
| * vo_opengl: remove caching GL_MAX_TEXTURE_SIZE valuewm42016-07-031-11/+15
| | | | | | | | | | | | | | No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
| * vo_opengl: use ringbuffer of PBOswm42016-07-032-7/+13
| | | | | | | | | | | | | | | | This is how PBOs are normally supposed to be used. Unfortunately I can't see an any absolute improvement on nVidia binary drivers and playing 4K material. Compared to the "old" PBO path with 1 buffer, the measured GL time decreases significantly, though.
| * vo_opengl: support inconsistent negative strides per planewm42016-07-031-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GL generally does not support flipping the image on upload, meaning negative strides are not supported. vo_opengl handles this by flipping rendering if the stride is inverted, and gl_pbo_upload() "ignores" negative strides by uploading without flipping the image. If individual planes had strides with different signs, this broke. The flipping affected the entire image, and only the sign of the first plane was respected. This is just a crazy corner case that will never happen, but it turns out this is quite simple to support, and actually improves the code somewhat.
| * vo_opengl: move PBO upload handling to shared codewm42016-07-034-140/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | This introduces a gl_pbo_upload_tex() function, which works almost like our gl_upload_tex() glTexSubImage2D() wrapper, except it takes a struct which caches the PBO handles. It also takes the full texture size (to make allocating an ideal buffer size easier), and a parameter to disable PBOs (so that the caller doesn't have to duplicate the gl_upload_tex() call if PBOs are disabled or unavailable). This also removes warnings and fallbacks on PBO failure. We just silently try using PBOs on every frame, and if that fails at some point, revert to normal texture uploads. Probably doesn't matter.
| * w32_common: make WM_NCHITTEST simpler and more accurateJames Ross-Gowan2016-07-031-15/+13