summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* OpenGL: Also detect softpipe as a software driverlinkmauve2020-02-251-0/+1
| | | Because it is.
* ipc: allow sending commands with named argumentswm42020-02-242-23/+33
| | | | | | | | | | | | | | This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
* ipc: add more blabla that nobody readswm42020-02-241-0/+23
|
* ipc: implement asynchronous commandswm42020-02-242-11/+90
| | | | | | | | | | | I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
* client API: minor clarification when asynchronous commands send eventswm42020-02-241-0/+5
|
* ta: remove two pointless wrapperswm42020-02-234-7/+3
|
* ta: minor simplificationwm42020-02-231-2/+1
| | | | | Due to the ta_header.parent invariant, the "h->parent->child==h" check is always true.
* client API: fix race condition on client exitwm42020-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The relatively recently added property update code has a race condition when clients exit. It still tried to access mpv_handle during and after it was destroyed. The reason is that it unlocks the lock for the mpv_handle list (while mpv_handle is locked), but nothing in mp_destroy_client() cares about this case. The latter function locks mpv_handle only before/while it makes sure all of its activity is coming to an end, such as asynchronous requests, and property updates that are in progress. It did not include the case when mp_client_send_property_changes() was still calling send_client_property_changes() with mpv_handle locked. Fix this by checking the mpv_handle.destroying field. This field can be set only when mpv_handle is locked. While we're checking the lock, the mpv_handle list is still locked, so at worst we might be at the point before mp_destroy_client() locks the list again and finally destroys the mpv_handle. This is a hard to reproduce race condition which I spotted only once in valgrind by chance, so the fix is unconfirmed.
* ta: change API; ta_set_parent() and ta_set_destructor() never failwm42020-02-233-45/+22
| | | | | | The previous change ensured that these cannot fail anymore (much like in original talloc). Change the APIs to not return a success value anymore, to "cement" this.
* ta: remove seperate internal "ext" headerwm42020-02-231-79/+54
| | | | | | | | | | | | | | | | | | | | | | | | The ta_ext_header was allocated on demand for allocations which have child-allocations or destructors. In theory, it saved 2 words for every TA leaf allocation. It had the very API-visible problem that setting a parent or destructor could fail. (Although in most cases, the failure was part of an allocation call anyway. Also, mpv code generally used the early-failure variants, so it didn't matter.) I think this was a bit too complex. These 2 words don't really matter; if you have memory allocations where you are worried about overhead, then these simply shouldn't use TA. Also, we never added new features to TA that would have needed more "optional" header fields, which would have justified the use of such a separately allocated header struct. This uses quite straight-forward data structures. The only strange thing is that ta_header.parent is NULL for most child allocations. That is because we don't want to iterate over all children when the parent is reallocated (yes, that is allowed, yes mpv makes use of it). The new code has a few more special cases, because the list sentinel concept isn't used anymore. Using it would have made the code more unnatural/complex, because ta_ext_header doesn't exist anymore.
* ta: remove ta_find_parent()wm42020-02-233-18/+0
| | | | Some mpv code once needed this, but it was removed in 2015.
* ytdl_hook: fix URL extraction for manifestssfan52020-02-231-4/+4
|
* cocoa-cb: fix crash with some japanese charactersder richter2020-02-221-1/+2
| | | | | | | | | | | | the actual character that made mpv crash is IDEOGRAPHIC COMMA (U+3001, UTF-8: E3 80 81, 、) and that only in some specific circumstances that could be reliably reproduced on my end. using an NSString instead of the Swift String actually fixes that issues even though they should technically do the exact same thing. i tested all the other String initialisers, but they all had had the same issue. this is kinda only a workaround till i can find a different way of handling it.
* mac, cocoa: fix UI updates on none main queue threadsder richter2020-02-222-5/+11
| | | | | | injecting the Apple Main Thread Checker via DYLD_INSERT_LIBRARIES=libMainThreadChecker.dylib identified several problems that needed fixing.
* cocoa-cb: remove unnecessary semicolonsder richter2020-02-223-16/+16
|
* mac: fix media key support for libmpv usersder richter2020-02-225-43/+33
| | | | | | | | this basically moves the remote command center to our mac events instead of keeping it our Application, which is only available when started from mpv itself. also make it independent of the NSApplication. this also prevents a runtime crash
* x11: switch back to StaticGravitywm42020-02-221-4/+1
| | | | | | | | | | | | | | | | | This was changed 6 years ago (444e583b6) and seemed to work fine. But it does seem to cause issues with IceWM sometimes, while with StaticGravity the problem is gone. Comparing both gravity values, reading the confused source code comment, and reading the referenced commit message, I can't determine what it even does, I just remove it. Reproduction: - start mpv in windowed mode, with 2 videos of different size - switch to second video - switch window with alt+tab - switch back to mpv with alt+tab - window moves to X=0 There's probably a better way to fix this. Please send a patch.
* ytdl_hook: prefer "format" over "format_note" field for track titleswm42020-02-211-1/+1
| | | | | Much more verbose, but on the other hand format_note is useless for the alphabetic site with fragmented DASH streams.
* ytdl_hook: use "format" as fallback for "format_note" for stream titleswm42020-02-211-1/+1
| | | | | "format_note" normally contains a semi-informative description of the format. But some extractors, confusingly, have it in the "format" field.
* ytdl_hook: fix audio codec with some extractorswm42020-02-211-5/+11
| | | | | E.g. soundcloud. While it still worked, not having the audio codec was pretty annoying.
* ytdl_hook: fix Lua escapeswm42020-02-211-3/+3
| | | | | | This was obviously nonsense. In Lua 5.1 this appeared to work correctly, but it really turned "\." into "." (making the pattern accept any character). The proper way is using "%" for escaping.
* ytdl_hook, edl: add fps, samplerate codec parameterswm42020-02-213-2/+18
| | | | Well, didn't help much in the case I was interested it.
* manpage: directly link interface-changes.rst in changelog sectionwm42020-02-211-4/+6
|
* ytdl_hook: make codec mapping more declarativewm42020-02-211-12/+9
|
* ytdl_hook: remove some old playlist redirection hackwm42020-02-211-6/+0
| | | | Should not be needed anymore. In fact, it's probably dangerous.
* ytdl_hook: enable default selection via --ytdl-format with all_formatswm42020-02-212-5/+32
| | | | | | | | | In all_formats mode, we've ignored what --ytdl-format did so far, since we've converted the full format list, instead of just the formats selected by youtube-dl. But we can easily restore --ytdl-format behavior: just mark the selected tracks as default tracks.
* edl: make it possible to set the track "default" flagwm42020-02-212-0/+22
| | | | | Also, the forced flag (and in the future, potentially a number of other flags not implemented yet). See next commit for purpose.
* manpage: fix some path description detailswm42020-02-211-5/+4
|
* manpage: suggest using PuTTY for accessing mpv IPC named pipes on win32wm42020-02-211-0/+3
|
* ytdl_hook: add length parameter to delay-loaded tracks only oncewm42020-02-211-3/+3
| | | | | This was done for each media type, so muxed tracks had it twice, which logged a dumb warning. Move it out of the per-media type loop.
* demux_edl: correct warning on duplicate parameterswm42020-02-211-2/+4
| | | | | | | | A parameter that is actually used is removed from the param_names[] array, so we can report unused parameters. This also happened on duplicate parameters, so adjust the warning to make it less confusing. (In any case, you're not supposed to provide duplicate parameters.)
* ytdl_hook: remove bitrate estimation from file sizewm42020-02-211-4/+0
| | | | | I think this is unnecessary, and at worst done by youtube-dl itself (didn't check).
* ytdl_hook: use tbr for all tracks if vbr/abr not availablewm42020-02-211-0/+9
| | | | | | | | | | | | | | | | | | vbr and abr are the video and audio bitrates. Sometimes there is a weird mix of any of them available, but in these cases, it's not good to fall back to tbr if a specific track has no vbr/abr. For example, the alphabetic site provides tbr only for the muxed fallback stream, but using tbr would make the primitive mpv hls_bitrate selection pick the compatibility stream for audio, because it appears to have a higher bitrate than the other audio-only streams (because the bitrate includes video). So we must not use tbr in this case. On the other hand, formats coming from youtube-dl HLS master playlist use will only have tbr set. So as a heuristic, use the tbr only if it's the only bitrate available in any track entry.
* ytdl_hook: replace skip_muxed with force_all_formats optionwm42020-02-212-42/+43
| | | | | | | | | | | | | I don't think the skip_muxed option was overlay useful. While it was nice to filter out the low quality muxed versions (as it happens on the alphabetic site, I suspect it's compatibility stuff), it's not really necessary, and just makes for another tricky and rarely used configuration option. (This was different before muxed tracks were also delay-loaded, and including the muxed versions slowed down loading.) Add the force_all_formats option instead, which handles the HLS case. Set it to true because they are also delay-loaded now, and don't slow down startup as much.
* manpage: reorganize ytdl_hook option descriptionswm42020-02-211-51/+66
| | | | Make it a proper list, instead of a paragraph soup.
* ytdl_hook: delay-load interleaved fileswm42020-02-211-23/+36
| | | | | | (Or if it's about HLS, just "muxed"/multiplexed streams.) This only affects all_formats=yes,skip_muxed=no modes.
* edl: make it possible to delay-load files with multiple trackswm42020-02-214-17/+65
| | | | | | | | | | | | | | Until now, delay-loading was for files with single tracks only (basically what DASH and HLS like to expose, so adaptive streaming and codec selection becomes easier - for sites, not for us). But they also provide some interleaved versions, probably for compatibility. Until now, we were forced to eagerly load it (making startup slightly slower). But there is not much missing. We just need a way to provide multiple metadata entries, and use them to represent each track. A side effect is now that the "track_meta" header can be used for normal EDL files too.
* demux_lavf: signal no seeking for RTSP streams without durationwm42020-02-201-0/+5
| | | | | | | | | | | | RTSP supports seeking, but at least the libavformat implementation makes this dependent on runtime behavior. So you have to perform a seek, and check if it fails. But even if you do this, the stream is interrupted and restarted, and there seem to be other issues. Assume that RTSP with unknown duration means it's a live stream, and disable seeking in this case, as suggested by the issue reporter. Fixes: #7472
* demux_timeline: don't open every delayed-open track on seekingwm42020-02-201-1/+1
| | | | | | | Now this was stupid. To seek a source, it obviously has to be opened... so just don't try to seek any unused source. If the track is actually selected during playback, a seek to the correct position is performed anyway.
* demux: fix seek range caching with delay_open hackwm42020-02-201-1/+2
| | | | | | These have ->segmented set (so the codec can be initialized properly), but have no segment start or end times. This code was (probably) the only thing which didn't handle this case.
* ytdl_hook: signal duration in all_formats modewm42020-02-201-1/+6
| | | | | | If all streams were delay loaded, there was actually no duration present at all in the EDL metadata. So the length was considered unknown by the player frontend.
* ytdl_hook: attempt to filter out muxed streams if all_formats is usedwm42020-02-202-74/+159
| | | | | | | | | | | | | See manpage additions. We would have to extend delay_open to support multiple sub-tracks (for audio and video), and we'd still don't know (?) whether it might contain more than one stream each (thinking of HLS master streams). And if it's a true interleaved file (such as a "normal" mp4 file provided as fallback for more primitive players), we'd either have to signal such "bundled" tracks, or waste bandwidth. This restructures a lot. The if/else tree in add_single_video for format selection was a bit annoying, so it's split into separate if blocks, where it checks each time whether a URL was determined yet.
* ytdl_hook: remove forgotten debug messagewm42020-02-201-1/+0
| | | | It even has a typo.
* ytdl_hook: use bitrate fields for bitrate metadata instead of file sizeswm42020-02-201-1/+8
| | | | If available.
* ytdl_hook: try to skip interleaved streams with all_formatswm42020-02-201-2/+11
| | | | | | | | | | | | | | | | | If a "format" has both audio and video codec set, it might contain both audio and video. all_format assumes that each format is just a quality variant containing a single track. This seems to happen with sites that provide a HLS master URL. youtube-dl tends to "butcher" it, and the result isn't very ideal. I guess HLS "renditions" simply don't map well to youtube-dl's output format and what mpv expects. Playing master HLS directly is also less than ideal, because of libavformat's stupid probing. Fix this by not using the delay-opening mechanism if it appears like we detected such a case. Add a metadata override to set the track titles to "muxed-N", to indicate that they form a single unit. (Mostly helpful for testing.)
* ytdl_hook: iterate format list by array orderwm42020-02-201-1/+1
| | | | | Shouldn't have any consequences. Probably makes the user-visible order more stable.
* demux_timeline: warn if streams are invisiblewm42020-02-201-0/+6
| | | | | | | | ytdl_hook.lua can do this with all_formats and when delay_open is used, and if the source stream actually contains both audio and video. In this case, it might accidentally hide a media type completely, or waste bandwidth (if the stream has true interleaved audio/video). So it's important to warn.
* player: change bitrate in track listing back to kilobitswm42020-02-201-1/+1
| | | | Because the --hls-bitrate option takes the same unit.
* manpage: minor fixeswm42020-02-192-11/+11
| | | | | In particular, all_formats description split away the example section of an unrelated option, so move that to its proper place.
* scripting: add a way to run sub processes as "scripts"wm42020-02-198-20/+176
| | | | | | | | | | This is just a more convenient way to start IPC client scripts per mpv instance. Does not work on Windows, although it could if the subprocess and IPC parts are implemented (and I guess .exe/.bat suffixes are required). Also untested whether it builds on Windows. A lot of other things are untested too, so don't complain.
* client API: document requirement about PID managementwm42020-02-191-0/+3
| | | | Basically, UNIX sucks. (Not as much as the other POS of course.)
* build: remove fchmod() checkwm42020-02-192-6/+0
| | | | | | This is UNIX-only code, and this function has been in POSIX since forever. Even Android has it. The test should be unnecessary, so remove it.
* ytdl_hook: add all_formats optionwm42020-02-192-18/+102
| | | | | | | | | Pretty worthless I guess. I only tested one site (and 2 videos), it's somewhat likely that it will break with other sites. Even if you leave the option disabled (the default). Slightly related to #3548. This will allows you to use the bitrate stream selection mechanism, that was added for HLS, with normal videos.
* ytdl_hook: add a way to not pass --format to the command linewm42020-02-192-4/+12
| | | | Might be helpful for... whatever.
* player: print manifest per-stream bitrate information to terminalwm42020-02-192-2/+2
| | | | | Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the track title use this.
* input: log commands with parameter nameswm42020-02-191-1/+12
|
* audio: remove outdated commentwm42020-02-191-2/+0
| | | | | | Neither does it (directly) mess with filters, nor does it return a bool. As noticed by a comment in #6333.
* manpage: deprecated options in examplesxPMo2020-02-191-4/+4
| | | | example config and default term-status-msg
* video: drop NV24 aliaswm42020-02-182-4/+0
| | | | | | | Caused build failures with still supported FFmpeg versions. It's unreferenced, so it's not needed. Fixes: #7471
* options: remove deprecation warning for "-foo bar" syntaxwm42020-02-171-3/+0
| | | | | It's still deprecated, but I guess users who preferred typing a space instead of a '=' can use it.
* demux: cosmetic changewm42020-02-171-2/+1
| | | | This was sort of asymmetric and annoying.
* demux: update file-size property even when pausedwm42020-02-161-0/+3
| | | | | | | | | | | While paused, the decoders typically stop reading data from the demuxer. But for some reason, the file size is returned as a public field in struct demuxer (wat...), and updated only when the packet reading function is called. This caused the file size property to always return the same value when paused, even though the demuxer thread was reading new data, and the internal file size was updated. Fix with a simple hack.
* stream_file: remove file size cachingwm42020-02-161-14/+7
| | | | With the last 3 commits, this caching should be completely unnecessary.
* demux: only query stream size at most once per secondwm42020-02-161-5/+9
| | | | | | | | | | Instead of every packet. Doing it every packet led to the performance regression mentioned in the fstat() commit. This should now be over, but out of being careful, don't query the file size that often. This is only used for user interface things, so this should not cause any problems. For the sake of leaving the code compact, abuse another thing that is updated only every second (speed statistics).
* demux: invert update_cache() lockingwm42020-02-161-9/+7
| | | | Equivalent, just slightly more convenient for the following change.
* stream_file: use fstat() instead of lseek() to determine file sizewm42020-02-161-3/+8
| | | | | | | | | |