summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* audio: move PTS setting out of the decoderwm42015-11-084-18/+16
| | | | | | | Instead of requiring the decoder to set the PTS directly on the dec_audio context (including handling absence of PTS etc.), transfer the packet PTS to the decoded audio frame. Marginally simpler, and gives more control to the generic code.
* vo_drm: relicense to LGPLrr-2015-11-083-10/+15
| | | | | Also removed authorship information (as per convention seen in other files)
* vo_drm: use bool rather than integer return valuesrr-2015-11-084-78/+60
| | | | | Since the errors weren't used for anything other than simple success/fail checks, I simplified things a bit.
* vo_opengl: add DRM EGL backendrr-2015-11-086-8/+467
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
* vo_drm: move initialization to drm_commonrr-2015-11-083-219/+278
| | | | | Makes KMS initialization procedures reusable so that they can be used by the upcoming DRM EGL adapter.
* vo_opengl: fix typorr-2015-11-071-1/+1
|
* vo_opengl: rename fancy-downscaling to correct-downscalingwm42015-11-073-12/+11
| | | | The old name was stupid. Very stupid.
* vo_opengl: fancy-downscaling: enable also for anamorphic clipsAvi Halachmi (:avih)2015-11-072-7/+12
|
* x11: print Xlib errors in verbose mode if Xlib messages are silencedwm42015-11-071-9/+5
| | | | Follow up to commit b984ec52.
* 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
|