summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: fix anamorphic video screenshots (second try)wm42018-03-161-3/+4
| | | | | | | | | | | | | | This passed the display size as source size to the renderer, which is of course nonsense. I don't know what I was doing in 569383bc54. Yet another fix for those damn anamorphic videos. As a somewhat redundant/cosmetic change, use image_params instead of real_image_params in the code above. They should have the same, dimensions (but possibly different formats when doing hw decdoing), and mixing them is confusing. p->image_params wins because it's shorter. Actually fixes #5619.
* img_format.h: cosmetics: fix whitespacewm42018-03-151-1/+1
|
* manpage: document that ---ao overrides --audio-devicewm42018-03-151-1/+3
| | | | Fixes #5640.
* f_hwtransfer: more detailed loggingwm42018-03-151-3/+4
| | | | This also switches the order, because that makes more sense.
* f_hwtransfer: fix a logic errorwm42018-03-151-2/+2
| | | | | Jesus Christ, how did I get this wrong, or never verified proper function. This fixes --vf=vdpaupp not working with yuv420p input.
* vo: pass through framedrop flag differentlywm42018-03-154-17/+5
| | | | | | | | There is some sort-of awkwardness here, because option access needs to happen in a synchronized manner, and the framedrop flag is not in the VO option struct. Remove the mp_read_option_raw() call and the awkward change notification via VO_EVENT_WIN_STATE from command.c, and pass it through as new vo_frame flag.
* vo: move display-fps internal option value to VO optswm42018-03-154-28/+24
| | | | | | Removes the awkward notification through VO_EVENT_WIN_STATE. Unfortunately, some awkwardness remains in mp_property_display_fps(), because the property has conflicting semantics with the option.
* video: add an option to tune waiting for video timingwm42018-03-156-2/+50
| | | | Probably mostly useful for the libmpv render API.
* vo: cosmetics: fix a case of bad whitespacewm42018-03-151-2/+1
|
* client API: deprecate qthelper.hppwm42018-03-152-5/+17
| | | | | | | It's a WTF that we have something as specific in the API. It could be argued that we should provide helpers for other language and GUI toolkit combinations. Obviously that's not going to scale, and it's somewhat likely that it will bitrot. The rest is said in the API changelog.
* vo_gpu: fix anamorphic screenshotswm42018-03-151-2/+2
| | | | | | | | | | | We took the storage size instead of the display size for "unscaled" screenshots. Even if it's called "unscaled", it's still supposed to scale to compensate for aspect ratio. (How many commits fixing anamorphic screenshots in various situations are there?) Fixes #5619.
* mp_image: fix UB with certain callers like vf_vdpauppwm42018-03-151-0/+4
| | | | | | | | | | | | | | | | | | | vf_vdpaupp crashed on certain files (with --hwdec=vdpau --deinterlace). This happened for example with mpeg2 files, which for some reason typically contain some AVFrame side data. It turns out the last change in 55c88fdb8f1a9269 was not quite clean, and forgot the special cases in mp_image_new_dummy_ref(). This function is supposed to copy all metadata from the argument passed, except buffer refs. But there were new buffer refs, that were not cleared properly. Also, the ff_side_data pointer must be cleared, or the new mp_image would try to free it on destruction. The bottom line is that mp_image_new_dummy_ref() is a pretty bad idea, and I suppose all callers with non-NULL arguments should be changed to create a blank mp_image, and copy frame properties as needed (this includes callers of mp_image_new_custom_ref()). Fixes #5630.
* DOCS/options: clarify that --end also supports relative timeRicardo Constantino2018-03-151-2/+2
|
* stream_file: enable cache for FUSE filesystems on OS XPhilip Sequeira2018-03-151-1/+2
| | | | Requested in #634. Better late than never?
* stream_file: add more network file systems (Linux)Philip Sequeira2018-03-151-0/+1
| | | | Fixes #5643.
* client API: send MPV_EVENT_SHUTDOWN only oncewm42018-03-153-3/+6
| | | | | | | | | | | | Before this change, mpv_wait_event() could inconsistently return multiple MPV_EVENT_SHUTDOWN events to a single mpv_handle, up to the point of spamming the event queue under certain circumstances. Change this and just send it exactly once to each mpv_handle. Some client API users might have weird requirements about destroying their state asynchronously (and not reacting immediately to the SHUTDOWN event). This change will help a bit to make this less weird and surprising.
* all: replace mpv_detach_destroy() with mpv_destroy()wm42018-03-154-8/+8
|
* client API: rename mpv_detach_destroy() to mpv_destroy()wm42018-03-154-8/+30
| | | | | Since this has clearer semantics now, the old name is just clunky and confusing.
* client API: add mpv_create_weak_client()wm42018-03-156-5/+44
|
* client API: cleanup mpv_handle terminationwm42018-03-156-113/+150
| | | | | | | | | | | | | | | This changes how mpv_terminate_destroy() and mpv_detach_destroy() behave. The doxygen in client.h tries to point out the differences. The goal is to make this more useful to the API user (making it behave like refcounting). This will be refined in follow up commits. Initialization is unfortunately closely tied to termination, so that changes as well. This also removes earlier hacks that make sure that some parts of FFmpeg initialization are run in the playback thread (instead of the user's thread). This does not matter with standard FFmpeg, and I have no reason to care about this anymore.
* player: move locale check to mp_create()wm42018-03-152-25/+30
| | | | | | The intention is to reduce annoying differences between mpv CLI and libmpv, and there's no reason to have the locale check only in libmpv (although it doesn't help with any real issues either).
* player: shuffle around CLI exit code handlingwm42018-03-152-58/+44
| | | | | Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
* cocoa-cb: fix crash on startup with not initialised title barAkemi2018-03-141-1/+2
| | | | | | | the first mouse events, that try to hide the title bar, could happen before the title bar was actually initialised. that caused our hiding code to access a nil value. check for an available title bar before trying to hide it.
* cocoa-cb: fix crash with forced iGPU on some multi GPU systemsAkemi2018-03-141-3/+5
| | | | | | | | | | | | | there were actually a few small problems. the fatalError() function wasn't supposed to be called there and caused an "Illegal instruction". this was replaced by a print and exit() call. the second problem was that cocoa returns a kCGLBadPixelFormat instead of a kCGLBadAttribute error, which broke our check, immediately exited our loop and no working pixel format was ever created. the third problem was that macOS 10.12 didn't return any errors but also didn't return a pixel format, that also broke our check. now the code checks for both cases. Fixes #5631
* build: fix swift build with waf 1.8.4Akemi2018-03-112-4/+4
| | | | | | | with older waf versions a node doesn't return an absolute path but just a relative one. fix this by explicitly requesting an absolute one. Fixes #5604
* cocoa-cb: remove unneeded icc-profile-auto checkAkemi2018-03-111-3/+1
| | | | | | with the new libmpv API it's not necessary to check for this property anymore since libmpv will only use the provided profile when it is needed.
* cocoa-cb: fix usage of wrong fbo when off-screenAkemi2018-03-111-4/+4
| | | | | | | | when we transitioned to the new libmpv API with commit ae29725 i reintroduced an old bug that was fixed with 7f714c6 because of a dumb rebasing error on my part. the branch i based the libmpv changed on was originally without the fbo fix and on rebasing i forgot to change the variable to the proper one, basically deactivating the fix.
* cocoa-cb: don't deactivate mouse events completely with input-cursor=noAkemi2018-03-111-7/+2
| | | | | | | | | | mouse events and the tracking area are needed for (un)hiding the new title bar, which was broken when input-cursor=no was set. no tracking area was ever created and set which completely deactivated any mouse events. the specific mouse event functions were already deactivated proactively and have the needed check. no events are being propagated to the mpv core when input-cursor=no is set, even with an active tracking area.
* doc: fix formatting of video-frame-info propertiesAman Gupta2018-03-111-5/+5
|
* demux: fix comment typoAman Gupta2018-03-111-1/+1
|
* TOOLS/autoload: be more robust with slow directory listingsRicardo Constantino2018-03-101-11/+24
| | | | | | | | | | Overall, just shuffled code around and added a few debugging messages for future issues. The issue could be reproduced easily by quickly navigating through the playlist inside a network mount. Closes #5618
* vo_vdpau: fix resizing and rotation problemswm42018-03-081-3/+7
| | | | | | | | | | | | | | | The s_size() function, whatever it was supposed to do, caused the surface size to increase indefinitely. Fix by making it always use the maximum size that was last used, which is less optimal (many surface recreations when making the window slowly larger), but at least it works. The rotation code didn't mark the old surface as invalid when it was freed, so it could destroy random other surfaces (let's call it dangling ID). Also, the required rotation surface size depends on the rotation mode, so recreate the surfaces on rotation as well.
* ao_sdl: fix default buffer sizewm42018-03-081-5/+6
| | | | | | | | If you set desired.samples to 0, SDL will return a default buffer size on obtained.samples. This was broken, because ceil_power_of_two(0) returns 1. Since 0 is usually not considered a power of two, this is probably correct, but we still want to set desired.samples to 0 in this case.
* ao: do not allow actual buffer size of 0wm42018-03-081-0/+1
| | | | | | | | | You can use --audio-buffer=0 to minimize the audio buffer size. But if the AO reports no device buffer size (like e.g. ao_jack does), then the buffer size is actually 0, and playback can never work properly. Make it fallback to a size of 1, which is unlikely to work properly, but you get what you asked for, instead of a freeze.
* demux: correctly report buffered size as 0 if there are no packetswm42018-03-081-1/+1
| | | | | | | | | | Since the demuxer cache addition, ds->queue->head can actually be set to non-NULL, but the decoder can still be at EOF (with no packets to come). This made it report an unknown buffered size, instead of 0. Fix this by checking the decoder part of the packet queue instead. Probably doesn't matter much, but fixes an annoying "???" on the CLI status line in some situations.
* vd_lavc: slightly better logging about why hwdec is not usedwm42018-03-081-5/+9
| | | | | The old message was outdated and also not very precise. Make it all a bit more elaborate.
* scripting: make a function staticwm42018-03-082-2/+1
|
* osxbundle: fix bundle creation with python3Akemi2018-03-081-6/+8
| | | | | | | | | | | | | | there were several problems that had to be fixed because of differences between python2 to python3: - subprocess.check_output returned an unicode instead of a string - filter() returns an iterator instead of a list - recursion limit was reached first two were fixed by explicitly converting to the needed type or using the proper function invocation. third was fixed by changing the recursive process_libraries function to an iterative one. Fixes #5600, #3316
* ao_opensles: bump device buffer size to 200mstomty892018-03-071-1/+1
| | | While the soft buffer size is already by default 200ms, it is not enough to guarantee dropout-free playback on Bluetooth audio. Bumping the device buffer size to the same value seems to suffice.
* ao_opensles: remove set_play_state()tomty892018-03-071-10/+1
| | | Set play state to playing in init() instead. We no longer touch the play state afterwards.
* ao_opensles: clear buffer queue in reset()tomty892018-03-071-1/+2
| | | Avoid resume() from causing SL_RESULT_BUFFER_INSUFFICIENT ("Failed to Enqueue: 7" when seek or resume from pause).
* hwdec_drmprime_drm: Fix a DRM buffer memory leakageLongChair2018-03-051-2/+3
| | | | | | | | We use triple buffering for this interop and we were only unreffing the data structures, which doesn't destroy the drm buffers. This patch allows to make sure that we release the drm buffers on playback end.
* cocoa-cb: fix a segfault without videoAkemi2018-03-041-10/+7
| | | | | | | we activated the rendering loop a bit too early and it was possible that the first draw function was called before it was actually ready. this was a remnant from the old init routine and should have been changed. start the queue on reconfigure instead of preinit.
* cocoa-cb: fix wrong aspect ratio on live resize after reconfig resizeAkemi2018-03-041-1/+1
| | | | | | | on a file change and when the aspect ratio of the window changed, the first live resize state had a wrong aspect ratio because the new aspect ratio was only set after the first resize. just set the new content frame before the resize.
* cocoa-cb: change handling of window aspect ratio changesAkemi2018-03-043-34/+16
| | | | | | | | | | | | i tried being smart and handle aspect ratio differences manually via atomic drawing and resizing to aspect fitted frames. there were a few issues with that. like unexpected visibility of certain System GUI elements on entering fullscreen or visually dropped frames due to the atomic drawing. now we rely on system mechanics to keep the proper aspect ratio of our layer, the recommended way. as a side effect it also fixes a segfault. Fixes #5581
* context_drm_egl: Allow fallback EGLConfig formatsAnton Kindestam2018-03-041-17/+49
| | | | | | | | | | | | It turns out that Mali drivers are likely broken, and do not return GBM_FORMAT_ARGB8888 (they return GBM_FORMAT_XRGB8888) when getting EGL_NATIVE_VISUAL_ID for any EGLConfig, even though the resulting EGLConfig appears to be capable of alpha. It could also be potentially useful to allow an ARGB EGLConfig used with an XRGB framebuffer on some platforms, so we do that. (cf. weston) Unrelated indentation fix in gbm_format_to_string.
* tv: Recognise v4l2 'JPEG' fourccPhilip Langdale2018-03-044-3/+8
| | | | | | | | | | | | | Naturally, there's more than one fourcc that indicates an mjpeg stream. I have a particular ancient webcam here (Logitech QuickCam Messanger) that only supports the single 'JPEG' format, but there are other devices out there which support both 'JPEG' and 'MJPG' with no visible differences, and others where the streams are slightly different. Regardless of those details, it remains correct to treat 'JPEG' the same as 'MJPG' from a stream consumption perspective.
* input: minor additions to default key bindingswm42018-03-042-13/+64
| | | | | | | | | This adds key bindings for some semi-popular features. It also tries to cleanup some old bindings. For example w/e for panscan is now changed to w/W. In all cases, the old bindings are still kept and work, though. Part of an ongoing attempt to cleanup the default key bindings. See #973 for some context.
* client: remove legacy API that is unused nowAkemi2018-03-042-44/+1
| | | | | | this API was introduced in c5e4538 solely for the use with cocoa-cb and was not public. with the port to the new API in 760d471 it is now unused and can safely be removed.
* cocoa-cb: use new libmpv API instead of opengl-cbAkemi2018-03-045-62/+76
| | | | | a new replacement API was introduced with b037121 and the old one was deprecated. porting cocoa-cb to the new API.
* cocoa-cb: move the GL dummy function to swiftAkemi2018-03-042-6/+3
| | | | | | it's possible to get a function pointer through a closure after all in swift. remove the GL dummy function from the c header and do it in the swift code instead.
* cocoa-cb: remove debug remnant (stray print)Akemi2018-03-041-1/+0
|
* vo_gpu: don't segfault in libmpv_gl's destroy()Niklas Haas2018-03-041-1/+2
| | | | | This segfaults when the GPU context has not been fully initialized, such as would be the case when initialization errors.
* wscript: also install render API related headersNiklas Haas2018-03-041-1/+2
| | | | Omitted from b0371214
* player: fix strange behavior on edition switchingwm42018-03-031-0/+2
| | | | | | | After switching, the playback state was not reset, which could leave it in a strange, pause like state, that could be fixed by e.g. seeking. This seems to be an older regression - it's even in 0.27.
* player: don't free root filter while it's still neededwm42018-03-031-1/+1
| | | | | | | | | | | | | | Sometimes, playback needs to be fully uninitialized and reinitialized without "officially" closing and reopening the playlist entry. This happens with PT_RELOAD_FILE, which is triggered by edition switching and also DVD/BD title switching. (Not really sure why it goes through so much pain for such obscure cases. All it gains is not resetting "local" options, and not signaling a reload to the client API. Whatever.) The recent filter change freed filter_root too early without recreating it, so it crashed on edition switching. Fixes #5587.
* demux_lavf: add some hacks for SDPwm42018-03-031-0/+6
| | | | | | | Just the usual guess-what-opaque-ffmpeg-thing-supports. See #5550. It looks like we can reduce packet drop by having the cache enabled automatically.
* player: fix track autoselection of external files yet againwm42018-03-031-3/+3
| | | | | | If you used --aufio-file=file.mkv, and file.mkv included a video track marked as default, then the logic in select_default_track() would pick the video track from file.mkv. This is 100% broken, so fix it.
* command: fix whitespacewm42018-03-031-1/+1
|
* video: add option to reduce latency by 1 or 2 frameswm42018-03-035-4/+31
| | | | | | | | | | | | | | | | | | | | The playback start logic explicitly waits until the first frame has been displayed. Usually this will introduce a wait of 1 vsync. For normal playback this doesn't matter, but with respect to low latency needs, this only leads to additional data getting queued up in the demuxer or network buffers. Another thing is that the timing logic decodes 1 frame ahead (= 1 frame extra latency) to determine the exact duration of a frame. To be fair, there doesn't really seem to be a hard reason why this is needed. With the current code, enabling the option does lead to A/V desync sometimes (if the demuxer FPS is too inaccurate), and also frame drops at playback start in some situations. But this all seems to be avoidable, if the timing logic were to be rewritten completely, which should probably happen in the future. Thus the new option comes with the warning that it can be removed any time. This is also why the option has "hack" in the name.
* manpage: describe how to list/inspect/apply profileswm42018-03-031-0/+5
| | | | | This is all documented elsewhere in the manpage, but hard to find from here.
* options: add a builtin low-latency profilewm42018-03-032-0/+49
| | | | | | | | | | Well I guess it doesn't help that much. Also add some stuff that might help to the manpage. The fundamental problem with some "live" sources (e.g. x11grab) is actually that the player gets behind initially, and never thinks it has to catch up. This is also why --untimed can help.
* video: don't read ahead a frame in --untimed modewm42018-03-031-0/+3
| | | | | The extra frame is used to compute the exact frame duration. But frame drop is disabvled with --untimed.
* demux_lavf: add --demuxer-lavf-probe-info=nostreamswm42018-03-032-4/+11
| | | | Another attempt to try to make it behave in certain situations.
* demux: move some code to a separate functionwm42018-03-031-33/+41
| | | | No functional changes.
* demux: improve audio tag merging for OGG fileswm42018-03-031-4/+17
| | | | | | | | | | | | | | It's a mess: mp3 files have user tags as global metadata (because the id3v2 tag is global and there is only 1 stream), while OGG files have it per-track (because it's per-stream on the lowest level). mpv needs to try to make something nice out of the mess. It did so by trying to detect audio-only O