aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* vo_opengl: never load vaapi GLX interop by defaultGravatar wm42015-11-09
| | | | | | | Causes more harm than it helps. Will eventually be removed. Also rename the "reject_emulated" field to "probing" - this is more appropriate now.
* vo_opengl: always preload hwdec interopGravatar wm42015-11-09
| | | | | | | | | Simplifies some auto detection matters. I _still_ don't want to remove the lazy loading mechanism, because it's still slightly useful for filters using the hwdec APIs. My main motivation for not always preloading them is actually that libva prints random useless crap to the terminal with no way to prevent this.
* vo_opengl: rename "drm_egl" to "drm-egl"Gravatar wm42015-11-09
|
* vo_opengl: disable drm_egl autopickupGravatar rr-2015-11-09
|
* dec_audio: add missing includeGravatar wm42015-11-08
| | | | Was masked by FFmpeg's terrible headers, but failed with Libav.
* win32: request MMCSS "Playback" profileGravatar wm42015-11-08
|
* manpage: remove examples and authors sectionGravatar wm42015-11-08
| | | | | | | | | The examples demonstrates use with optical media, which is far from mpv's main purpose. The authors section is a leftover from MPlayer times. There are enough other places which reiterate how mpv is based on mplayer2/MPlayer, copyright statements, and so on.
* manpage: slightly improve configuration files sectionGravatar wm42015-11-08
| | | | | | | | Hint that the linked section contains information for Windows. (Well, that's a lie, but it has a link to the Windows section.) Avoid implying that lines in the config file end with ';'. Also, the <> are probably just confusing.
* audio: interpolate audio timestampsGravatar wm42015-11-08
| | | | | | | | | | | | Deal with jittering Matroska crap timestamps. This reuses the mechanism that is needed for frames without PTS, and adds a heuristic to it. If the interpolated timestamp is less than 1ms away from the real one, it might be due to Matroska timestamp rounding (or other file formats with such rounding, or files remuxed from Matroska). While there actually isn't much of a need to do this (audio PTS jittering by such a low amount doesn't negatively influence much), it helps with identifying jitter from other sources.
* audio: move PTS setting out of the decoderGravatar wm42015-11-08
| | | | | | | 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 LGPLGravatar rr-2015-11-08
| | | | | Also removed authorship information (as per convention seen in other files)
* vo_drm: use bool rather than integer return valuesGravatar rr-2015-11-08
| | | | | Since the errors weren't used for anything other than simple success/fail checks, I simplified things a bit.
* vo_opengl: add DRM EGL backendGravatar rr-2015-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_commonGravatar rr-2015-11-08
| | | | | Makes KMS initialization procedures reusable so that they can be used by the upcoming DRM EGL adapter.
* vo_opengl: fix typoGravatar rr-2015-11-07
|
* vo_opengl: rename fancy-downscaling to correct-downscalingGravatar wm42015-11-07
| | | | The old name was stupid. Very stupid.
* vo_opengl: fancy-downscaling: enable also for anamorphic clipsGravatar Avi Halachmi (:avih)2015-11-07
|
* x11: print Xlib errors in verbose mode if Xlib messages are silencedGravatar wm42015-11-07
| | | | Follow up to commit b984ec52.
* demux_mkv: remove --demuxer-mkv-fix-timestampsGravatar wm42015-11-07
| | | | | | | | 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 layoutsGravatar wm42015-11-07
| | | | Unused; last uses removed with the previous two commits.
* ao_jack: remove "alsa" std-channel-layout choiceGravatar wm42015-11-07
| | | | | 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 fallbackGravatar wm42015-11-07
| | | | | | | | 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 formatsGravatar wm42015-11-07
| | | | | | | | | 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 contextGravatar wm42015-11-06
| | | | | | | | 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 VLAsGravatar wm42015-11-06
| | | | | | | | 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 rateGravatar James Ross-Gowan2015-11-06
| | | | | | | | | | 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 HMONITORGravatar James Ross-Gowan2015-11-06
| | | | | | | | | | | | | | | | 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 codeGravatar James Ross-Gowan2015-11-06
| | | | | | | | | | | | | | 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 sizeGravatar wm42015-11-06
| | | | | When decoding on RPI/MMAL, the buffering between decoder input and output can be quite excessive.
* vo_opengl: simplify function loader slightlyGravatar wm42015-11-06
| | | | | 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.0Gravatar wm42015-11-06
| | | | | | | | 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 logGravatar wm42015-11-06
|
* old-makefile: update with latest source additionsGravatar wm42015-11-05
| | | | Yes, I'm still using this.
* vo_opengl: implement NNEDI3 prescalerGravatar Bin Jin2015-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-safeGravatar Bin Jin2015-11-05
| | | | | 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 upscalingGravatar Bin Jin2015-11-05
| | | | | | | | | | | 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 renderingGravatar Bin Jin2015-11-05
| | | | | 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 requestedGravatar wm42015-11-05
| | | | | 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 h264Gravatar wm42015-11-05
| | | | FFmpeg now supports h264 and mpeg2. At least vc-1 will probably follow.
* vo_vdpau: check VDP_RGBA_FORMAT_A8 supportGravatar wm42015-11-04
| | | | | 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 checkGravatar wm42015-11-04
| | | | | | 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 changesGravatar wm42015-11-04
| | | | | | | | | | | | | | | 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 codeGravatar wm42015-11-04
| | | | | | | | | 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 handlingGravatar wm42015-11-04
| | | | | | 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 framesGravatar wm42015-11-04
| | | | | | 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 eagerlyGravatar wm42015-11-04
| | | | | | | | | | | 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 eventsGravatar wm42015-11-04
| | | | | | | | | | 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 fieldsGravatar wm42015-11-04
| | | | | | | | | 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 HDMIGravatar wm42015-11-04
| | | | | | | | | | | | | | | | | 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 wayGravatar wm42015-11-04
| | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-07 20:40:13 +0000