summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* manpage: add some missing color management related sub-propertieswm42016-07-131-0/+3
|
* command: add properties for HDR metadataNiklas Haas2016-07-132-0/+8
| | | | | | | | | Since it turns out that knowing what exactly a file was tagged with can be useful for debugging purposes, expose this as a property so I can check it more easily. This is mostly useful for sig-peak (since nom-peak is currently entirely calculated by us), but I added both for consistency.
* video: respect --deinterlace=autowm42016-07-121-1/+2
| | | | | | | | | | | | | | | | | | | | --deinterlace=auto is the default, and has the obscure semantics that deinterlacing is disabled, unless the user has manually inserted a deinterlacing filter. While in software decoding this doesn't matter, and we will happily insert 2 yadif filters (if the user has already added one), or not remove the yadif filter (if deinterlacing is disabled, but the user has added the filter manually), this is different with hardware deinterlacer filters. These support VFCTRL_SET_DEINTERLACE for toggling deinterlacing filtering at runtime. It exists mainly for legacy reasons, and possibly because it makes switching deinterlacing modes more efficient. It might also gives us an entry-point for VO deinterlacing, maybe. For whatever reasons this mechanism exists, we still support and use it. This commit fixes that video.c always used VFCTRL_SET_DEINTERLACE to disable deinterlacing, even if --deinterlace=auto was set. Fix this by checking the value of the option directly.
* win32: mpv.rc: re-add version infoJames Ross-Gowan2016-07-121-7/+25
| | | | | | | | | | | | | | | | For some reason, the lack of version info was preventing mpv from appearing in the Default Programs dialog. Re-add it, but don't set the string version numbers from version.h, because that's what was causing trouble when the version info was removed. Like the binary version numbers, these are now hardcoded to 2.0.0.0, which probably doesn't matter. The new version info block is also slightly different to the old one. It fills out all the binary VERSIONINFO fields and makes better use of macros. It also removes the \000 line terminators from the string version info, since as far as I can tell, this was just cargo-culting for an old broken version of the Microsoft resource compiler, and binutils' windres terminates the strings properly without them.
* vo_opengl: angle: use WARP if there are no hw adaptersJames Ross-Gowan2016-07-121-2/+45
| | | | | | | | | | | | | | | This should get mpv working on Windows 7 machines without hardware accelerated graphics adapters. It already worked on Windows 8 and up because those systems would silently fall back to WARP if there was no graphics hardware installed. The normal MPGL_CAP_SW flag is not set, so unlike other opengl backends, this will choose a software adapter even if opengl:sw is not specified. The reason for this is, unlike on Linux, where vo_xv and vo_x11 can be used, mpv on Windows does not have any VO to fall back on when hardware acceleration isn't available, so if software adapters are rejected, the user won't see any video output when using the default settings. WARP seems to perform quite well, so it should be used in this case.
* cache: minor simplificationwm42016-07-111-7/+10
| | | | | Every cache_wakeup_and_wait() caller has to deal with asynchronous stream abort, so why not make it somehow part of the function.
* cache: fix previous commitwm42016-07-111-1/+11
| | | | | | | | | | | The cache reader thread actually unlocks the mutex protecting the underlying stream while reading from it. That's why other code goes out of its way to run certain stream operations on the cache thread. Do the same. We could have this simpler by creating a mechanism that would "park" the cache thread and make it wait for the lock (while we have it) in order to gain exclusive access. This could be done in the future.
* cache: propagate seek failureswm42016-07-111-7/+17
| | | | | | | | | | | Eagerly execute seeks to the underlying stream in the cache seek entrypoint itself. While asynchronous execution is a goal of the cache, it doesn't matter too much for seeks. They always were executed within the lock, so the reader was blocked anyway. It's not necessary to ensure async. execution here either, because seeks are relatively rare, and the demuxer can just stay blocked for a while. Fixes: mpv http://samples.mplayerhq.hu/V-codecs/DIV5/ayaneshk-test.avi
* vo_opengl: angle: try D3D9 when D3D11 fails eglInitializeJames Ross-Gowan2016-07-111-7/+8
| | | | | This will happen when D3D11 is present on the machine but the supported feature level is too low.
* audio: fix code for adjusting conversion filterswm42016-07-111-4/+5
| | | | | | | | | | | | | | | This code was supposed to adjust existing conversion filters (to make them output a different format). But the code was just broken, apparently a refactoring accident. It accessed af instead of af->prev. The bug tended to add new conversion filters, even if an existing one could have been used. (Can be tested by inserting a dummy lavrresample filter followed by a format filter which forces conversion.) In addition, it's probably better to return the actual error code if reinitializing the filter fails. It would then respect an AF_FALSE return value, which means format negotiation failed, instead of a generic error.
* af_volume: don't let softvol overwrite af_volume volumedb sub-optionwm42016-07-111-2/+2
| | | | | | | | | | af_volume has a volumedb sub-option, which allows the user to set an explicit volume. Until recently, the player read back this value and used it as initial softvol volume. But now it just overwrites it. Instead of overwriting it, multiply the different gain values. Above all, this will do the right thing if only softvol is used, or if the user only adds the af_volume filter manually.
* audio: add heuristic to move auto-downmixing before other filterswm42016-07-101-7/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, you want downmixing to happen first thing in the filter chain. This is reflected in codec downmixing, which feeds the filter chain downmixed audio in the first place. Doing this has the advantage of needing less data to process. But the main motivation is that if there is a drc filter in the chain, you want to process it the downmixed audio. Add an idiotic heuristic to achieve this. It tries to detect whether the audio was indeed automatically downmixed (or upmixed). To detect what the output format is going to be, it builds the filter chain normally, and then retries with the heuristic applied (and for extra paranoia, retries without the heuristic again if it fails to successfully rebuild the filter chain for unknown reasons). This is simple and will work in almost all cases. Doing it in a more complete way is rather hard, because filters are so generic. For example, we know absolutely nothing about the behavior of af_lavfi, which creates an opaque filter graph with libavfilter. We don't know why a filter would e.g. change the channel layout on its output. (Our heuristic bails out in this case.) We're also slave to the lowest common denominator of how our format negotiation works, and how libavfilter's works. In theory, we could make this mechanism explicit by introducing a special dummy filter. The filter chain would then try to convert between input and output formats at the dummy filter, which would give the user more control over how downmix happens. On the other hand, the user could just insert explicit conversion filters instead, so this would probably have questionable value.
* audio: add auto-inserted flag to filter list loggingwm42016-07-101-0/+2
| | | | Like the video filter chain.
* audio: cleanup audio filter format negotiationwm42016-07-103-149/+62
| | | | | | | | | | | | | | | | | | The algorithm and functionality is the same, but the code becomes much simpler and easier to follow. The assumption that there is only 1 conversion filter (lavrresample) helps with the simplification, but the main change is to use the same code for format/channels/rate. Get rid of the different AF_CONTROL_SET_* controls, and change the af->data parameters directly. (af->data is badly named, but essentially is a placeholder for the output format.) Also, instead of trying to use the af_reinit() loop to init inserted conversion filters or filters with changed output formats, do it inline, and move the common code to a filter_reinit() function. This gets rid of the awful retry variable. In general, this should not change any runtime behavior.
* manpage: minor fixwm42016-07-102-3/+3
| | | | Also fix some other type in interface-changes.rst.
* audio: show an osd bar when changing ao-volumeUros Vampl2016-07-101-1/+17
| | | | also, make the osd msg prettier
* 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 f