summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: remove --demuxer-mkv-fix-timestampswm42015-11-072-29/+1
| | | | | | | | While it seemed like a pretty good idea at first, it's just a dead end and works only in the simplest cases. While it may or may not help slightly with audio sync mode, the display-sync mode already compensates this in a better way. The main issue is that timestamps at this layer are not in order, so it can look at single timestamps only.
* chmap: remove MPlayer layoutswm42015-11-074-39/+0
| | | | Unused; last uses removed with the previous two commits.
* ao_jack: remove "alsa" std-channel-layout choicewm42015-11-072-11/+4
| | | | | Same deal as with previous commit. "waveext" is less arbitrary and at least supports 3/7 channels.
* ao_alsa: remove the last bits of legacy channel map fallbackwm42015-11-071-3/+1
| | | | | | | | Essentially we'd use something random, just because it's part of the srt of traditionally used ALSA channel mappings. But each driver can do its own things. This doesn't let me sleep at night, so remove it.
* audio: fix af_fmt_change_bytes() with spdif formatswm42015-11-071-1/+1
| | | | | | | | | This could accidentally change some spdif formats to AAC (because AAC is the first on the list and will match first). spdif formats are inherently uninterchangeable, so treat them as their own class of formats (like int vs. float). Might fix some issues with ao_wasapi.c.
* vo_opengl: x11: silence error messages when using legacy GL contextwm42015-11-063-2/+16
| | | | | | | | glXCreateContextAttribsARB() by design can throw some X11 errors. We ignore these, but we generally still print error messages to the terminal. This was confusing/annoying users, so silence it. The stupid part is that the Xlib error handler is global, so we have to be slightly careful here.
* Remove some VLAswm42015-11-065-32/+24
| | | | | | | | They are evil and should be eradicated. Some of these were pretty dumb anyway. There are probably some more around in platform specific code or other code not enabled by default on Linux.
* w32: use DisplayConfig API to retrieve correct monitor refresh rateJames Ross-Gowan2015-11-065-19/+303
| | | | | | | | | | This is based on an older patch by James Ross-Gowan. It was rebased and cleaned up. Also, the DWM API usage present in the older patch was removed, because DWM reports nonsense rates at least on Windows 8.1 (they are rounded to integers, just like with the old GDI API - except the GDI API had a good excuse, as it could report only integers). Signed-off-by: wm4 <wm4@nowhere>
* w32: always get screenrc from an HMONITORJames Ross-Gowan2015-11-061-21/+41
| | | | | | | | | | | | | | | | This simplifies update_screen_rect a bit. Unless --fs-screen=all is used, it will always get an HMONITOR and call GetMonitorInfo to determine its dimensions. This will make it easier for the next few commits to determine the colour profile and the refresh rate from the HMONITOR. There is a slight change in behaviour. When selecting a screen that is out of range, such as --screen=9 on a machine with only two monitors, the old code would silently select the last existing monitor. The new code prints an error message and falls back to the default screen (same as the Cocoa code.) Signed-off-by: wm4 <wm4@nowhere>
* w32: remove Win95 and NT4 monitor codeJames Ross-Gowan2015-11-061-25/+4
| | | | | | | | | | | | | | The call to EnumDisplaySettings seems to be a relic from when MPlayer ran on systems that didn't have GetMonitorInfo or SM_CX/CYVIRTUALSCREEN. GetMonitorInfo was loaded dynamically, so it was possible for MPlayer to run without it and use the values returned by EnumDisplaySettings. These are always present in modern versions of Windows, so the values returned from EnumDisplaySettings are always overwritten. Remove the call to EnumDisplaySettings and assume SM_CX/CYVIRTUALSCREEN is always present. Signed-off-by: wm4 <wm4@nowhere>
* video: increase avi pts buffer sizewm42015-11-061-1/+1
| | | | | When decoding on RPI/MMAL, the buffering between decoder input and output can be quite excessive.
* vo_opengl: simplify function loader slightlywm42015-11-061-6/+0
| | | | | We don't use any functions that have been deprecated in any later GL or GLES functions. (This is a leftover of vo_opengl_old support.)
* vo_opengl: glBindBufferBase is not part of GL 2.1/GLES 2.0wm42015-11-062-2/+2
| | | | | | | | Commit 27dc834f added it as such. Also remove the check for glUniformBlockBinding() - it's part of an extension, and the check glGetUniformBlockIndex() already checks whether the extension is fully available.
* demux_mkv: dump mixing/writing app fields in verbose logwm42015-11-061-0/+4
|
* old-makefile: update with latest source additionswm42015-11-051-0/+6
| | | | Yes, I'm still using this.
* vo_opengl: implement NNEDI3 prescalerBin Jin2015-11-0511-5/+403
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement NNEDI3, a neural network based deinterlacer. The shader is reimplemented in GLSL and supports both 8x4 and 8x6 sampling window now. This allows the shader to be licensed under LGPL2.1 so that it can be used in mpv. The current implementation supports uploading the NN weights (up to 51kb with placebo setting) in two different way, via uniform buffer object or hard coding into shader source. UBO requires OpenGL 3.1, which only guarantee 16kb per block. But I find that 64kb seems to be a default setting for recent card/driver (which nnedi3 is targeting), so I think we're fine here (with default nnedi3 setting the size of weights is 9kb). Hard-coding into shader requires OpenGL 3.3, for the "intBitsToFloat()" built-in function. This is necessary to precisely represent these weights in GLSL. I tried several human readable floating point number format (with really high precision as for single precision float), but for some reason they are not working nicely, bad pixels (with NaN value) could be produced with some weights set. We could also add support to upload these weights with texture, just for compatibility reason (etc. upscaling a still image with a low end graphics card). But as I tested, it's rather slow even with 1D texture (we probably had to use 2D texture due to dimension size limitation). Since there is always better choice to do NNEDI3 upscaling for still image (vapoursynth plugin), it's not implemented in this commit. If this turns out to be a popular demand from the user, it should be easy to add it later. For those who wants to optimize the performance a bit further, the bottleneck seems to be: 1. overhead to upload and access these weights, (in particular, the shader code will be regenerated for each frame, it's on CPU though). 2. "dot()" performance in the main loop. 3. "exp()" performance in the main loop, there are various fast implementation with some bit tricks (probably with the help of the intBitsToFloat function). The code is tested with nvidia card and driver (355.11), on Linux. Closes #2230
* file2string: mark question mark as non-safeBin Jin2015-11-051-2/+2
| | | | | Escaping all question marks as well, they can be used to form trigraph characters which are effective even within string literal.
* vo_opengl: add Super-xBR filter for upscalingBin Jin2015-11-058-7/+538
| | | | | | | | | | | Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
* vo_opengl: make image size dynamic during renderingBin Jin2015-11-051-24/+33
| | | | | This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
* options: enable mpeg2 hw decoding by default if hw decoding is requestedwm42015-11-052-4/+4
| | | | | We didn't include this codec in the whitelist because of past problems with vdpau and interlacing. (I can't reproduce any problems anymore.)
* rpi: add support for codecs other than h264wm42015-11-053-7/+20
| | | | FFmpeg now supports h264 and mpeg2. At least vc-1 will probably follow.
* vo_vdpau: check VDP_RGBA_FORMAT_A8 supportwm42015-11-041-2/+6
| | | | | Apparently not all vdpau drivers in the wild support this format (VDPAU SUNXI can't). Revert to RGB in these cases.
* player: use input instead of output format for spdif checkwm42015-11-041-1/+1
| | | | | | This check disables the display-sync resample method. If the filters convert PCM to AC3, we can still insert a filter to change speed. This is because filters are inserted at the beginning of the filter chain.
* audio: do not require full audio chain reinit for speed changeswm42015-11-042-60/+66
| | | | | | | | | | | | | | | Actually, it didn't really require that before (most work was avoided), but some bits had to be run anyway. Separate the speed change into a light-weight function, which merely updates already created filters, and a heavy-weight one which messes with filter insertion. This also happens to fix the case where the filters would "forget" the current speed (force resampling, change speed, hit a volume control to force af_volume insertion - it will reset speed and desync). Since we now always run the light-weight function, remove the af_scaletempo verbose message that is printed on speed setting. Other than that, all setters are cheap.
* player: move audio speed adjustment codewm42015-11-041-54/+60
| | | | | | | | | Move it (in a cosmetic sense), and also move its invocation to below all the video handling. All other changes remain cosmetic, including moving the framedrop calculation code, and getting rid of the video_speed_correction variable.
* af_lavcac3enc: simplify/fix AVPacket handlingwm42015-11-041-16/+21
| | | | | | For some reason, the encoder didn't like that the AVPacket already had fields set. I'm not quite sure, but this might just be invalid API usage. Do it as it's recommended.
* audio: strictly align audio on spdif frameswm42015-11-041-3/+7
| | | | | | We still have a sample-based buffer between filters and audio outputs. In order to avoid cutting frames into half (which can upset receivers), we strictly need to align the boundaries on which we cut the audio.
* options: handle terminal/logging settings eagerlywm42015-11-045-19/+29
| | | | | | | | | | | Update msg.c state immediately if a terminal or logging setting is set. Until now, this was delayed until mp[v]_initialize() was called. When using the client API, you could easily miss logged error messages, even when logging was initialized early on by calling mpv_request_log_messages(). (Properties can't be used for this either, because properties do not work before mpv_initialize().)
* vo_opengl_cb: log some eventswm42015-11-041-0/+4
| | | | | | | | | | The noframe event is logged whenever there is no new frame. This can happen due to normal redraws, but also due to video frame queue underflow. The mpv_opengl_cb_report_flip() API function is currently pretty useless, because blocking on the video frame queue is more reliable and simpler. But at least we can log the actual vsync.
* vo_opengl, vo_opengl_cb: drop unneeded vo_frame fieldswm42015-11-044-28/+6
| | | | | | | | | next_vsync/prev_vsync was only used to retrieve the vsync duration. We can get this in a simpler way. This also removes the vsync duration estimation from vo_opengl_cb.c, which is probably worthless anyway. (And once interpolation is made display-sync only, this won't matter at all.)
* ao_alsa: fix 7.1 over HDMIwm42015-11-041-0/+26
| | | | | | | | | | | | | | | | | We need to effectively swap the last channel pair. See commit 4e358a96 and 5a18c5ea for details. Doing this seems rather strange, as 7.1 just extends 5.1 with 2 new speakers, and 5.1 doesn't need this change. Going by the HDMI standard and the Intel HDA sources (cited in the referenced commits), it also looks like 7.1 should simply append two channels to 5.1 as well. But swapping them is apparently correct. This is also what XBMC does. (I didn't find any other applications doing 7.1 PCM using the ALSA channel map API. VLC seems to ignore the 7.1 case.) Testing reveals that at least the end result is correct. "Normal" ALSA 7.1 is unaffected by this, as it reports a different (and saner) channel layout.
* ao_alsa: map mp_chmaps back to ALSA in a different waywm42015-11-041-39/+54
| | | | | | | | | | | | | | | | Instead of constructing an ALSA channel map from mpv ones from scratch, try to find the original ALSA channel map again. Th result is that we need to convert channel maps only in one direction. If we need to map a mp_chmap to ALSA, we fetch the device's channel map list, convert each entry to mp_chmap, and find the first one which fits. This seems helpful for the following commit. For now, this only gets rid of mapping back the trivial MONO mapping, which alone would still be acceptable, but with other channel layout mogrifications it gets messy fast. While we need to do something awkward to keep our channel map reordering for VAR chmaps (which basically gives nicer output and possibly slightly better performance), this is still the better solution.
* ao_alsa: print more chmap info at debug verbositywm42015-11-041-9/+11
|
* Revert "af_lavrresample: don't drop sl/sr channels for 7.1 on ALSA"wm42015-11-041-28/+5
| | | | | | | | | | | This reverts commit 4e358a963604af8746a059d7388cb202be0f919d. Testing shows the channel pairs must indeed be swapped (details see commit message of the reverted commit). Making the downmix code move sl/sr to sdl/sdr is not an appropriate solution anymore, and it's better to fix the unusual channel layout in ao_alsa.c directly. (Not reverting the change in chmap.c; this is still correct.)
* TOOLS/gen-x11-icon.sh: fix for recent ImageMagickJames Ross-Gowan2015-11-041-1/+1
| | | | | Apparently ImageMagick no longer appends a newline to the format. This also sets the execute bit on the script.
* player: fix display-sync adrop speed limitingwm42015-11-041-1/+2
| | | | Commit 49d94853 worked only at the start of playback.
* vo: do not go to sleep if there's a new frame queuedwm42015-11-031-3/+3
| | | | | | This affects only the display-sync code path, as for normal timing the wakeup_pts stuff handles proper wakeup. It's probably mostly a theoretical issue.
* player: limit speed change in display-sync adrop modewm42015-11-032-0/+9
| | | | | | | | | | Discontinuities (like toggling fullscreen) can cause multiple frames to be dropped in succession, which sounds very weird. It's better to drop some video frames instead to compensate for larger desyncs. We roughly base it on the maximum allowed speed changes (audio change is "additional" to the video change to account for deviations when playing at max. video speed change).
* vd_lavc: make hwdec fallback more tolerantwm42015-11-033-8/+17
| | | | | | | | | | | | A hw decoder might fail to decode a frame for multiple reasons, and not always just because decoding is impossible. We can't generally distinguish these reasons well. Make it more tolerant by accepting failures of 3 frames, but not more. The threshold can be adjusted by the repurposed --vd-lavc-software-fallback option. (This behavior was suggested much earlier in some PR, but at the time the "proper" hwdec fallback was indistinguishable from decoding error. With the current situation, "proper" fallback is still instantious.)
* vo: fix display-sync frame drop accounting againwm42015-11-031-1/+1
| | | | | Commit acd5816a fixed this, except when vo_opengl interpolation was active. (And again, the old interpolation code path should be removed.)
* af_lavrresample: don't drop sl/sr channels for 7.1 on ALSAwm42015-11-032-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ao_alsa: attempt to fix 7.1 over HDMI The last 2 channels of 7.1 (RLC/RRC in ALSA) were exported as sdl/sdr instead of sl/sr (I don't even know why I chose sdl/sdr, but SL/SR and RLC/RRC are different in the ALSA API). libsw/avresample do not move the sl/sr channels to sdl/sdr when rematrixing, so silence was sent for 2 channels. If my selection of sdl/sdr is essentially API abuse, there's no reason why they should do this differently. The mess here is really that ALSa doesn't map the HDMI layouts cleanly. Most ALSA drivers export 7.1 in a way compatible to our expectations, but Intel HDA/HDMI does not: mpv/ffmpeg: fl-fr-fc-lfe-bl-br-sl-sr ALSA/generic: FL FR FC LFE RL RR SL SR [1] ALSA/HDMI: FL FR LFE FC RL RR RLC RRC [2] The HDMI layout is layout 0x13 (going by CEA-861-B). The comment in the kernel code has to be correct too. The early standard defines only 1 other layout, which replaces RLC/RRC with FRC/FLC - this probably corresponds to what we call "7.1(wide)". So it appears when ALSA requests RLC/RRC, we should feed it sl/sr. To make it more complicated, Kodi/xbmc apparently also have to deal with ALSA being special, but instead of sending sl/sr to RLC/RRC, they swap the last two pairs of the layout, and send sl/sr to RL/RR and bl/br to RLC/RRC. Or I might have misunderstood their code. I don't have a 7.1-capable A/V receiver, so I can't test this. For now, go with the simpler solution, and wait until someone tests it. If the speakers end up swapped, a completely different solution will be needed. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/core/pcm_lib.c?id=refs/tags/v4.3#n2434 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/pci/hda/patch_hdmi.c?id=refs/tags/v4.3#n307
* ao_alsa: minor cleanupswm42015-11-031-34/+18
|
* ao_alsa: simplify dmix non-NA hackwm42015-11-031-58/+43
| | | | | There's really no need to do this deep in the chmap sslection code. This will setup the device further than before, but that doesn't matter.
* ao_alsa: move channel map setting code out of main init functionwm42015-11-031-104/+125
| | | | This grew way too large.
* ao_alsa: make failure of buffer parameter setting non-fatalwm42015-11-031-4/+12
| | | | | | | | | | | | | | | | | | | | These calls actually can leave the ALSA configuration space empty (how very useful), which is why snd_pcm_hw_params() can fail. An earlier change intended to make this non-fatal, but it didn't work for this reason. Backup the old parameters, so we can retry with the non-empty configuration space. (It has to be non-empty, because the previous setters didn't fail.) Note that the buffer settings are not very important to us. They're a leftover from MPlayer, which needed to write enough data to the audio device to not underrun while decoding and displaying a video frame. In mpv, most of these things happen asynchronously, _and_ there is a dedicated thread just for feeding the audio device, so we should be pretty imune even against extreme buffer settings. But I suppose it's still useful to prevent PulseAudio from making the buffer too large, so still keep this code.
* ao_alsa: disable resampling first thingwm42015-11-031-7/+7
| | | | | | Again, this could have bad access, is unlikely, and has no bad consequences. It's noteworthy that vlc and the ALSA PCM example both do this first, even if they set the sample rate later.
* ao_alsa: set access type before formatwm42015-11-031-11/+13
| | | | | | | | I'm worried that not restricting the access type before restricting the format will cause problems. While it's unlikely, it might prevent failures in some corner cases. Also, since we by default always use interleaved access (buggy ALSA plugins), this will have no effects at all.
* ao_alsa: handle channel count mismatch safeguard after chmap negotiationwm42015-11-031-12/+12
| | | | | | | | If the API doesn't list padded channel maps, but the final device channel map is padded, and if unpadded output is not possible (unlike in the somewhat similar dmix case), then we shouldn't apply the channel count mismatch fallback in the beginning. Do it after channel map negotiation instead.
* ao_alsa: apply non-NA fallback only if input is stereowm42015-11-031-0/+1
| | | | | | Doesn't matter much; effectively this prevents just log spam in some cases where the map is legitimately padded. Normally this is really only needed for the dmix ALSA case. (See git blame for details.)
* ao_alsa: treat SND_CHMAP_UNKNOWN as NA channel toowm42015-11-031-0/+1
| | | | | | Apparently required by nVidia HDMI. It should not be, and NA would definitely be more correct here, so this could be considered a driver bug. Maybe.
* ao_alsa: remove log message on pausingwm42015-11-031-1/+2
| | | | This was annoying.
* vdpau: fix uninit when init failswm42015-11-012-5/+2
| | | | | | | | | | The uninit() function was called twice if the uninit() function failed (once by init(), once by vd_lavc.c code), which caused crashes due to double-free. (This failure is a corner case, and all other hwdec backends appear to handle this case gracefully.) I do not think this code should be able to deal with uninit() being called other than once. Guarantee that it's called exactly once.
* vo_opengl: win32: fix cross-compilationwm42015-11-011-1/+1
| | | | MXE uses an all-lowercase convention for MS headers.
* vo_opengl: win32: always request MMCSS for DWMwm42015-11-011-0/+5
| | | | | | | | | | | | | | | | | | Quoting MSDN: "Notifies the Desktop Window Manager (DWM) to opt in to or out of Multimedia Class Schedule Service (MMCSS) scheduling while the calling process is alive.". Whatever this means. (An application can change the scheduling priority of the window manager?) Does this improve anything? I have no idea. Certainly this is a program that does multimedia and graphics, so we seem to be a good match for this. Is it bad if we enable this even while playback is inactive or paused? I have no idea either. Is there a magic cargo cult function that will mark our renderer thread as multimedia thing? I have no idea. (We use a function to enable MMCSS for our audio thread in ao_wasapi.)
* vo_opengl: win32: try to enable DwmFlush by defaultwm42015-11-013-11/+52
| | | | | | | | | | | | | | Enable it by default, but not unconditionally. Add an "auto" mode, which disable DwmFlush if the compositor is (probably) inactive. Let's see how this goes. Since I accidentally enabled DwmFlush always by default (more or less) in a previous commit touching this code, this is probably mostly just cargo-culting, and it's uncertain whether it does anything. Note that I still got bad vsync behavior when fullscreening mpv, and making another window visible on the same screen. This happens even if forcing DWM.
* player: another fix to A/V difference calculation in display-sync modewm42015-11-011-1/+1
| | | | | | |