summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 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.
* 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-032-1/+26
| | | | | | | | | | | | | | | | | | | 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-0319-124/+135
| | | | | | | | | | | | | | | | | | 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: move RGBA scaling to vo_vaapiwm42016-07-031-7/+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.
* 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
| | | | | | | | 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.)
* vd_lavc: hide structs behind platform flagsBen Boeckel2016-07-011-0/+4
| | | | Otherwise, warnings about them being unused appear.
* bitmap_packer: remove some unused functionswm42016-07-012-49/+0
|
* vo_direct3d: remove bitmap packerwm42016-07-011-85/+70
| | | | See previous comments.
* vo_vdpau: remove bitmap packer usewm42016-07-011-80/+57
| | | | See previous commit.
* vo_opengl: remove OSD bitmap packingwm42016-07-012-75/+13
| | | | It's packed in the OSD common layer already.
* d3d: implement screenshots for --hwdec=d3d11vawm42016-06-283-0/+86
| | | | | | | | | | | | | | 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.hwm42016-06-287-36/+26
| | | | | | | | 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 shaderMuhammad Faiz2016-06-281-0/+3
| | | | | | logically, scaler should know its input and output size Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: minor typo and coding style fixeswm42016-06-281-5/+5
|
* vo_opengl: revise the transfer curve logicNiklas Haas2016-06-283-17/+37
| | | | | | | | 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 whitespaceNiklas Haas2016-06-281-9/+0
| | | | | 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 spaceNiklas Haas2016-06-281-11/+10
| | | | | | | 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 autoconfigNiklas Haas2016-06-281-14/+17
| | | | | | | | | | | | | | | | | 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 functionNiklas Haas2016-06-285-3/+39
| | | | | | | | | | 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.
* csputils: add Panasonic V-Gamut primariesNiklas Haas2016-06-282-0/+10
| | | | | | | 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.
* vo_opengl: implement ARIB STD-B68 (HLG) HDR TRCNiklas Haas2016-06-284-7/+42
| | | | | | | | | | | | | | This HDR function is unique in that it's still display-referred, it just allows for values above the reference peak (super-highlights). The official standard doesn't actually document this very well, but the nominal peak turns out to be exactly 12.0 - so we normalize to this value internally in mpv. (This lets us preserve the property that the textures are encoded in the range [0,1], preventing clipping and making the best use of an integer texture's range) This was grouped together with SMPTE ST2084 when checking libavutil compatibility since they were added in the same release window, in a similar timeframe.
* ao_lavc, vo_lavc: Migrate to new encoding API.Rudolf Polzer2016-06-271-87/+102
| | | | | Also marked some places for possible later refactoring, as they became quite similar in this commit.
* Fix misspellingsstepshal2016-06-265-5/+5
|
* vo_opengl utils: use gl->main_fb when reading window contentquilloss2016-06-261-1/+4
| | | | | | | | The main framebuffer is not the default framebuffer for the dxinterop backend. Bind the main framebuffer and use the appropriate attachment when reading the window content. Fix #3284
* vo_xv: fix behavior with odd sizeswm42016-06-251-6/+8
| | | | | | | | | | The size check introduced in commit d941a57b did not consider that Xv can round up the image size to the next chroma boundary. Doing that makes sense, so it can't certainly be considered server misbehavior. Do 2 things against this: allow if the server returns a larger image (we just crop it then), and also allocate a properly aligned image in the first place.
* image_writer: port to new encode APIwm42016-06-241-0/+12
|
* vo_opengl: improve missing function warningwm42016-06-221-6/+8
| | | | | Mostly a cosmetic change. Handling bultin and extension functions separaterly makes more sense here too.
* vo_opengl: add scaler name to the 'Disabling scaler' messagedirb2016-06-221-1/+2
| | | | | Print to the user the name of the scaler that gets disabled rather than just printing its number.
* vf_vdpaurb: use new common nv12 download codewm42016-06-211-15/+5
| | | | | | | | | | See previous commit. (The mixing case was never supported, so this has equivalent functionality.) This also implicitly fixes a bug: the old code allocated image data for the cropped surface size only, which means the video_surface_get_bits_y_cb_cr call could write beyond the allocated image memory.
* vdpau: get surface data as nv12 if possiblewm42016-06-212-0/+54
| | | | | | | | | | | | | | | | For now, this affects taking screenshots only. If the video mixer is actually needed, we want to go through the video mixer for screenshots too - which is why this function simply always used the video mixer, and then copied the surface to RAM as RGBA. Add reading the surface as nv12 if possible. If the format is correct, and no special video processing (like deinterlacing) is used, then it's read directly without going through the video mixer. There's no particular reason for doing this, other than avoiding the video mixer (like vo_opengl can do it now). Also, the next commit will make use of this in vf_vdpaurb.c.
* vo_opengl: manually add the GL_BACK_LEFT constant for GLESFloens2016-06-201-0/+4
| | | | | GLES doesn't have this constant. It's not used on GLES. I'm starting to think we need some better way to do this.
* vo_opengl: GL_ARB_timer_query compile fix for GLESFloens2016-06-201-0/+6
| | | | | | | | The GL_ARB_timer_query extension and thus the GL_TIME_ELAPSED constant don't exist for GLES. For ES the EXT_disjoint_timer_query is used so take the constant from that else provide the constant manually. See pr #3216 which introduced this error.
* vf_vdpaurb: fix operationwm42016-06-201-0/+1
| | | | | The hw_subfmt field remained set, while it has to be unset for non-hwdec formats.
* vo_opengl: unmap hwdec images once rendering is donewm42016-06-201-2/+10
| | | | | Instead of keeping them for a while. While keeping the mapping was perfectly ok, nothing speaks against reducing the time they're mapped.
* vo_opengl: vdpau interop without RGB conversionwm42016-06-197-37/+155
| | | | | | | | | | | | | | | | | | | | | | Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
* refqueue: free referenced images on freewm42016-06-191-0/+1
| | | | | | | | Otherwise stale references will survive forever. Could leak hardware video surfaces. In particular, the mpv vdpau code crashed with an assertion when exiting after toggling deinterlacing, because not all references were released.
* bitmap_packet: let max=0 mean unlimitedwm42016-06-182-6/+7
| | | | | And remove the strange PACKER_MAX_WH define. This is more convenient for users which don't care about limits, such as sd_lavc.c.
* vo_opengl: remove prescaling framework with superxbr prescalerBin Jin2016-06-184-351/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: remove uniform buffer object routinesBin Jin2016-06-184-44/+2
|
* vo_opengl: remove nnedi3 prescalerBin Jin2016-06-185-367/+0
|
* cocoa: fix display refresh rate retrieval on multi monitor setupsAkemi2016-06-182-4/+17
| | | | | | | | | | | | | | | | | | 1. this basically reverts commit de4c74e5a4a996e8ff431c8f33a32c4b580be203. even with CVDisplayLinkCreateWithActiveCGDisplays and CVDisplayLinkSetCurrentCGDisplayFromOpenGLContext we still have to explicitly set the current display ID, otherwise it will just always choose the display with the lowest refresh rate. another weird thing is, we still have to set the display ID another time with CVDisplayLinkSetCurrentCGDisplay after the link was started. otherwise the display period is 0 and the fallback will be used. if we ever use the callback method for something useful it's probably better to use CVDisplayLinkCreateWithActiveCGDisplays since we will need to keep the display link around instead of releasing it at the end. in that case we have to call CVDisplayLinkSetCurrentCGDisplay two times, once before and once after LinkStart. 2. add windowDidChangeScreen delegate to update the display refresh rate when mpv is moved to a different screen.
* cocoa: fix actual display refresh rate retrievalAkemi2016-06-181-3/+18
| | | | | | | | | | | | | We have two problems here. 1. CVDisplayLinkGetActualOutputVideoRefreshPeriod, like the name suggests, returns a frame period and not a refresh rate. using this as screen_fps just leads to a slideshow. why didn't this break video playback on OS X completely? the answer to this leads us to the second problem. 2. it seems that CVDisplayLinkGetActualOutputVideoRefreshPeriod always returns 0 if used without CVDisplayLinkSetOutputCallback and hence always fell back to CVDisplayLinkGetNominalOutputVideoRefreshPeriod. adding a callback to CVDisplayLink solves this problem. the callback function at this moment doesn't do anything but could possibly used in the future.
* vo_opengl: dxinterop: render to gl->main_fbJames Ross-Gowan2016-06-181-54/+5
| | | | | | | This can also remove all the stuff for lazily attaching the texture. It doesn't matter if the dxinterop backend changes the bound framebuffer during a VOCTRL, since the renderer does not rely on the GL state being preserved.
* vo_opengl: add ability to render to an arbitrary backing framebufferwm42016-06-183-1/+9
| | | | | | | Most of the functionality already exists for the sake of vo_opengl_cb. We only have to use it. This will be used by dxinterop in the following commit.
* sub, vo_opengl: use packed sub-bitmaps directly if availablewm42016-06-171-28/+80
| | | | | | | | | | | | | | | | | | The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
* sub: move paletted image handling completely to sd_lavc.cwm42016-06-171-1/+2
| | | | | | | | | | | | | | | | | | | Until n