aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* ao_alsa: treat SND_CHMAP_UNKNOWN as NA channel tooGravatar wm42015-11-03
| | | | | | 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 pausingGravatar wm42015-11-03
| | | | This was annoying.
* vdpau: fix uninit when init failsGravatar wm42015-11-01
| | | | | | | | | | 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-compilationGravatar wm42015-11-01
| | | | MXE uses an all-lowercase convention for MS headers.
* vo_opengl: win32: always request MMCSS for DWMGravatar wm42015-11-01
| | | | | | | | | | | | | | | | | | 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 defaultGravatar wm42015-11-01
| | | | | | | | | | | | | | 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 modeGravatar wm42015-11-01
| | | | | | | update_av_diff() works on the timestamps, while time_left is in real time. When playing at not-1 speed, these are very different, and cause the A/V difference to jitter. Fix this by scaling the expected A/V desync to the correct range.
* vo: fix no-audio mode with interpolation enabled/display-sync disabledGravatar wm42015-11-01
| | | | | | | Commit acd5816a broke this. It was stopping playback occasionally. Another case where the non-display-sync interpolation mode (in->vsync_timed==true) is causing a lot of subtle issues and will be removed soon.
* video: fix playback of pal8Gravatar wm42015-11-01
| | | | | | | | | | | PAL8 is the only format that is RGB, has only 1 component, is byte- aligned. It was accidentally detected by the GBRP case as planar RGB. (It would have been ok if it were gray; what ruins it is that it's actually paletted, and the color values do not correspond to colors (but palette entries). Pseudo-pal formats are ok; in fact AV_PIX_FMT_GRAY is rightfully marked as MP_IMGFLAG_YUV_P.
* video: fix another A/V difference bug in display-sync modeGravatar wm42015-10-31
| | | | | | | | | | | | | | | This didn't show up with cases where the frame pattern has a cycle of 1 or 2 like it is the case with 24-on-24 fps, or 24-on-60 fps. It did show up with 25-on-60 fps. (We don't slow down 25 fps video to 24 on default settings.) In this case, we must not add the timing error of the next frame to the A/V difference estimation of the current frame. Use the previous timing error instead. This is another bug resulting from the confusion about whether we calculate parameters for the currently playing frame, or the one we're about to queue.
* vo_direct3d: fix operationGravatar wm42015-10-31
| | | | | | | | | Regression since commit 93db4233. I think the bit that was forgotten here was to remove the vo_w32_config() return value completely. The VO failed to init because that function always returned 0. This commit removes these bits and fixes the VO. Fixes #2434.
* SVG version of the icon (with symbolic counterpart)Gravatar Evgeny Kolesnikov2015-10-30
|
* vo_opengl: add vsync-fences optionGravatar wm42015-10-30
| | | | | | | | | | | | | | | | | | | | | | Yet another relatively useless option that tries to make OpenGL's sync behavior somewhat sane. The results are not too encouraging. With a value of 1, vsync jitter is gone on nVidia, but there are frame drops (less than with glfinish). With 2, I get the usual vsync jitter _and_ frame drops. There's still some hope that it might prevent too deep queuing with some GPUs, I guess. The timeout for the wait call is 1 second. The value is pretty arbitrary; it should just not be too high to freeze the process (if the GPU is un-nice), and not too low to trigger the timeout in normal cases, even if the GPU load is very high. So I guess 1 second is ok as a timeout. The idea to use fences this way to control the queue depth was stolen from RetroArch: https://github.com/libretro/RetroArch/blob/df01279cf318e7ec90ace039d60515296e3de908/gfx/drivers/gl.c#L1856
* vo_opengl: cosmetics: flip the order of 2 functionsGravatar wm42015-10-30
| | | | | draw_frame() is called first, then flip_page(). Order them in the order they're called.
* vo_drm: uninstall signal handlers after quittingGravatar rr-2015-10-30
|
* vo_drm: handle possible errors from sigactionGravatar rr-2015-10-30
|
* vo_drm: check if signal already usedGravatar rr-2015-10-30
|
* stream/audio: fix unchecked strdupsGravatar wm42015-10-30
| | | | | See #2435. It's literally a waste of time trying to fix minor memory leaks in this old, unused, and crappy code.
* command: add mistimed-frame-count propertyGravatar wm42015-10-30
| | | | | Does what the manpage says. This is a replacement incrementing the dropped frame counter (see previous commit).
* video: fix framedrop accounting in display-sync modeGravatar wm42015-10-30
| | | | | | | | | | | | | | Commit a1315c76 broke this slightly. Frame drops got counted multiple times, and also vo.c was actually trying to "render" the dropped frame over and over again (normally not a problem, since frames are always queued "tightly" in display-sync mode, but could have caused 100% CPU usage in some rare corner cases). Do not repeat already dropped frames, but still treat new frames with num_vsyncs==0 as dropped frames. Also, strictly count dropped frames in the VO. This means we don't count "soft" dropped frames anymore (frames that are shown, but for fewer vsyncs than intended). This will be adjusted in the next commit.
* vo_opengl: cache frames only in display-sync modeGravatar wm42015-10-30
| | | | | | | vo_frame.num_vsyncs can be != 1 in some cases in normal sync mode too. This is not a very exact fix, but in exchange it's robust. (These vo_frame flags are way too tricky in combination with redrawing and such.)
* vo_opengl: do not attempt to cache frames in FBO in dumb-modeGravatar wm42015-10-30
| | | | | | | | | | There were occasional shader compilation and rendering failures if FBOs were unavailable. This is caused by the FBO caching code getting active, even though FBOs are unavailable (i.e. dumb-mode). Boken by commit 97fc4f. Fixes #2432.
* manpage: briefly mention libmpvGravatar wm42015-10-30
|
* vd_lavc: fix declarationsGravatar wm42015-10-30
| | | | | | | Fixes linker failure. How did this ever work? Apparently it did most of the time, but apparently we just got the first case where it didn't. Fixes #2433.
* manpage: extend profile documentationGravatar wm42015-10-29
|
* vo: take normal drop path when dropping in display-sync modeGravatar wm42015-10-29
| | | | I hope there wasn't a deeper reason for exiting early.
* vo_drm: show osd in audio only modeGravatar Paul B Mahol2015-10-29
| | | | Signed-off-by: Paul B Mahol <onemda@gmail.com>
* player: raise display sync desync toleranceGravatar wm42015-10-28
| | | | | | | Bump it to 80, and 2 vsyncs. This is another measure against vsync jitter. Admittedly this is a bit simplistic (and we should probably estimate a stable estimated vsync phase instead), but for now this will do.
* player: reset AO stats on pause and other discontinuitiesGravatar wm42015-10-28
| | | | It's annoying.
* player: simplify display-adrop mode safeguardGravatar wm42015-10-28
| | | | | | It's not needed, because the additional data is not appended, but is the total size of the audio buffer. The maximum size is the static audio drop size (or twice, if the audio is duplicated).
* player: minor refactor for A/V diff computationGravatar wm42015-10-28
| | | | | | | | Calculate the A/V difference directly in the display sync code, instead of the awkward current way, which reuses the fields for audio sync. We still set time_frame, because it makes falling back to audio sync somewhat smoother.
* player: fix display sync A/V difference estimation on dropsGravatar wm42015-10-28
| | | | | | | When dropping or repeating frames, we essentially influence when the frame after the next frame will be shown, not the next frame. This led to dropping/repeating frames 2 times, because the A/V difference had a delay of one frame. Compensate it with the expected value.
* sub: remove use of semi-deprecated libass fieldGravatar wm42015-10-28
| | | | | In newer libass version, this does nothing, and will be removed on the next API/ABI bump.
* Replace deprecated av_free_packet() callsGravatar wm42015-10-28
| | | | | | av_free_packet() got finally deprecated. Use av_packet_unref() instead, which has almost the same semantics, has existed for a while, and is available in all FFmpeg and Libav versions we support.
* demux_mkv: fix cluster skip with duration probingGravatar wm42015-10-27
| | | | The start time probing essentially broke it.
* vo: kill non-working missed frame detectionGravatar wm42015-10-27
| | | | | | | | | | | | | | | This was not very reliable. In the normal vo_opengl case, this didn't deal well enough with vsync jitter. Vsync timings can jitter quite extremely, up to a whole vsync duration, in which case the "missed" frame counter keeps growing, even though nothing is wrong. This behavior also messes up the A/V difference calculation, but as long as it's within tolerance, it won't provoke extra frame dropping/repeating. Real misses are harder to detect, and I might add such detection later. In the vo_opengl_cb case, this was additionally broken due to the asynchronity between renderer and VO threads.
* player: disable total-avsync-change update in display-sync modeGravatar wm42015-10-27
| | | | | The total-avsync-change property made no sense in display-sync mode (in addition to making not all that much sense in general).
* player: fix display-sync A/V calculation on high playback speedsGravatar wm42015-10-27
| | | | | | This is all kinds of stupid - update_avsync_after_frame() will multiply this value with the speed at a later point, and we only update this field for this function. (This should be refactored.)
* player: add audio drop/duplicate modeGravatar wm42015-10-27
| | | | Not very robust in the moment.
* player: simplify audio sync pts calculationGravatar wm42015-10-27
| | | | | This was done for symmetry with adjust_sync(). But mpctx->delay is always 0 at this point, so prefer slightly simpler code.
* demux_mkv: fix duration probing for files with non-0 start timeGravatar wm42015-10-26
| | | | | When using --demuxer-mkv-probe-video-duration=full and the file did not start at timestamp 0, the reported duration was still wrong.
* ao_coreaudio_exclusive: check for maximum channel countGravatar wm42015-10-26
| | | | | | Until recently, the channel layout code happened to catch this, but now an explicit check is needed. Otherwise, it'd try to pad the missing channels with NA in the channel map fallback code.
* client API: change error string if playback fails completelyGravatar wm42015-10-26
| | | | | It can print this if AO/VO initialization fails, which makes the wording a lie. Change it to something more diplomatically safe.
* ao_coreaudio_exclusive: fallback to stereo on unknown channel layoutsGravatar wm42015-10-26
| | | | | | | | | | | This is intended for the case when CoreAudio returns only unknown channel layouts, or no channel layout matches the number of channels the CoreAudio device forces. Assume that outputting stereo or mono to the first channels is safe, and that it's better than outputting nothing. It's notable that XBMC/kodi falls back to a static channel layout in this case. For some messed up reason, the layout it uses happens to match with the channel order in ALSA's/mpv's "7.1(alsa)" layout.
* ao_coreaudio_chmap: minor refactorGravatar wm42015-10-26
| | | | | | Share some code between ca_init_chmap() and ca_get_active_chmap(), which also makes it look slightly nicer. No functional changes, other than the additional log message.
* ao_coreaudio_chmap: allow stereo as fallback; avoid mono fallbackGravatar wm42015-10-26
| | | | | | | | | | | | | | | | If no channel layouts were determined (which can actually happen with some "strange" devices), the selection code was falling back to mono, because mono is always added as a fallback. This doesn't seem quite right. Allow a fallback to stereo too, if no channel layout could be retrieved at all. So we always assume that mono and stereo work, if no other layouts are available. (I still don't know what the CoreAudio stereo layout is supposed to do. It could be used to swap left and right channels. It could also be used to pad/move the channels, but I have never seen that. And it can be set to non-stereo channels, which breaks mpv. Whatever.)
* ao_coreaudio: fix another minor memory leakGravatar wm42015-10-26
| | | | How stupid, even the cleanup gotos were already there.
* audio: bump maximum number of channels to 16Gravatar wm42015-10-26
| | | | | | | | | | | The main reason is that ao_coreaudio_exclusive needs this for some OSX devices. They want packed audio, and special-casing this in the coreaudio code would be too much of a pain. The maximum of channels we can support is 64 (because FFmpeg uses 64 bit masks for channel layouts), but since struct mp_audio can get pretty big (has static allocations of 2 pointers for each channel for planar mode), it's less wasteful to stay lower for now.
* audio: use AVFrames with more than 8 channels correctlyGravatar wm42015-10-26
| | | | | | | Requires messy dealing with the extended_ fields. Don't bother with af_lavfi and ao_lavc for now. There are probably no valid use-cases for these.
* af_lavrresample: make planarization pass work with >8 channelsGravatar wm42015-10-26
| | | | | | | | | | av_get_default_channel_layout() fails with channel counts larger than 8. The channel layout doesn't need to make sense, so pick an arbitrary fallback. libswresample also has options for setting the channel counts directly, but better not introduce new concepts in the code. Also, libavresample doesn't have these options.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-20 05:09:56 +0000