aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* x11_common: silence xdg-screensaverGravatar Ben Boeckel2016-07-05
| | | | | 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 outputGravatar Ben Boeckel2016-07-05
| | | | This callback is equivalent to shoving data into /dev/null.
* vo_opengl: angle: update the swapchain on resizeGravatar James Ross-Gowan2016-07-04
| | | | | | | | | | | | | 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 APIGravatar wm42016-07-04
| | | | | | | | | | | 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 filteringGravatar wm42016-07-04
| | | | | | | 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 messageGravatar wm42016-07-04
|
* vo_opengl: move eval_szexpr to user_shaders.cGravatar Niklas Haas2016-07-03
| | | | | | 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 peakGravatar Niklas Haas2016-07-03
| | | | | | | | | | | | | | | | | | | 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 mechanismGravatar Niklas Haas2016-07-03
| | | | | | | | | | | | | | | | | | | | | | | | 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 structGravatar Niklas Haas2016-07-03
| | | | | | | | | | | | | | | | | | 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 FBOGravatar Niklas Haas2016-07-03
| | | | | | | | | | 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 fieldGravatar wm42016-07-03
|
* sub: move RGBA scaling to vo_vaapiGravatar wm42016-07-03
| | | | | | | | | 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 casesGravatar wm42016-07-03
| | | | | | | | | | | | | | | | | 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 codeGravatar wm42016-07-03
| | | | | Put the packing code into separate functions. Preparation for the following commit.
* sub: pass preferred OSD format to subtitle renderersGravatar wm42016-07-03
| | | | | | | | 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 valueGravatar wm42016-07-03
| | | | | | | 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 PBOsGravatar wm42016-07-03
| | | | | | | | 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 planeGravatar wm42016-07-03
| | | | | | | | | | | | | | | 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 codeGravatar wm42016-07-03
| | | | | | | | | | | | | 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 accurateGravatar James Ross-Gowan2016-07-03
| | | | | | | | This makes the geometry of the sizing borders more like the ones in Windows 10. It also fixes an off-by-one error that made the right and bottom borders thinner than the left and top borders, which made it difficult to resize the window when using the Windows 7 classic theme (because it has pretty thin sizing borders to begin with.)
* manpage: document confusing "vf clr" command usageGravatar wm42016-07-03
|
* player: add missing space to error messageGravatar wm42016-07-02
|
* vd_lavc: hide structs behind platform flagsGravatar Ben Boeckel2016-07-01
| | | | Otherwise, warnings about them being unused appear.
* readme: fix typoGravatar Ben Boeckel2016-07-01
|
* player: fatal error if linked and compiled FFmpeg versions mismatchGravatar wm42016-07-01
| | | | | | | | | We don't support this anymore. This tries to exit in a controlled way after command line options are applied in order to honor logging options and, in case of libmpv, not to kill the host. Not sure if it would be better to just vomit text to stderr and call abort().
* bitmap_packer: remove some unused functionsGravatar wm42016-07-01
|
* sub: set ASS sub bitmap data to correct pointerGravatar wm42016-07-01
| | | | | Point it to the copied data. Doesn't really matter at this point, but later it might have left dangling pointers.
* vo_direct3d: remove bitmap packerGravatar wm42016-07-01
| | | | See previous comments.
* vo_vdpau: remove bitmap packer useGravatar wm42016-07-01
| | | | See previous commit.
* vo_opengl: remove OSD bitmap packingGravatar wm42016-07-01
| | | | It's packed in the OSD common layer already.
* command: pack sub image data in overlay-add commandGravatar wm42016-07-01
| | | | | | | | | | | | | | Working towards refcounted sub images, and also for removing bitmap packers from VOs. I'm not sure why we even have this overlay-add command. It was sort of "needed" before opengl-cb was introduced, and before Lua scripts could put ASS drawings on OSD without conflicting with the OSC. But now trying to use it doesn't make too much sense anymore. Still keep it because we're trying to be nice, but throw performance out of the window. Now image data is copied 2 more times before displaying it. This also makes using the command a bit simpler.
* ad_lavc: work around braindead ffmpeg behaviorGravatar wm42016-07-01
| | | | | | | | | | | | | | | | | | | | | The libavcodec wmapro decoder will skip some bytes at the start of the first packet and return each time. It will not return any audio data in this state. Our own code as well as libavcodec's new API handling (avcodec_send_packet() etc.) discard the PTS on the first return, which means the PTS is never known for the first packet. This results in a "Failed audio resync." message. Fixy it by remember the PTS in next_pts. This field is used only if the decoder outputs no PTS, and is updated after each frame - and thus should be safe to set. (Possibly this should be fixed in libavcodec new API handling by not setting the PTS to NOPTS as long as no real data has been output. It could even interpolate the PTS if the timebase is known.) Fixes the failure message seen in #3297.
* sub: pack libass bitmaps directly in sd_ass.c and osd_libass.cGravatar wm42016-06-30
| | | | | | | | | | | | | | | | Change all producer of libass images to packing the bitmaps into a single larger bitmap directly when they're output. This is supposed to help working towards refcounted sub bitmaps. This will reduce performance for VOs like vo_xv, but not for vo_opengl. vo_opengl simply will pick up the pre-packed sub bitmaps, and skip packing them again. vo_xv will copy and pack the sub bitmaps unnecessarily - but if we want sub bitmap refcounting, they'd have to be copied anyway. The packing code cannot be removed yet from vo_opengl, because there are certain corner cases that still produce unpackad other sub bitmaps. Actual refcounting will also require more work.
* README: declare that we do not respect FFmpeg ABI rulesGravatar wm42016-06-29
|
* options: deprecate --heartbeat-cmdGravatar wm42016-06-29
| | | | | It's useless. --heartbeat-interval is also considered deprecated, but this is not made explicit.
* options: add a deprecation warning printing mechanismGravatar wm42016-06-29
| | | | | | | | | | We have a warning mechanism for removed and for replaced options, but none yet for options which have been simply deprecated. For the following commit. (Fun fact: just adding the m_option field increases binary size by 14KB.)
* ao_oss: do not add an entry to audio-device-list if device file missingGravatar wm42016-06-29
| | | | | This effectively makes it go away on Linux (unless you have OSS emulation loaded).
* audio: don't add default entry to audio-device-list if AO support listingGravatar wm42016-06-29
| | | | | | | In such cases there isn't really a reason to do so, and using such an entry would probably fail anyway. Also convenient for the following commit.
* d3d: implement screenshots for --hwdec=d3d11vaGravatar wm42016-06-28
| | | | | | | | | | | | | | No method of taking a screenshot was implemented at all. vo_opengl lacked window screenshotting, because ANGLE doesn't allow reading the frontbuffer. There was no way to read back from a D3D11 texture either. Implement reading image data from D3D11 textures. This is a low-quality effort to get basic screenshots done. Eventually there will be a better implementation: once we use AVHWFramesContext natively, the readback implementation will be in libavcodec, and will be able to cache the staging texture correctly. Hopefully. (For now it doesn't even have a AVHWFramesContext for D3D11 yet. But the abstraction is more appropriate for this purpose.)
* d3d: merge angle_common.h into d3d.hGravatar wm42016-06-28
| | | | | | | | OK, this was dumb. The file didn't have much to do with ANGLE, and the functionality can simply be moved to d3d.c. That file contains helpers for decoding, but can always be present (on Windows) since it doesn't access any D3D specific libavcodec APIs. Thus it doesn't need to be conditionally built like the actual hwaccel wrappers.
* vo_opengl: add output_size uniform to custom shaderGravatar Muhammad Faiz2016-06-28
| | | | | | logically, scaler should know its input and output size Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: minor typo and coding style fixesGravatar wm42016-06-28
|
* vo_opengl: revise the transfer curve logicGravatar Niklas Haas2016-06-28
| | | | | | | | Instead of hard-coding a big list, move some of the functionality to csputils. Affects both the auto-guess blacklist and the peak estimation. Also update the comments.
* csputils: adjust whitespaceGravatar Niklas Haas2016-06-28
| | | | | All these blank lines felt sort of weird, especially since the functions were semantically related.
* vo_opengl: revise the logic for picking the default color spaceGravatar Niklas Haas2016-06-28
| | | | | | | Too many "exceptions" these days, it's easier to just hard-code a whitelist instead of a blacklist. And besides, it only really makes sense to avoid adaptation for BT.601 specifically, since that's the one we auto-guess based on the resolution.
* vo_opengl: use image_params instead of *_src for autoconfigGravatar Niklas Haas2016-06-28
| | | | | | | | | | | | | | | | | I'm not even sure why we ever consulted *_src to begin with, since that just describes the current image format - and not the original metadata. (And in fact, we specifically had logic to work around the impliciations this had on linear scaling) image_params is *the* authoritative source on the intended (i.e. reference) image metadata, whereas *_src may be changed by previous passes already. So only consult image_params for picking auto-generated values. Also, add some more missing "wide gamut" and "non-gamma" curves to the autoconfig blacklist. (Maybe it would make sense to move this list to csputils in the future? Or perhaps even auto-detect it based on the associated primaries)
* vo_opengl: implement the Panasonic V-Log functionGravatar Niklas Haas2016-06-28
| | | | | | | | | | User request and not that hard. Closes #3157. Note that FFmpeg doesn't support this and there's no signalling in HEVC etc., so the only way users can access it is by using vf_format manually. Mind: This encoding uses full range values, not TV range.
* manpage: add missing documentation for vf_format:gamma=dci-p3Gravatar Niklas Haas2016-06-28
|
* csputils: add Panasonic V-Gamut primariesGravatar Niklas Haas2016-06-28
| | | | | | | This is actually not entirely trivial since it involves negative Yxy coordinates, so the CMM has to be capable of full floating point operation. Fortunately, LittleCMS is, so we can just blindly implement it.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 04:59:26 +0000