summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* encode: cosmeticswm42018-04-203-93/+107
| | | | Mostly whitespace changes; some semantic preserving transformations.
* vo_lavc: remove pointless uint32_t type for int valueswm42018-04-201-7/+2
| | | | | params->w/h are int, and the further use of these variables are int. The uint32_t is probably some refactoring artifact.
* encode: remove some unused functionswm42018-04-202-20/+0
|
* encoding: deprecate a bunch of obscure optionswm42018-04-204-10/+13
| | | | | --audio-delay does not work correctly yet, but hopefully this can be fixed later.
* audio: fix EOF handling if there was no data at allwm42018-04-201-0/+7
| | | | | | It stopped and did nothing, instead of terminating (or just letting video play, if there was any video). Regression due to recent filter changes.
* video: pass through container fps to filterswm42018-04-197-15/+16
| | | | | | | | | | | | This means vf_vapoursynth doesn't need a hack to work around the filter code, and libavfilter filters now actually get the frame_rate field on input pads set. The libavfilter doxygen says the frame_rate field is only to be set if the frame rate is known to be constant, and uses the word "must" (which probably means they really mean it?) - but ffmpeg.c sets the field to mere guesses anyway, and it looks like this normally won't lead to problems.
* demux: support for some kinds of timed metadatawm42018-04-188-121/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes ICY title changes show up at approximately the correct time, even if the demuxer buffer is huge. (It'll still be wrong if the stream byte cache contains a meaningful amount of data.) It should have the same effect for mid-stream metadata changes in e.g. OGG (untested). This is still somewhat fishy, but in parts due to ICY being fishy, and FFmpeg's metadata change API being somewhat fishy. For example, what happens if you seek? With FFmpeg AVFMT_EVENT_FLAG_METADATA_UPDATED and AVSTREAM_EVENT_FLAG_METADATA_UPDATED we hope that FFmpeg will correctly restore the correct metadata when the first packet is returned. If you seke with ICY, we're out of luck, and some audio will be associated with the wrong tag until we get a new title through ICY metadata update at an essentially random point (it's mostly inherent to ICY). Then the tags will switch back and forth, and this behavior will stick with the data stored in the demuxer cache. Fortunately, this can happen only if the HTTP stream is actually seekable, which it usually is not for ICY things. Seeking doesn't even make sense with ICY, since you can't know the exact metadata location. Basically ICY metsdata sucks. Some complexity is due to a microoptimization: I didn't want additional atomic accesses for each packet if no timed metadata is used. (It probably doesn't matter at all.)
* player: remove in_dispatch fieldwm42018-04-184-17/+35
| | | | (Not sure if worth the trouble, but it does seem less awkward.)
* dispatch: simplify, disallow recursive invocationwm42018-04-181-75/+60
| | | | | | | | | Recursive invocation was needed up until the previous commit. Drop this feature, and simplify the code. It's more logical, and easier to detect miuses of the API. This partially reverts commit 3878a59e. The original reason for it was removed.
* w32_common: avoid recursive dispatch queue callswm42018-04-181-1/+6
| | | | | | | | I suppose this doesn't matter in practice, i.e. even if calls relayed over the dispatch queue will cause WndProc to be invoked, WndProc will never run for a longer time. Preparation for removing recursion support from the dispatch queue code.
* scripting: change when/how player waits for scripts being loadedwm42018-04-185-22/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fundamentally, scripts are loaded asynchronously, but as a feature, there was code to wait until a script is loaded (for a certain arbitrary definition of "loaded"). This was done in scripting.c with the wait_loaded() function. This called mp_idle(), and since there are commands to load/unload scripts, it meant the player core loop could be entered recursively. I think this is a major complication and has some problems. For example, if you had a script that does 'os.execute("sleep inf")', then every time you ran a command to load an instance of the script would add a new stack frame of mp_idle(). This would lead to some sort of reentrancy horror that is hard to debug. Also misc/dispatch.c contains a somewhat tricky mess to support such recursive invocations. There were also some bugs due to this and due to unforeseen interactions with other messes. This scripting stuff was the only thing making use of that reentrancy, and future commands that have "logical" waiting for something should be implemented differently. So get rid of it. Change the code to wait only in the player initialization phase: the only place where it really has to wait is before playback is started, because scripts might want to set options or hooks that interact with playback initialization. Unloading of builtin scripts (can happen with e.g. "set osc no") is left asynchronous; the unloading wasn't too robust anyway, and this change won't make a difference if someone is trying to break it intentionally. Note that this is not in mp_initialize(), because mpv_initialize() uses this by locking the core, which would have the same problem. In the future, commands which logically wait should use different mechanisms. Originally I thought the current approach (that is removed with this commit) should be used, but it's too much of a mess and can't even be used in some cases. Examples are: - "loadfile" should be made blocking (needs to run the normal player code and manually unblock the thread issuing the command) - "add-sub" should not freeze the player until the URL is opened (needs to run opening on a separate thread) Possibly the current scripting behavior could be restored once new mechanisms exist, and if it turns out that anyone needs it. With this commit there should be no further instances of recursive playloop invocations (other than the case in the following commit), since all mp_idle()/mp_wait_events() calls are done strictly from the main thread (and not commands/properties or libmpv client API that "lock" the main thread).
* cocoa-cb: fix a warning with swift 4.1 and slight cleanupAkemi2018-04-171-3/+7
| | | | | | the icc profile data is mutated to an UnsafeMutablePointer and could possibly changed. therefore the size of it should be accessed before a possible change.
* HIDRemote: fix volume buttons on macOS 10.13Akemi2018-04-171-0/+8
| | | | | | | this is a backport of line 1039 to 1046 from https://github.com/iospirit/HIDRemote/commit/33a32ab6136feb8b8220e99ec52c7504c3a82242#diff-8a4d13f0849b3beffa4267954ca28517R1039 Fixes #5721
* hwdec_ios: fix crash after mapper_init failureAman Gupta2018-04-171-2/+4
|
* demux: mark eia608 packets as keyframesAman Gupta2018-04-171-0/+1
| | | | | | This fixes an issue where captions stop rendering after an in-demuxer-cache seek, because the demuxer keeps waiting to find a keyframe (ds->skip_to_keyframe set to true in execute_cache_seek).
* demux, player: mark dependent tracksAman Gupta2018-04-174-1/+5
| | | | | | | ffmpeg marks audio tracks which are not meant to be played standalone as DEPENDENT. these are typically used in DVB broadcasts for audio descriptions, and are meant to be mixed into the main audio track during playback.
* client API: make sure to send IDLE event after mpv_initialize()wm42018-04-161-0/+1
| | | | | | | | | | | This was slightly broken: since mp_initialize() did not necessarily interrupt core_thread() (which is waiting for initialization), it did not enter mp_play_files(), which would have sent an IDLE event. I suppose that in some cases (like with mpv-android), the initial IDLE event was never actually sent, because the first wakeup of the core thread happens with the "loadfile" command, which will disallow the core thread an IDLE event.
* demux_lavf: use new libavformat semantics for stream resyncwm42018-04-161-17/+2
| | | | | | | | | | I changed avio_flush() and introduced avformat_flush() exactly for this reason. Used with DVD/BD only (on seeks and when setting the "angle" property). Seems to work, but wasn't tested too thoroughly (I don't care about optical discs, I only want this ugly stuff gone that might even violate the API/ABI).
* client API: fix potential sporadic freezes on terminationwm42018-04-161-4/+4
| | | | | | | | | | | | | | | Although this was never observed to be happening, it seems definitely possible: we first tell the main thread to exit, and then we ask the main thread to do some work for us (with mp_dispatch_run()). Obviously this is racy, and the main thread could exit without doing this, which would block mp_dispatch_run() forever. Fix this by changing the order of operation, so that it makes sense. We could also just store the pthread_t of the main thread in some variable, but the fact that pthread_create() might set the pthread_t argument _after_ starting the thread makes this a bit messy (at least it doesn't seem to be guaranteed on a superficial look at the manpage).
* client API: clarify that Display pointers etc. need to stay validwm42018-04-162-8/+25
| | | | | | | | | | | | Normally, MPV_RENDER_PARAM* arguments are copied, unless documented otherwise. Of course we can't copy X11 Display or Wayland wl_display types, but for arguments that are "summarized" in a struct (like MPV_RENDER_PARAM_OPENGL_FBO), a copy is expected. Also add some unused infrastructure to make this explicit, and to make it easier to add parameter types that require a copy. Untested.
* f_lavfi: add an option to use old audio PTS handling for af_lavfiwm42018-04-153-1/+45
| | | | | The fix-pts option basically uses the old af_lavfi's (before filter rewrite) timestamp logic. The rest is explained in the manpage.
* DOCS/interface-changes.rst: adjust some audio filter change noteswm42018-04-151-3/+5
| | | | | | | | | | | | The first change is about spdif - I mostly ignore spdif issues these days, but it seems like the recent changes made handling of it slightly better (but I didn't really test). The second change is about broken libavfilter filters. We won't restore the old behavior, because people were complaining about the old behavior in the past. Possibly we could make libavfilter export this was metadata and use the old behavior if we know they're broken - but it doesn't exist yet.
* audio: do not try to resample spdif datawm42018-04-151-0/+5
| | | | | | Normally we don't even try this, but in corner cases it can happen. For example when inserting lavcac3enc at runtime, and display-sync-resample was active.
* audio: don't recreate AO if a filter changes the output formatwm42018-04-152-4/+32
| | | | | | | | | | | | | | | | | | | | | | | Until recently, the AO was reinitialized strictly only on decoder format changes. But the commit for simplifying audio format negotiation removed this. Now the AO is recreated for any format change. This is sort of annoying if you change playback speed. The insertion/removal of af_scaletempo can change the sample format. For example, the acompressor filter will convert output to double, so toggling scaletempo will force the format back to float. This recreates the AO under the --gapless-audio=weak default. This likely affects a lot of other filters too. Work this around by allowing sample format changes, and keeping the current AO format in these cases. This is probably not a big problem. Most audio APIs force the output format to float anyway. This means you actually have to worry about what the default gapless mode does to your audio. If you start with a file that uses 8 bit per sample, and then continue playing a 24 bit FLAC, it will be converted down to 8 bit per sample. (Assuming they are played in a way that uses the gapless logic.)
* ao_alsa: actually report underruns to userwm42018-04-151-5/+5
| | | | | | | | | Print them as a warning. Note that there may be some cases where it underruns, without being a bad condition. This could possibly happen e.g. if the last chunk is written, and then it resumes playback some time after that. Eventually I want to add more code to avoid such spurious warnings.
* f_output_chain: fix typowm42018-04-151-1/+1
|
* audio: change format negotiation, remove channel remix fudgingwm42018-04-153-229/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The audio format neogitation code was pretty complicated, although the idea was simple: when the format changes (or on the first audio frame), filter only the new frame through the entire filter chain, discard the resulting frame, but use the format to initialize the AO. This was useful for "fudging" the channel remix behavior (upmix or downmix), and moving it before other filters. Apparently this was useful for things like DRC filters, which might work better in stereo, and which also can only achieve the desired volume levels by doing it before a downmix, which would modify the volume. This mechanism was introduced in commit 60048b7eb957b (which the commit message also describes as "idiotic heuristic"). Knowing the output format is inherently necessary for this, because otherwise we can't know what the hell the user defined filters will do. There were problems with robustness. Some filters needed more than one frame. Resampling in particular would discard initial audio at high resampling ratios. Some filters might drop audio intentionally (like clipping data on timestamp ranges). There were also allegations that some decoders output 0 length frames (although that is invalid in libavcodec). The state machine was excessively complex and hard to understand too. There are 3 things that could have been done: 1. Fix robustness problems by doing more heuristics, like repeating audio frames or simply decoding several frames. Since filters can behave differently, this would have added lots of complexity. 2. Make use of libavfilter's format negotiation, and add the same to mpv builtin filters. This is sort of annoying, because the format negotiation in libavfilter changes the state of the filters. It also reports only some parameters (mostly all for audio, but a lot of holes for video). It would remove some of the state machine, but not all. 3. Drop the channel remix fudging, and do the same as the video chain. This would not require format negotiation, but instead you can just filter the audio frames, and look what comes out of it. If nothing comes out, simply never create an AO. This commit selects option 3. It removes the remix fudging, which means the loss of a feature. Users can instead add "--af=format=channels=2" before their DRC filter, or something. I'm also considering changing the default for --audio-channels back to stereo, and downmix in the decoder or at the start of the filter chain, which would give the same results, except requiring more configuration. Implementation-wise, this is still a bit different from the video path. The VO always remains the same instance, while the AO might have to be recreated on configuration changes. This still requires explicit format change handling + draining old data, but by putting it into f_autoconvert, not much new code is needed.
* f_autoconvert: be less clever about running specific codepathswm42018-04-151-28/+14
| | | | | | | This tried to avoid running the audio/video functions depending on whether any of the audio or video related format restrictions were called (so the filter would show an error if a mismatching media type was passed in). It was a shit idea anyway, so fuck it.
* ao_pulse: reduce requested device buffer sizewm42018-04-152-2/+2
| | | | | | Same deal as with the previous commit for ALSA. Untested.
* ao_alsa: reduce requested buffer sizewm42018-04-151-2/+2
| | | | | | There is a dedicated thread for feeding audio to the ALSA API from a buffer with a larger size. There is little reason to have such a large device buffer.
* ao_alsa: add options for controlling period/buffer sizewm42018-04-152-8/+30
|
* ytdl_hook: don't log error when loading is abortedwm42018-04-151-2/+6
|
* stream_libarchive: mark as needing cachewm42018-04-151-0/+1
| | | | | Seeking back can be excessively slow with most formats, so it'll benefit from this.
* demux: fix deadlock on "program" property changeswm42018-04-151-0/+6
| | | | | Tries to recursively lock a non-recursive lock, which usually ends in a deadlock. Must have been broken by some past refactor.
* demux_mkv: fix certain cases of recursive SeekHeadswm42018-04-151-4/+1
| | | | | | | | | | | | | | | Some shittily muxed files (by a certain HandBrake+libavformat combo) contain a SeekHead pointing to a SeekHead at the end of the file, which in turn points to track headers (also at the end of the file). This failed because the demuxer didn't bother to actually read the elements listed by the second SeekHead, so no track headers were read, and playback broke. Somehow commit 6fe75c38 broke this for no reason. It adds a "needed" field, which seems completely pointless and replaced the "parsed" flag in an incomplete way. In particular, the "needed" field was not set when a _recursive_ SeekHead was read, so those elements were not read. Just get rid of the field and use "parsed" instead.
* vo_gpu: hwdec: Use ffnvcodec to load CUDA symbolsPhilip Langdale2018-04-155-246/+50
| | | | | | The CUDA dynamic loader was broken out of ffmpeg into its own repo and package. This gives us an opportunity to re-use it in mpv and remove our custom loader logic.
* build: fixup vendored wayland protocols with variantsJan Ekström2018-04-152-10/+31
| | | | | | Utilize the SRC variable for this to get a built-in relative path. Can be tested by adding `--variant="random_string"` to configure and build.
* ao_openal: document the muted↔gain conversionJan Ekström2018-04-151-0/+3
| | | | This struck me as odd for a moment, so adding a comment.
* ao/openal: Remove notes on experimentality from the documentationLAGonauta2018-04-151-4/+1
| | | | | Also, multi-channel audio should be fast now with the use of the MC extensions.
* ao/openal: Add option to set buffering characteristicsLAGonauta2018-04-152-23/+70
| | | | | | | | | One can now set the number of buffers and the buffer size. This can reduce the CPU usage and the total latency stays mostly the same. As there are sync mechanisms the A/V sync continue intact and working. It also modifies 6.1 channel order, as per OpenAL spec and add AOPLAY_FINAL_CHUNK support
* ao/openal: Add better sample format and channel layout selectionLAGonauta2018-04-151-139/+73
| | | | Also re-added floating-point support.
* ao/openal: Add OpenAL Soft extension to get the correct latencyLAGonauta2018-04-151-1/+16
| | | | | | | | OpenAL Soft's AL_SOFT_source_latency extension allows one to correctly get the device output latency, facilitating the syncronization with video. Also added a simpler generic fallback that does not take into account latency of the device.
* ao/openal: Add support for direct channels outputLAGonauta2018-04-152-0/+16
| | | | | | | Uses OpenAL Soft's AL_DIRECT_CHANNELS_SOFT extension and can be controlled through a new CLI option, --openal-direct-channels. This allows one to send the audio data direrctly to the desired channel without effects applied.
* ao/openal: Add hardware mute supportLAGonauta2018-04-151-0/+12
| | | | | While the volume is set on the listener, mute is set on the sound source. Seemed easier that way.
* ao/openal: Use only one source for audio outputLAGonauta2018-04-151-52/+153
| | | | Floating point audio not supported on this commit.
* opengl: include details in EGL context errorsAman Gupta2018-04-121-3/+3
|
* demux_lavf: skip demuxer hack iteration if hacks are disabledsergey.dobrodey2018-04-121-3/+1
|
* demux_mkv: add V_AV1 identifier for AV1Jan Ekström2018-04-081-0/+1
| | | | | | | | | | | Quickly tested by a person who had FFmpeg linked with libaom. Seems as simple as the VP9 mappings, where there is no extradata/ initialization data off-band, and just stuff in the packets themselves. Do note that the AV1 video format itself at this point is still not frozen, so what you might produce one day might not be decodable the following day.
* manpage: document vaapi-deviceKevin Mitchell2018-04-081-0/+4
| | | | This was left out of e3e2c79 by mistake.
* manpage: move cuda-decode-device with hwdec optionsKevin Mitchell2018-04-081-10/+10
|
* js: use new hooks API (match f60826c3)Avi Halachmi (:avih)2018-04-072-10/+50
|
* js: dump(..): fix incorrect <VISITED> with array argumentAvi Halachmi (:avih)2018-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | When dump's argument is an array, it was displaying <VISITED> for all the array's object elements (objects, arrays, etc), regardless if they're actually visited or not. The reason is that we try to stringify twice: once normally which may throw (on cycles), and a second time while excluding visited items which is indicated by binding the replacer to an empty array - in which we hold the visited items, where the replacer tests if its 'this' is an array or not and acts accordingly. However, its "this" may also be an array even if we don't bind it to one, because its "normal" this is the main stringified object, so the test of Array.isArray(this) is true when the top object is an array, and the object items are indeed are in it - so the replacer considers them visited. Fix by binding to null on the first attempt such that "this" is an array only when we want it to test for visited items and not when the argument itself is an array.
* js: implement mp.register_idleAvi Halachmi (:avih)2018-04-072-7/+53
| | | | | | | | | | Due to earlier misinterpretation of the Lua docs as if mp.register_idle registers a one-shot callback, the JS docs suggested to use setTimeout. But the behavior and Lua docs are such that it's a repeating callback which fires just before the script thread goes to sleep. Implement it for JS too.
* js: implement mp.options.read_optionsAvi Halachmi (:avih)2018-04-072-8/+60
|
* config: replace config dir lua-settings/ with dir script-opts/Avi Halachmi (:avih)2018-04-076-5/+14
| | | | lua-settings/ is still supported, with deprecation warning.
* ao_opensles: let cfg_frames_per_buffer accept buffer size up to 0.5s at 192kHzTom Yan2018-04-051-1/+1
|
* ao_opensles: remove useless cfg_sample_rateTom Yan2018-04-052-5/+1
| | | | We should always use the ao-neutral --audio-samplerate option.
* ao_opensles: bump device buffer size to 250msTom Yan2018-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although half (non-fast track on sink rate) or one-third (non-fast track not on sink rate) of the buffer size of the created AudioTrack instance as the SL Enqueue buffer size is basically enough for dropout-free playback, only using the full size can avoid stutter upon (re)start of playback. Here are the various buffer sizes on different track/sink rate when on Bluetooth audio on Android O: aptX @ 48kHz: Sink rate: 48000 Hz 44100 Hz: 10632 frames (241.09 ms) 48000 Hz: 11544 frames (240.50 ms) 88200 Hz: 21216 frames (240.54 ms) 96000 Hz: 23088 frames (240.50 ms) 176400 Hz: 42384 frames (240.27 ms) 192000 Hz: 46128 frames (240.25 ms) SBC/AAC/aptX @ 44.1kHz: Sink rate: 44100 Hz 44100 Hz: 10776 frames (244.35 ms) 48000 Hz: 11748 frames (244.75 ms) 88200 Hz: 21552 frames (244.35 ms) 96000 Hz: 23448 frames (244.25 ms) 176400 Hz: 43056 frames (244.08 ms) 192000 Hz: 46848 frames (244.00 ms) The above results were produced with the following code: import android.media.AudioAttributes; import android.media.AudioFormat; import android.media.AudioTrack; class AudioInfo { public static void main(String[] args) { int nosr = AudioTrack.getNativeOutputSampleRate(3); System.out.printf("Sink rate: %d Hz\n", nosr); int[] rates = {44100,48000,88200,96000,176400,192000}; for (int rate: rates) { AudioAttributes aa = new AudioAttributes.Builder().setFlags(256).build(); AudioFormat af = new AudioFormat.Builder().setSampleRate(rate).build(); AudioTrack at = new AudioTrack(aa, af, 4, 1, 0); int sr = at.getSampleRate(); int bs = at.getBufferSizeInFrames(); float ms = bs * (float) 1000 / sr; at.release(); System.out.printf("%d Hz: %d frames (%.2f ms)\n", sr, bs, ms); } } } Therefore bumping the device buffer size to 250ms.
* ao_opensles: do one buffer onlyTom Yan2018-04-051-15/+8
| | | | Doing two buffers causes stutters upon (re)start of playback on Android O for all kinds of sinks.
* av_common: cosmetic simplification to ffmpeg component iteration loopswm42018-04-031-4/+2
|
* f_lavfi: use new libavfilter iteration APIwm42018-04-033-5/+6
|
* video: remove libavutil PSEUDOPAL stuffwm42018-04-033-6/+3
| | | | Not needed anymore with newest libavutil.
* vaapi: add option to select a non-default device pathRostislav Pehlivanov2018-03-303-27/+52
| | | | | | | | | | | On machines with multiple GPUs, /dev/dri/renderD128 isn't guaranteed to point to a valid vaapi device. This just adds the option to specify what path to use. The old fallback /dev/dri/card0 is gone but that's not a loss as its a legacy interface no longer accepted as valid by libva. Fixes #4320
* lavc_conv: do not allow libavcodec to drop subtitles with broken UTF-8wm42018-03-262-1/+2
| | | | | | | libavcodec normally drops subtitle lines that fail a check for invalid UTF-8 (their check is slightly broken too, by the way). This was always annoying and inconvenient, but now there is a mechanism to prevent it from doing this. Requires newst libavcodec.
* player: fix hook processing consistency and code duplication issueswm42018-03-263-45/+20
| | | | | | | | | | | | | | | | | | | | | | | | There was a "generic" function to run a hook and to wait for its completion, yet there were two duplicated functions doing the same anyway. Replace them with a single function. They differed in how stop_play was handled, but it was broken anyway. stop_play is set when playback is stopped due to quitting or changing the playlist entry - but we still can't stop hook processing, because that would mean asynchronously doing something else while the user hook code is still busy and might still have the expectation that running the hook stops everything else. So not waiting until the hook ends properly is against the whole hook idea. That this was done inconsistently is even worse. (Though it could be argued that when quitting the player, everything should just be stopped violently. But I still think that's up to the hook handler.) process_hooks() does not return anything, since hook processing doesn't really have a result (it's all about blocking and letting some other code synchronously do something). Just let the caller check whether loading was aborted in the meantime. Also change the potentially misleading name of mp_hook_run().
* client API: add a first class hook API, and deprecate old APIwm42018-03-2614-103/+283
| | | | | | | | | | | | | | | As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
* client API: deprecate mpv_get_wakeup_pipe()wm42018-03-263-17/+24
| | | | I don't think anything even uses it.
* command: remove an old compatibility hackwm42018-03-262-48/+3
| | | | | Was removed 3 releases ago and was spamming warning messages that it'll be dropped, so it's fine to remove it now.
* command: remove duplication of property set error message handlingwm42018-03-261-59/+36
| | | | | | | | Move all of this stuff to a common function. This makes the error messages less specific, but I don't think anyone will miss it. The OSD flag handling is annoying, but it's nothing that should be changed with this commit.
* command: move property multiply code to m_property.cwm42018-03-263-26/+36
| | | | | | | I think this will help with reducing code duplication (see following commit). The error messages loses the multiplication factor, but the error message will be replaced by a generic one in the following commit anyway.
* command: use mpv_node helpers instead of duplicated codewm42018-03-262-27/+12
| | | | | | They didn't exist yet when this code was added. Completely untested.
* manpage: mention how to get multiple video tracks for --lavfi-complexwm42018-03-261-0/+2
| | | | See #5670.
* client API: add a new way to pass X11 Display etc. to render APIwm42018-03-2624-144/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware decoding things often need access to additional handles from the windowing system, such as the X11 or Wayland display when using vaapi. The opengl-cb had nothing dedicated for this, and used the weird GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not officially registered with OpenGL). This was awkward, and a pain due to having to emulate GL context behavior (like needing a TLS variable to store context for the pseudo GL extension function). In addition (and not inherently due to this), we could pass only one resource from mpv builtin context backends to hwdecs. It was also all GL specific. Replace this with a newer mechanism. It works for all RA backends, not just GL. the API user can explicitly pass the objects at init time via mpv_render_context_create(). Multiple resources are naturally possible. The API uses MPV_RENDER_PARAM_* defines, but internally we use strings. This is done for 2 reasons: 1. trying to leave libmpv and internal mechanisms decoupled, 2. not having to add public API for some of the internal resource types (especially D3D/GL interop stuff). To remain sane, drop support for obscure half-working opengl-cb things, like the DRM interop (was missing necessary things), the RPI window thing (nobody used it), and obscure D3D interop things (not needed with ANGLE, others were undocumented). In order not to break ABI and the C API, we don't remove the associated structs from opengl_cb.h. The parts which are still needed (in particular DRM interop) needs to be ported to the render API.
* f_decoder_wrapper: retry decoding if libavcodec returns invalid statewm42018-03-261-2/+7
| | | | | | | | | | | | | | | | | At least the libavcodec MediaCodec wrapper sometimes seems to break the libavcodec API, and does the following sequence: send_packet() -> EAGAIN receive_frame() -> EAGAIN send_packet() -> OK The libavcodec API never allows returning EAGAIN from both functions, so we discarded packets in this case. Change it to retrying decoding, for the sake of MediaCodec. Note that it could also happen due to internal bugs in the vd_lavc.c hw fallback code, but if there are any remaining, they should be fixed properly instead. Requested.
* player: don't print error if aborted while loading external fileswm42018-03-261-1/+2
|
* demux, stream: ignore packets and errors on forced exitwm42018-03-262-3/+4
| | | | | | | | | | When this happens, network calls are forcibly aborted (more or less), but demuxers might keep going, as most of them do not check for forced exits properly. This can possibly lead to broken packets being added. Also do not attempt to read more packets in this situation. Also do not print a stream open failed message if opening was aborted anyway.
* cocoa-cb: render on a dedicated dispatch queueAkemi2018-03-253-28/+36
| | | | | | | | | | | we rendered on the displaylink thread which wasn't the best idea. if rendering took too long or was blocking it also blocked the displaylink callback. when that happened new vsyncs were reported delayed or not at all. consequently the mpv_render_context_report_swap function wasn't called consistently and that could cause bad video playback. so the rendering is moved to a dedicated dispatch queue. furthermore the update callback starts a layer update directly instead of the displaylink callback, making the rendering a bit more consistent.
* stats: print section titles independentlyJulian2018-03-251-3/+6
| | | | | | | Previously, section titles (File/Video/Audio) were printed as suffix of a property that was assumed to always exist. However, with e.g. lavi-complex this is not the case, therfore, print them without being dependent on a property.
* stats: improve video/audio detectionJulian2018-03-251-30/+29
| | | | | | | | | Switch from audio|video to audio|video-out-params properties as per recommendation in #5670. These properties are tables and include information explicitly queried later, so switch to using these tables and reduce the amount of queried properties. Fixes #5670
* ao_opensles: re-flow interface/configuration retrievalJan Ekström2018-03-241-9/+18
| | | | | This manages to make the code more readable. Thanks to MakeGho@IRCnet for the snippet on which this was based.
* ao_opensles: fix audio sync using device latency extensionAman Gupta2018-03-231-3/+20
|
* drm/atomic: ensure request is available until uninitLongChair2018-03-231-3/+14
| | | | | | | | | | Right now the atomic request is alive during the renderloop. We want it to be alive until the drm egl context is destroyed because some properties might still be set upon interop close This patch make the request to be kept created even outside the renderloop. The context uninit will commit the last request.
* mpv.desktop: fix French translation consistencyemersion2018-03-181-1/+3
| | | | This makes the French version consistent with the English one.
* cocoa-cb: fix shutdown when fullscreen animation is runningAkemi2018-03-183-8/+21
| | | | | | | | commit 2edf00f changed the MPV_EVENT_SHUTDOWN behaviour slightly, such that it will only be sent once. cocoa-cb relied on it being sent continuously till all mpv_handles are destroyed. now it manually shuts down and destroys the mpv_handle after the animation instead of relying on this removed behaviour.
* 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 OGG files, and then copying the per-stream metadata to the global metadata. Make the heuristic for detecting this slightly more clever, so it works for files with extra, unrelated streams, like the awful libavformat cover art hack. Fixes #5577.
* vo_gpu: error out if there were rendering errors when taking screenshotwm42018-03-031-1/+5
|
* vo_gpu: fix taking screenshots of rotated videoswm42018-03-031-0/+3
| | | | Good old 90° rotation logic messing everything up.
* vd_lavc: fix inverted conditionwm42018-03-031-1/+1
|
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-034-54/+5
| | | | This is new, thus a dependency bump is required.
* demux_lavf: don't mess up in streams with unknown size and init segmentwm42018-03-031-1/+2
| | | | | The return value of stream_get_size() will be -1 if it fails. We shouldn't mess up this value if a mp4 init segment is used.
* player: set thread name in opener threadwm42018-03-031-0/+3
| | | | Somewhat helpful for debugging.
* DOCS/interface-changes: add note about desyncing audio filterswm42018-03-031-0/+2
| | | | For example af_loudnorm is a known filter with this behavior.
* mp_image: make ref error handling slightly readablewm42018-03-031-10/+9
| | | | I think this is slightly more readable than this repeated "fail |= !".
* mp_image: pass through unknown AVFrame side datawm42018-03-032-1/+42
| | | | | | | | | Useful for libavfilter. Somewhat risky, because we can't ensure the consistency of the unknown side data (but this is a general problem with side data, and libavfilter filters will usually get it wrong too _if_ there are conflict cases). Fixes #5569.
* player: add warning comment about ignoring ABI safetywm42018-03-031-0/+3
| | | | | At least ffmpeg_garbage() uses sizeof(AVFrameSideData), which is not included in the ABI, but there's no ABI-safe alternative either.
* mp_image: fix subtle side data memory leakswm42018-03-031-2/+2
| | | | | | We must not create new references herem because mp_image_new_ref() is called later, and actually creates new references (including doing actual error checking). Blame C, not me.
* demux_mkv: enable libavcodec parser for eac3wm42018-03-031-1/+1
| | | | | | | | | | | | | | It appears some (or all) mkv files with EAC3 are muxed in a way that breaks FFmpeg's spdifenc. I suspect it's because either dependent substream packets are localted in their own packets, or the reverse. Or possibly this is case where the muxer did not respect packet boundaries at all. Enabling the EAC3 parser seems to fix this anyway, because why waste your precious time on retarded Dolby bullshit technology? (Which idiot came up with this shitty substream garbage?) Observed with dolby_digital_plus_channel_check_lossless-DWEU.mkv. Fixes #5578.
* README: mention some semi-required FFmpeg dependencieswm42018-03-031-0/+4
| | | | | | | | I think DASH playback tends to work much better with FFmpeg's DASH demuxer, which requires libxml2. For nvdec, FFmpeg git master now requires the external nvidia headers, since the builtin ones were removed.
* demux_edl: fix undefined behavior if mp4 init segment is not providedwm42018-03-031-1/+1
| | | | param_names[n] is only valid for n<nparam.
* cocoa-cb: fix building with SDK 10.12 and earlierAkemi2018-03-011-1/+1
| | | | | | | | | the NSWindowButton enum was moved to be a member of NSWindow and renamed to ButtonType in SDK 10.13. apparently that wasn't documented anywhere. not even in the SDK changes Document and the official Documentations makes it look like it was always like this. the old NSWindowButton enum though is still around on SDK 10.13 or at least got a typealias. so we will just use that.
* build: restore alphabetical sort order of file listswm42018-02-281-71/+71
|
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-2823-288/+1267
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* m_option: remove unneded compatibility featureswm42018-02-282-9/+2
| | | | | Aliases that set old options are not needed anymore. Also extend the total size of the aliases array for one of the following commits.
* vo_gpu: remove a dead declarationwm42018-02-281-1/+0
|
* client API: clarify license, fix some typoswm42018-02-282-3/+4
|
* osdep/atomic: add emulation for atomic_exchange()wm42018-02-281-0/+7
|
* osdep/atomic: fix potential shadowing warningswm42018-02-281-8/+8
| | | | | | | The stdatomic emulation adds "_" to each variable used inside the macros, to avoid that compilers print -Wshadow warnings for identifiers that are also used in surrounding code. Do this more consistently, because new warnings have been showing up.
* cocoa-cb: make fullscreen resize animation duration configurableAkemi2018-02-283-2/+30
|
* cocoa-cb: fix stretched gl surface on window aspect ratio changeAkemi2018-02-282-2/+48
| | | | | | | | when resizing async it's possible that the layer, and the underlying gl surface, is stretched on an aspect ratio change. to prevent that we do an atomic resize (resize and draw at the same time). usually max one unique frame should be dropped but it's possible, depending on the performance, that more are dropped.
* cocoa-cb: change border and borderless window stylingAkemi2018-02-289-20/+158
| | | | | | | | | | | the title bar is now within the window bounds instead of outside. same as QuickTime Player. it supports several standard styles, two dark and two light ones. additionally we have properly rounded corners now and the borderless window also has the proper window shadow. Also make the earliest supported macOS version 10.10. Fixes #4789, #3944
* drm_common: Improve VT switching signal handling somewhatAnton Kindestam2018-02-261-1/+15
| | | | | | | | By blocking the VT switcher signal in the VO thread we get less races and other oddities. This gets rid of tearing (at least for me) when VT switching with --gpu-context=drm.
* vo_drm: Fix pageflip errors on VT switchAnton Kindestam2018-02-261-2/+5
| | | | | | | | crtc_setup gets called on VT reacquire as well as during normal setup. When called during VT reacquire p->front_buf might not be 0, so the maths was wrong, and could cause array OOB errors. Use mathematically correct (for negative numbers) modulo to always pick the farthest away buffer (should work even for larger values of BUF_COUNT).
* context_drm_egl: Repair VT switchingAnton Kindestam2018-02-261-2/+27
| | | | | | | | | | | | | The VT switcher was being set up, but it was being neither polled nor interrupted. Insert wait_events and wakeup functions based on those from vo_drm, and add return early in drm_egl_swap_buffers if p->active isn't set. This should get basic VT switching working, however there will likely still be some random glitches. Switching between mpv and X11/weston is unlikely to work satisfactorily until we can solve the problems with drmSetMaster and drmDropMaster.
* context_drm_egl: Introduce 30bpp supportAnton Kindestam2018-02-264-30/+103
| | | | | | | | | | | | | This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
* egl_helpers: mpegl_cb can now signal an error conditionAnton Kindestam2018-02-262-1/+8
| | | | | This can be used by client code that needs to fail when it cannot find a suitable EGLConfig.
* cocoa-cb: fix wrong fullscreen window sizeAkemi2018-02-252-11/+21
| | | | | | | | | | | | | | | | | | | even though the fullscreen animation has a shorter duration than the system wide animation (space sliding effect) there are still cases where it takes longer, eg performance issues (especially on init). furthermore the final size of the animation is usually different than the actual fullscreen size because of spect ratio differences. the actual resize to fullscreen is done automatically by cocoa itself when the actual transition to fullscreen happens (system event). so it could happen that the last animation resize happened after the actual resize to fullscreen leading to a wrongly sized frame after entering fullscreen. to prevent this we cancel the animation when entering fullscreen, we always set the proper frame size when in fullscreen and discard any other frame sizes, and to prevent some performance problems on init we push entering fullscreen to the end of the main queue to execute it when most of the init routines are done. Fixes #5525
* cocoa-cb: fix wrong drawing size on resizeAkemi2018-02-251-17/+12
| | | | | | on live resize, eg async resize, the layer's bounds size is not in sync with the actual surface size. this led to a wrongly sized frame and a perceived flicker. get and use the actual surface size instead.
* vo_gpu: fix mobius tone mapping when sig_peak <= 1.0Niklas Haas2018-02-251-0/+2
| | | | | | | Mobius isn't well-defined for sig_peak <= 1.0. We can solve this by just soft-clamping sig_peak to 1.0. Although, in this case, we can just skip tone mapping altogether since the limit of mobius as sig_peak -> 1.0 is just a linear function.
* vo_gpu: don't tone-map for pure gamut reductionsNiklas Haas2018-02-251-3/+0
| | | | | | | | | Based on testing with real-world non-HDR BT.2020 clips, clipping the color space looks better than attempting to gamut map using a tone mapping shader that's (by now) optimized for HDR content. If anything, we'd have to develop a separate gamut mapping shader that works in LCh space.
* stream_file: add mode for reading appended fileswm42018-02-212-7/+61
| | | | | | | | | | | | | Do this because retrying reading on higher levels (like the demuxer) usually causes tons of problems. A hack like this is simpler and could allow to remove some of the higher level retry behavior. This works by trying to detect whether the file is appended. If we reach EOF, check if the file size changed compared to the initial value. If it did, it means the file was appended at least once, and we set the p->appending flag. If that flag is set, we simply retry reading more data every time we encounter EOF. The only way to do this is polling, and we poll for at most 10 times, after waiting for 200ms every time.
* audio: improve behavior if filters output nothing during probingwm42018-02-212-1/+9
| | | | | | | | | | Just bail out immediately (and disable audio) if format probing has no result, instead of doing nothing and then apparently freezing. This can happen with bogus filters, cases where the first audio frame is essentially dropped by filters (can happen with large resampling factors), and if the audio track contains no packets at all, or all packets fail to decode.
* cocoa-cb: fix invalid framebuffer operation errorAkemi2018-02-211-1/+5
| | | | | | | | | in certain circumstances the returned fbo for drawing is 0, but that fbo is solely used internally by the CAOpenGLLayer for its drawing and should never be used. in that case we fallback to 1 or the last used fbo instead if it was not 0. Fixes #5546
* drm_vo: pixel aspect from --monitoraspectMarco Migliori2018-02-211-1/+7
| | | | | | | | | | | | | | | | | When pixels are non-square, the appropriate value of vo->monitor_par is necessary to determine the destination rectangle, which in turn tells how to scale the video along the x and y axis. Before this commit, the drm driver only used --monitorpixelaspect. For example, to play a video with the right aspect on a 4:3 screen and 640:400 pixels, --monitorpixelaspect=5:6 had to be given. With this commit, vo->monitor_par is determined from the size of the screen in pixels and the --monitoraspect parameter. The latter is usually easier to determine than --monitorpixelaspect, since it is simply the proportion between the width and the height of the screen, in most cases 16:9 or 4:3. If --monitoraspect is not given, --monitorpixelaspect is used if given, otherwise pixel aspect is assumed 1:1.
* vf_vapoursynth: fix freezewm42018-02-201-5/+7
| | | | | | | Commit 59f9547fb56b missed this case, in which we can't make new progress and have to exit. Fixes #5548.
* vo_gpu: introduce --target-peakNiklas Haas2018-02-204-7/+49
| | | | | | | | | | | | | This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
* vo_gpu: correctly parametrize the HLG OOTF by the display peakNiklas Haas2018-02-201-20/+31
| | | | | | | | | | | | | | The HLG OOTF is defined as a one-parameter family of OOTFs depending on the display's peak luminance. With the preceding change to OOTF scale and handling, we no longer have any issues with outputting values in whatever signal range we need. So as a result, it's easy for us to support a tunable OOTF which may (drastically) alter the display brightness. In fact, this is also the only correct way to do it, because the HLG appearance depends strongly on the OOTF configuration. For the OOTF, we consult the mastering display's tagging (via src.sig_peak). For the inverse OOTF, we consult the output display's target peak.
* vo_gpu: simplify and correct color scale handlingNiklas Haas2018-02-203-33/+40
| | | | | | | | | | | | | | | | | | | | | | | | | The primary need for this change is the fact that the OOTF was incorrectly scaled, due to the fact that the application of the OOTF can itself change the required normalization peak. (Plus, an oversight in pass_inverse_ootf meant we forgot to normalize at the end of it) The linearize/delinearize functions still normalize the scale since it's used in a number of places throughout gpu/video.c, but the color management function now converts to absolute scale right away, instead of in an awkward way inside the tone mapping branch. The OOTF functions now work in absolute scale only. In addition, minor changes have been made to the way normalization is handled for tone mapping - we now divide out the dst_peak *after* peak detection, in order to make the scale of the peak detection buffer consistent even if the dst_peak were to (hypothetically) change mid-stream. In theory, we could also do this for desaturation, but doing the desaturation before tone mapping has the advantage of preserving much more brightness than the other way around - and even mid-stream changes are not that drastic here. Finally, some preparation work has been done for allowing the user to customize the `dst.sig_peak` in the future.
* vo_mediacodec_embed: fix forgotten VO_CAP_NOREDRAW→VO_CAP_NORETAINJan Ekström2018-02-201-1/+1
| | | | Fixes compilation of this module.
* video: fix --video-rotate in some caseswm42018-02-181-1/+1
| | | | Which idiot wrote this code? [Yeah, me.]
* cocoa-cb: fix hwdec when drawing off-screenAkemi2018-02-171-0/+1
| | | | | | | | | drawing off-screen failed because we didn't have a valid context. the problem is we force off-screen drawing because the CAOpenGLLayer refuses to draw anything while being off-screen. set the current context before starting to draw anything off-screen. Fixes #5530
* video: do not buffer extra frames with VO_CAP_NORETAIN outputsAman Gupta2018-02-171-0/+3
| | | | | | | | | | | | | | This fixes playback stalls on some mediacodec hardware decoders, which expect that frame buffers will be rendered and returned back to the decoder as soon as possible. Specifically, the issue was observed on an NVidia SHIELD Android TV, only when playing an H264 sample which switched between interlaced and non-interlaced frames. On an interlacing change, the decoder expects all outstanding frames would be returned to it before it would emit any new frames. Since a single extra frame always remained buffered by mpv, playback would stall. After this commit, no extra frames are buffered by mpv when using vo_mediacodec_embed.
* video: rename VO_CAP_NOREDRAW to VO_CAP_NORETAINAman Gupta2018-02-172-4/+4
|
* vo_gpu: hwdec_drmprime_drm: cosmetic simplificationwm42018-02-161-6/+3
| | | | | | Coverity complained about the redundant init of hratio etc. - just remove that and merge declaration/init of these variables. Also the first double cast in each expression is unnecessary.
* filter: fix potential NULL pointer derefwm42018-02-161-1/+1
| | | | | | The rest of the function should be executed only if both are set. It seems like in practice this didn't happen yet with only one of them unset, but in theory it's possible. Found by Coverity.
* command: simplify mp_property_filter_metadatawm42018-02-161-19/+11
| | | | Also silence a dead code coverity error.
* github: recommend 0x0.st rather than sprunge.us for logfilesKevin Mitchell2018-02-161-1/+1
| | | | The latter seems to give 500 errors more often than not these days.
* build: fix dependency check on macOSAkemi2018-02-162-9/+8
| | | | | | | 235eb60 added a needed linking flag, but too soon. this lead to some of the configure checks to fail. add the flag in our build phase. Fixes #5528
* cocoa-cb: fix drawing on macOS 10.11Akemi2018-02-161-3/+19
| | | | | | | | | the CVDisplayLinkSetOutputHandler function introduced with 10.11 is broken on the very same version of the OS, which caused our render loop never to start. fallback to the old display link callback on 10.11. for reference the radar http://www.openradar.me/26640780 Fixes #5527
* build: fix linking libmpv when swift features are builtAkemi2018-02-132-0/+3
| | | | | | | | the swift object file wasn't linked when libmpv was linked, which resulted in a missing symbol error. add the swift object to the linking list for libmpv too. Fixes #5522
* build: remove shell usage from swift build scriptsAkemi2018-02-131-4/+5
| | | | | | | for convenience reasons i used strings for subprocess commands instead of command lists, which made it mandatory to use a shell. for security reasons, among others, we removed the shell usage and converted the commands to actual command lists.
* build: fix swift detection with python2Akemi2018-02-131-6/+2
| | | | | | | | | c82fed8 fixed the detection with python3 but broke it on python2. the decode function on python2 converts the str to unicode which causes problems when concatenating to str when building. instead of decoding the output we change the subprocess to operate in text mode. also use check_output instead of Popen for simplicity.
* lua+js: Implement utils.getpid()sfan52018-02-135-0/+51
| | | | | | | Usable for uniquely identifying mpv instances from subprocesses, controlling mpv with AppleScript, ... Adds a new mp_getpid() wrapper for cross-platform reasons.
* vo_gpu: remove old window screenshot glue code and GL implementationwm42018-02-134-42/+0
| | | | | | | | | | | There is now a better way. Reading the font framebuffer was always a hack. The new code via VOCTRL_SCREENSHOT renders it into a FBO, which does not come with the disadvantages of reading the front buffer (like not being supported by GLES, possibly black regions due to overlapping windows on some systems). For now keep VOCTRL_SCREENSHOT_WIN on the VO level, because there are still some lesser VOs and backends that use it.
* f_lavfi: extend filter help outputwm42018-02-131-1/+41
| | | | | | Also print type and help string. Also print AV_OPT_TYPE_CONST, which are like the mpv choice option type, except different. Print them as separate lines because FFmpeg usually has help strings for them too.
* options: minor cleanup to --no-... handlingwm42018-02-133-7/+14
| | | | | | | | Most options starting with --no-<name> are automatically translated to --<name>=no. Make the code slightly nicer by using a flag instead of explicitly comparing option types. Also fix an issue that made the option parser print nonsense error messages for if --no-... was used for options which don't support it.
* options: prefix option with "--" in one case in help outputwm42018-02-131-1/+1
|
* vo: make opengl-cb first in the autoprobing orderwm42018-02-134-5/+12
| | | | | | | This should be helpful for the new OSX Cocoa backend, which uses opengl-cb internally. Since it comes with a behavior change that could possibly interfere with libmpv/opengl_cb users, we mark it as explicit API change.
* Fix recent FFmpeg deprecationswm42018-02-137-56/+56
| | | | | | | | | This includes codec/muxer/demuxer iteration (different iteration function, registration functions deprecated), and the renaming of AVFormatContext.filename to url (plus making it a malloced string). Libav doesn't have the new API yet, so it will break. I hope they will add the new APIs too.
* filter: extend documentation commentswm42018-02-131-6/+43
| | | | Add more explanations, and also fix some blatantly wrong things.
* filter: simplify/fix external filter graph usagewm42018-02-131-34/+37
| | | | | | | | | | | | | | | | There was the following problem: if a filter graph had asynchronous filters, and the filter graph user did not call mp_filter_run() (and only accessed the mp_pins), then filtering could stall, because using mp_pin_out_request_data() only recursively invoked filtering if the data_requested flag wasn't already set. The latter can happen if a request was tried earlier but failed, and then an asynchronous filter actually produced output that would satisfy the request. Obviously, it has to invoke filtering again to get the requested frame. Fix this by organizing the code differently, and making sure to invoke mp_filter_run() on every request (if there's nothing to do, it doesn't do anything anyway). Simplify it a bit by removing things which are not needed, like connecting filter graphs with different root filters.
* audio: don't touch spdif frames in mp_aframe_clip_timestamps()wm42018-02-131-0/+3
| | | | It can't work for this type of format.
* f_lavfi: fix typo in commentwm42018-02-131-1/+1
|
* demux: lower demuxer cache default sizeswm42018-02-131-2/+2
| | | | | | | | | Reduce backward/forward from 400MB/400MB to 50MB/150MB. Too many complaints about high memory usage. Note that external tracks (like ytdl DASH with external audio tracks) will double the amounts, because an external track uses its own demuxer and cache.
* filter: adjust root log prefixwm42018-02-131-2/+3
| | | | | | | | | | Avoids that the audio decoder shows up with a "[root/ad]" log prefix. This is an annoying consequence of mp_log_new(): if a log parent doesn't have a prefix with "!", it'll add the prefix to all mp_logs created from it. This should probably be fixed in the mp_log code itself, but doing so would be a big deal as we'd have to make sure all the other log prefixes are what we want. So work it around for now.
* vf_vavpp: select best quality deinterlacing algorithm by defaultwm42018-02-133-6/+28
| | | | | | | | This switches the default away from "bob" to the best algorithm reported as supported by the driver. This is convenient for users, and there is no reason to use something worse by default. Untested.
* manpage: remove mention of --vf=eqwm42018-02-131-1/+1
| | | | This doesn't work anymore.
* input: add a keybinding to toggle hardware decodingwm42018-02-133-0/+5
| | | | | We sure as hell won't enable hardware decoding by default, but we can make it more accessible with a key binding.
* video: make --deinterlace and HW deinterlace filters always deinterlacewm42018-02-137-8/+13
| | | | | | | | | | | | | | | | Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
* build: drop support for SDL1wm42018-02-133-8/+1
| | | | | For some reason it was supported for ao_sdl because we've only used SDL1 API.
* audio: move back PTS jump detection to before filter chainwm42018-02-134-21/+20
| | | | | | | | | | | The recent changes to player/audio.c moved PTS jump detection to after audio filtering. This was mostly done for convenience, because dataflow between decoder and filters was made "automatic", and jump detection would have to be done as filter. Now move it back to after decoders, again out of convenience. The future direction is to make the dataflow between filters and AO automatic, so this is a bit in the way. Another reason is that speed changes tend to cause jumps - these are legitimate, but get annoying quickly.
* DOCS/interface-changes.rst: fix typowm42018-02-131-1/+1
|
* vo_gpu: d3d11: implement tex_download()James Ross-Gowan2018-02-135-102/+57
| | | | | | | This allows the new GPU screenshot functionality introduced in 9f595f3a80ee to work with the D3D11 backend. It replaces the old window screenshot functionality, which was shared between D3D11 and ANGLE. The old code can be removed, since it's not needed by ANGLE anymore either.
* vo_gpu: use a variable for the RA_CAP_FRAGCOORD flagJames Ross-Gowan2018-02-131-4/+3
| | | | | This is just a cosmetic change. Now the RA_CAP_FRAGCOORD check looks like all the others.
* vo_gpu: check for HDR peak detection in dumb mode tooJames Ross-Gowan2018-02-131-7/+8
| | | | | | | | Similar spirit to edb4970ca8b9. check_gl_features() has a confusing early-return. This also adds compute_hdr_peak to the list of options that is copied to the dumb-mode options struct, since it seems to make a difference. Otherwise it would be impossible to disable HDR peak detection in dumb mode.
* build: fix swift detection on major swift versionsAkemi2018-02-121-2/+2
| | | | | the swift version string on major versions only has two components, major and minor, the third one is missing.
* build: fix swift detection with python3Akemi2018-02-121-1/+1
| | | | | python3 returns bytes instead of str, unlike python2. explicitly decode the output.
* build: fix configure on windowsAkemi2018-02-121-7/+8
| | | | | configure failed because of a wrong check. fix the check and also only check for swift on macOS.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-1223-82/+2054
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* build: fix linking to dev SDK on macOSAkemi2018-02-121-1/+21
| | | | | | | | | on macOS mpv was linked to the system SDK which didn't cause any problems as long as the system SDK was the same as the dev SDK. though it started to cause linking warnings when a new xcode version with the SDK for the next macOS was installed. in the worst case it could also cause linking errors. to fix this we explicitly set the SDK path to the SDK that is used for building instead.
* osx: always deactivate the early opengl flush on macOSAkemi2018-02-122-2/+9
| | | | | | | | | | | early flushing only caused problems on macOS, which includes: - performance problems and huge amount of dropped frames - problems with playing back video files with fps close to the display refresh rate - rendering at twice the rate of the video fps - not properly detected display refresh rate we always deactivate any early flush for macOS to fix these problems.
* ytdl_hook: add ytdl:// prefix again for non-youtube playlistsRicardo Constantino2018-02-111-2/+6
| | | | | | | | Only youtube playlists return ID-only urls. Other extractors may return "<extractor>:<ID>" so those still need the ytdl:// prefix. Reproduced with http://www.cbc.ca/burdenoftruth/videos/trailers-promos/burden-of-truth-returns
* ytdl_hook: add script opt for using manifest URLsRicardo Constantino2018-02-112-2/+7
| | | | | | | | | | | Disable by default. This feature was added in 7eb342757, which allowed stream selection in runtime. Problem with this atm is that FFmpeg will try to demux every first packet of every track leading to noticeable delay opening the URL. This option can be changed to enabled by default or removed when HLS/DASH demuxers are improved upstream.
* ytdl_hook: parse youtube playlist urls to set start indexRicardo Constantino2018-02-111-5/+53
| | | | | | | | | | | | | | Still needs `--ytdl-raw-option=yes-playlist=` because this only works for youtube. This was requested in a few issues: https://github.com/mpv-player/mpv/issues/1400 https://github.com/mpv-player/mpv/issues/2592 https://github.com/mpv-player/mpv/issues/3024 For #1400 to be completely implemented would need ytdl_hook to re-request the same playlist with the last video's ID for the mix to continue indefinitely which would probably too hackish to work reliably.
* ytdl_hook: exit early, save an indentation levelRicardo Constantino2018-02-111-164/+165
|
* ytdl_hook: various nitRicardo Constantino2018-02-111-9/+5
| | | | | | | | Remove obsolete comment about FFmpeg ignoring non-http proxies which was repeated in ytdl_hook before the feature was added. Remove unnecessary conditions for not nil. Lua tables will always return nil for non-existent keys.
* ytdl_hook: whitelist subtitle URLs as wellRicardo Constantino2018-02-111-2/+4
| | | | | This was overlooked when doing the whitelisting for video and audio to fix #5456.
* ytdl_hook: use fallback if there's no demuxer-lavf-list propRicardo Constantino2018-02-111-3/+3
| | | | | | | This is important if backporting by grabbing the latest version of the script without backporting the commit that added the property: 828bd2963cd10a851e0a977809687aed4d377dc3
* appveyor: trigger build on pushing to 'ci'Kevin Mitchell2018-02-111-0/+1
| | | | | This way, both travis and appveyor can be manually triggered simultaneously.
* vo_drm: support --monitorpixelaspectMarco Migliori2018-02-111-0/+2
| | | | | | | | | | This commit allows for video to be shown with the right aspect even when pixels are not square in the selected drm mode. For example, if drm mode 5 is "640x400", the right aspect on a 4:3 monitor is obtained by mpv --vo=drm --drm-mode=5 --monitorpixelaspect=5:6 ... Other vo's seem to make this parameter change the size of the window, but in the drm vo this is fixed, being as large as the screen.
* vo_drm: reset last input image on reconfigMarco Migliori2018-02-111-0/+3
| | | | | | | | | | | | | | | | | | The last image is stored in vo->priv->last_input to be used when redrawing a frame is necessary (control: VOCTRL_REDRAW_FRAME). At the beginning it is NULL, so a redraw request has no effect since draw_image ignores calls with image=NULL. When using --force-window the size of the image may change without the vo structure being re-created. Before this commit, the size of vo->priv->last_input could become inconsistent with the cropping rectangle vo->priv->src_rc, which could trigger an assert in mp_image_crop_rc(). Even if it did not, the last image of a video remained on the screen when the next file in the playlist had no video (e.g., it was an mp3 without an embedded cover). This commit deallocates and resets to NULL the image vo->priv->last_input when reconfiguring video.
* vo_drm: make the osd as large as the screenMarco Migliori2018-02-111-18/+18
| | | | | | | | | | | | | | | | | | | | Before this commit, the drm vo drew the osd over the scaled image, and then copied the result onto the framebuffer, shifted. This made the frame centered, but forced the osd to be only as large as the image. This was inconsistent with other vo's, covered the image with the progress indicator even when a black band was at the top of the screen, made the progress indicator wrap on narrow videos, etc. The change is to always use an image as large as the screen. The frame is copied scaled and shifted to it, and the osd drawn over it. The result is finally copied to the framebuffer without any shift, since it is already as large as it. Technically, cur_frame is an image as large as the screen and cur_frame_cropped is a dummy reference to it, cropped to the size of the scaled video. This way, copying the scaled image to cur_frame_cropped positions the image in the right place in cur_frame, which can then have the osd added to it and copied to the framebuffer.
* vo_gpu: make screenshots use the GL rendererwm42018-02-1116-33/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
* vo_gpu: add internal ability to skip osd/subs for renderingwm42018-02-115-18/+40
| | | | Needed for the following commit.
* vo_gpu: use blit() only if target ra_tex supports itwm42018-02-111-2/+3
| | | | | Even if RA_CAP_BLIT is set, this might just not be enabled for the target ra_tex.
* vo_gpu: add memory barrier on the HDR peak detectionNiklas Haas2018-02-111-0/+1
| | | | | This can cause the peak detection state to be inconsistent in rare cases, which might explain the issues when taking screenshots in #5499.
* vo_gpu: correctly infer HDR peak detection supportNiklas Haas2018-02-111-1/+4
| | | | | | The re-ordering of commits e3d93fd and 0870859 ended up swallowing the change which made the HDR tone mapping algorithm actually check for RA_CAP_NUM_GROUPS support.
* vo_gpu: refactor HDR peak detection algorithmNiklas Haas2018-02-113-16/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The major changes are as follows: 1. Use `uint32_t` instead of `unsigned int` for the SSBO size calculation. This doesn't really matter, since a too-big buffer will still work just fine, but since `uint` is a 32-bit integer by definition this is the correct way to do it. 2. Pre-divide the frame_sum by the num_wg immediately at the end of a frame. This change was made to prevent overflow. At 4K screen size, this code is currently already very at risk of overflow, especially once I started playing with longer averaging sizes. Pre-dividing this out makes it just about fit into 32-bit even for worst-case PQ content. (It's technically also faster and easier this way, so I should have done it to begin with). Rename `frame_sum` to `frame_avg` to clearly signal the change in semantics. 3. Implement a scene transition detection algorithm. This basically compares the current frame's average brightness against the (averaged) value of the past frames. If it exceeds a threshold, which I experimentally configured, we reset the peak detection SSBO's state immediately - so that it just contains the current frame. This prevents annoying "eye adaptation"-like effects on scene transitions. 4. As a result of the previous change, we can now use a much larger buffer size by default, which results in a more stable and less flickery result. I experimented with values between 20 and 256 and settled on the new value of 64. (I also switched to a power-of-2 array size, because I like powers of two)
* appveyor: use undocumented --ask to force yes for all questionsRicardo Constantino2018-02-111-3/+3
| | | | Also, remove progressbar, just spammy for reason.
* player: correctly set track information on adding external filesZehua Chen2018-02-103-34/+44
| | | | | | | | Before this commit, auto_loaded and lang were only set for the first track in auto-loaded external files. Likewise, for the title and lang arguments to the sub-add and audio-add commands. Fixes #5432
* wayland_common: fix idle_inhibitor protocol segfaultRostislav Pehlivanov2018-02-091-0/+1
| | | | The pointer is used as a state and wasn't zeroed after seeks.
* drmprime interop : Add frames triple bufferingLongChair2018-02-071-3/+8
| | | | | | | | | | | | | | | | | Currently using the drmprime interop with external mpv intgration can lead to rendering issues because the current frame is being released too early. Typically using this with Qt results in one frame shift because Qt will do waitforvsync and swap, rather than swap and waitforvsync. This leads to tearing as the frambuffer is released while being displayed on screen. In order to avoid releasing the framebuffer that is displayed, We keep the framebuffer alive for one more frame with triple buffering to make sure that whatever rendering process is used, the framebuffer will not be released when it's still on screen. This was tested on RockChip Rock64
* vd_lavc: fix stall with some uses of --hwdec=copywm42018-02-051-3/+6
| | | | | | | | | | | Also a regression of the filter change. The new code is more picky about EOF states, and it turns out the weird delay queue (used with some hwdec copy back modes only) accidentally dropped an EOF event. It reset the avctx before the delay queue was drained, which meant it never returned the expected AVERROR_EOF status code. Also don't signal EOF when copy back fails. It should just try to continue until fallback is performed.
* vo_gpu: port HDR tone mapping algorithm from libplaceboNiklas Haas2018-02-054-81/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
* vo_gpu: add RA_CAP for gl_NumWorkGroupsNiklas Haas2018-02-053-1/+3
| | | | | SPIRV-Cross doesn't support this for the time being. It's possible this could go away again at a later date.
* vo_gpu: vulkan: correctly enable textureGatherOffsetNiklas Haas2018-02-052-2/+3
| | | | This also requires a vulkan feature / SPIR-V capability to function
* vo_gpu: vulkan: don't issue queries for unused timersNiklas Haas2018-02-051-5/+13
| | | | | | | The vulkan validation layers warn you if you try requesting a query result from a timer that hasn't even been started yet, so we have to do some extra bit of work to keep track of which indices we've seen so far, and avoid the queries on them.
* vo_gpu: vulkan: try enabling required featuresNiklas Haas2018-02-052-0/+10
| | | | | | | Instead of enabling every feature under the sun, make an effort to just whitelist the ones we actually might use. Turns out the extended storage format support is needed for some of the storage formats we use, in particular rgba16.
* vo_gpu: vulkan: add missing buffer barrier fieldsNiklas Haas2018-02-051-0/+2
| | | | These were accidentally omitted.
* f_decoder_wrapper: fix log message incorrect for audiowm42018-02-051-1/+1
| | | | | This code is used by both video and audio, so the text should not talk about video.
* f_demux_in: give it a slightly better filter namewm42018-02-051-1/+1
| | | | Matters for logging.
* filter: don't randomly lose async wakeup notificationswm42018-02-051-5/+4
| | | | | | | | | | | | Another "what was I thinking" thing - destroying filters explicitly skipped async wakeups for no reason. These were notifications for filters that are not going to be destroyed too, and so their wakeup will be lost, leading to stalled playback. This is completely unnecessary and the special code can be removed. Fixes #5488. (This case destroyed all audio filters due to AO init failure, which could make clear out the f_demux_in.c wakeup for video, and "freeze" playback.)
* vd_lavc: fix recently broken hardware decode fallbackwm42018-02-041-7/+16
| | | | | | | | | This is a dataflow issue caused by the filters change. When the fallback happens, vd_lavc does not return a frame, but also does not accept a new packet, which confuses lavc_process(). Fix this by immediately retrying to feed the buffered packet and decode a frame on fallback. Fixes #5489.
* vf_vapoursynth: always keep input frame array filledwm42018-02-031-1/+3
| | | | | | | | In theory (and practice), this is not needed, because the VS filter get frame callback will cause the process function to be called again if there's not enough data. But it's still a bit weird to just add one more frame on each iteration, so make it cleaner and make it request frames until the input array is full.
* vf_vapoursynth: fix lockingwm42018-02-031-1/+2
| | | | | | | | This was obviously nonsense, and a previous "fix" to this code was nonsense too. What is really needed here is temporarily dropping the lock while calling destroy_vs()/reinit_vs(). Fixes #5470.
* tests: stop comparing floats against DBL_EPSILON, use FLT_EPSILONIlya Tumaykin2018-02-032-6/+7
| | | | Fixes #5253.
* swresample: minor simplificationwm42018-02-031-7/+6
| | | | Cosmetic and no change in behavior. At least I think this looks simpler.
* swresample: remove unnecessary request for new inputwm42018-02-031-1/+2
| | | | | | | | | | | We called mp_pin_out_request_data() if there was input _and_ output. This is not how it should be: we should request new input only if output was requested, but we could not produce any output. On the other hand, the upper half of the process() function will request new input if output is required, but all input was consumed. But this requires calling mp_filter_internal_mark_progress(), as otherwise the general filter logic would not know that we can continue.
* swresample: actually reinit resampler on large speed changeswm42018-02-031-5/+13
| | | | | | | | | | | | | | | | | | | If the speed is changed by a large amount, we need to effectively change the output rate by a large amount, and swr_set_compensation() is apparently not designed to handle such large changes well. So it's better to reinitialize the resampler on all large changes. Also, strictly reinitialize the resampler if the rate changes, otherwise it could happen that libavresample (which does not automatically initialize resampling if avresample_set_compensation() is used) would never apply speed changes properly. Also document some conditions better that handle corner cases (remove the inline condition from the if gating the compensation code). It also appears that we crashed with very large compensation ratios (when raising audio speed quickly by keeping the "[" key down), and this commit accidentally mitigates it by not allowing large compensation.
* loadfile: make --lavfi-complex runtime changes more flexiblewm42018-02-031-18/+27
| | | | | | | | | Setting lavfi-complex at runtime will now forcefully reselect the tracks as needed, even if it was a "proper" track selection via --aid or --vid. Before this commit, it just failed and complained that the VO/AO was already "used". Requested.
* loadfile: initialize decoders after outputs for --lavfi-complexwm42018-02-031-37/+31
| | | | | | | This makes it actually somewhat simpler, and doesn't have any disadvantages. It should also make some new features easier. Mostly just moves code around.
* loadfile: fix crash in some cases of setting --lavfi-complex at runtimewm42018-02-031-1/+1
| | | | | | | | | The somewhat confusing thing is that many filters (including track->dec) have a public struct, but to free them, you need to free the mp_filter pointer itself (track->dec->f). The assignment wrote to a dangling pointer, instead of removing the dangling pointer. (Other than that, this idiom is actually nice.)
* loadfile: remove minor unneeded things from --lavfi-complex setupwm42018-02-031-3/+1
|
* f_output_chain: remove unused got_input_eof fieldwm42018-02-032-4/+1
| | | | Was used by the player code before decoders were moved to filters.
* vf_vapoursynth: fix obscure/impossible leakwm42018-02-031-0/+1
| | | | | | | Unknown frames were not freed properly. Although this doesn't really happen anyway, because we're never going to feed audio frames to a video filter chain. Since it's theoretically possible, and all other filters handle this consistently, fix it anyway.
* vf_vapoursynth: fix output colorspace flags and other attributeswm42018-02-031-0/+2
| | | | | | | Properly initialize the output frame parameters other than image format and size. This includes colorspace hints. (We're still not reading them back from VapourSynth if it sets them, though. Usually it doesn't anyway.)
* vf_vapoursynth: fix potential deadlock on init failurewm42018-02-031-1/+1
| | | | | When VS initialization failed, it could hang due to forgetting to release the mutex.
* vf_vapoursynth: initialize start timestamp properlywm42018-02-031-1/+1
| | | | | | | | | VapourSynth can't pass through timestamps, only frame durations. So we need to remember the timestamp of the very first frame passed to it. This was accidentally set to 0 instead of NOPTS on init, so inserting the filter during playback could show strange behavior. Might be part of #5470.
* f_utils: fix leak in frame duration filterwm42018-02-031-0/+1
| | | | | vf_vapoursynth used this. Could cause a crash at VO uninit, if the leaked frame was allocated via VO DR.
* video: fix passing down FPS to vf_vapoursynthwm42018-02-033-11/+11
| | | | | | | To make this less of a mess, remove one of the redundant container_fps fields. Part of #5470.
* swresample: limit output size of audio frameswm42018-02-033-35/+67
| | | | | | | | | | | | | | Similar to the previous commit, and for the same reasons. Unlike with af_scaletempo, resampling does not have a natural frame size, so we set an arbitrary size limit on output frames. We add a new option to control this size, although I'm not sure whether anyone will use it, so mark it for testing only. Note that we go through some effort to avoid buffering data in libswresample itself. One reason is that we might have to reinitialize the resampler completely when changing speed, which drops the buffered data. Another is that I'm not sure whether the resampler will do the right thing when applying dynamic speed changes.
* af_scaletempo: output minimally sized audio framewm42018-02-031-57/+76
| | | | | | | | | | | | | | | | | | | | This helps the filter to adapt much faster to speed changes. Before this commit, the filter just converted and output the full input frame, which could cause problems with large input frames. This was made worse by certain filters like dynaudnorm or loudnorm outputting pretty large frames. This commit changes the filter from trying to convert all input at once to only outputting a single internally filtered frame. Internally, this filter already output data in units of 60ms by default (controlled by the "stride" sub-option), and concatenated as many output frames as necessary to consume all input. Behavior is still kind of bad when inserting the filter. This is because the large frames can be buffered up after the insertion point, so the speed change will be performed with a larger latency. The scaletempo filter can't do anything against this, although it can be fixed by inserting scaletempo as user filter as part of --af.
* filter: add/use a convenience functionwm42018-02-033-2/+12
| | | | | I guess this is generally useful for filters which buffer data internally.
* options: slightly improve filter help output for lavfi bridgewm42018-02-036-10/+97
| | | | | | | | | | | | | | --vf=help will now list libavfilter filters, and e.g. --vf=yadif=help will list libavfilter filter options. The latter is rather bare, because the AVOption API is really awful (holy shit how is it so bad), and would require us to handle _every_ option type manually. Alternatively we could call av_opt_show2(), which ffmpeg uses for help output in its CLI tools and which is much more detailed. But it's rather foreign and forces output through av_log(), so I don't really want to use it.
* options: pretty print default values with --list-optionswm42018-02-011-1/+1
|
* codecs: remove unused family fieldwm42018-02-016-20/+8
| | | | | | | | | | MPlayer used this to distinguish multiple decoder wrappers (such as libavcodec vs. binary codec loader vs. builtin decoders). It lost meaning in mpv as non-libavcodec things were dropped. Now it doesn't serve any purpose anymore. Parsing was removed quite a while ago, and the recent filter change removed any use of the internal family field. Get rid of it.
* manpage: clarify some --vf optionswm42018-01-312-16/+28
| | | | In particular, mention deprecated things.
* Revert "demux_mkv: remove remaining GPL code"wm42018-01-311-1/+4
| | | | | | | | This reverts commit b7f90be567c3c19eb3fec30be2b76775296a6ed1. The author agreed to the relicensing now (if that code is affected by the original copyright at all - that was the only line possibly left of it).
* Copyright: fix missing wordwm42018-01-311-1/+1
|
* cue: strip quotes and leading whitespace from tagswm42018-01-301-2/+10
| | | | | | | | If tags like TITLE have the whole parameter in " quotes, strip them. Also remove the leading whitespace, since even with a single space it was always included. Fixes #5462.
* ytdl_hook: pass http proxy to ffmpegRicardo Constantino2018-01-302-15/+35
| | | | | | | | | | | | | | FFmpeg only suppports http proxies and ignores it if the resulting url is https. Also, no SOCKS. Use it like `--ytdl-raw-options=proxy=[http://127.0.0.1:3128]` so it doesn't confuse mpv because of the colons. You need to pass it as an option because youtube-dl doesn't give us the proxy. Or just set `http_proxy` environment variable as recommended before. Added example using -append, which doesn't need escaping.
* input.conf: use exact value for [ bindingwm42018-01-301-1/+1
| | | | | | This is supposed to undo the ] binding. This uses a value closer to the inverse. (Although it's not fully exact since the values are still stored as floating point instead as fractions.)
* audio: move to decoder wrapperwm42018-01-3018-797/+330
| | | | | | | | | | | | | | | | Use the decoder wrapper that was introduced for video. This removes all code duplication the old audio decoder wrapper had with the video code. (The audio wrapper was copy pasted from the video one over a decade ago, and has been kept in sync ever since by the power of copy&paste. Since the original copy&paste was possibly done by someone who did not answer to the LGPL relicensing, this should also remove all doubts about whether any of this code is left, since we now completely remove any code that could possibly have been based on it.) There is some complication with spdif handling, and a minor behavior change (it will restrict the list of codecs to spdif if spdif is to be used), but there should not be any difference in practice.
* ao_null: add --ao-null-format option for debuggingwm42018-01-302-0/+8
| | | | Helpful especially to test spdif fallback and so on.
* video: make decoder wrapper a filterwm42018-01-3026-1040/+1094
| | | | | | | | | | | | | | | | | | | | | | | | | Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
* demux: add a per stream wakeup callbackwm42018-01-302-13/+56
| | | | | | | | | | This is supposed to help making data flow easier and wakeup handling more efficient. Once that change is done, reading a packet on any stream won't have to wakeup and poll all decoders (which helps reducing the mess even if all decoders are on the same thread). This also improves the accuracy of wakeups by tracking better whether a wakeup is needed.
* mp_image: preserve AVFrame closed captions datawm42018-01-302-0/+8
| | | | | | | | | | This is preparation for a change in vd_lavc.c: it should not have to access the demuxer (to pass along closed captions), so the idea is to make them part of mp_image, and to let the layer above vd_lavc propagate the buffer. Don't bother with preserving them for mp_image->AVFrame, because we don't need this.
* mp_image: factor buffer referencingwm42018-01-301-17/+15
| | | | | | | | | | | Reduce the trivial but still annoying code duplication in mp_image_new_ref(), which has to create new buffer references and deal with possible failure of creating them. The tricky part is that if creating a reference fails, we must set the target to NULL, so that unreferencing the failed new mp_image reference does not release the buffer references of the original mp_image. For the same reason, the code can't jump to error handling when it can't create a new reference, and has to set a flag instead.
* player: replace old lavfi wrapper with new filter codewm42018-01-309-909/+108
| | | | | lavfi.c is not necessary anymore, because f_lavfi.c (which was actually converted from it) can be used now.
* audio: rewrite filtering glue codewm42018-01-3039-3758/+2483
| | | | Use the new filtering code for audio too.
* video: rewrite filtering glue codewm42018-01-3056-2864/+5887
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* vo_gpu: check for RA_CAP_FRAGCOORD in dumb mode tooJames Ross-Gowan2018-01-301-13/+14
| | | | | | | The RA_CAP_FRAGCOORD checks apply to dumb mode as well, but they were after the check for dumb mode, which returns early, so they never ran. Fixes #5436
* ytdl_hook: pre-append id-only playlist items with shortened youtube URLRicardo Constantino2018-01-291-1/+1
|
* ytdl_hook: whitelist segmented DASH and HLS for the manifests codeRicardo Constantino2018-01-271-7/+9
| | | | Close #5453
* video: fix crash with vdpau when reinitializing renderingwm42018-01-271-3/+3
| | | | | | | | | | Using vdpau will allocate additional textures for the reinterleaving step, which uninit_rendering() will free. This is a problem because the hwdec image remains mapped when reinitializing, so the reinterleaving textures are turned into dangling pointers. Fix this by freeing the reinterleave textures on full uninit instead. Fixes #5447.
* demux_lavf: work around another aspect of libavformat garbage APIwm42018-01-261-1/+6
| | | | | | | | | | | | | | | | AV_DISPOSITION_ATTACHED_PIC usually means the video track isn't real, and merely reflects the presence of an embedded image in tag data (such as ID3v2 tags), with some inconsistent hack to make libavformat return it as video packet once. Except it doesn't mean that. It can be randomly set on other streams that do sort of behave like video streams, such as chapter thumbnail tracks in mp4 files. AV_DISPOSITION_TIMED_THUMBNAILS is set in these cases. In theory, there can supposedly be more such cases, but only the chapter thumbnail one currently exists. So add it as exception. This restores displaying these thumbnails as video frames, for better or worse. (Before, only the first thumbnail was displayed.)
* demux_lavf: export correct seekability state for HLS live streamswm42018-01-261-0/+5
| | | | | | | Requires newest FFmpeg git, which has a change that makes the HLS demuxer set an AVFMTCTX_UNSEEKABLE flag if seeking is not available, which is the case for HLS live streams. This should make the player frontend behave pretty well, instead of crapping up irrecoverably.
* command: add --osd-on-seek option defaulting to barKevin Mitchell2018-01-265-11/+30
| | | | | | | | | | | | | Restores behaviour prior to aef2ed5dc13e37dec0670c451b4369b151d5c65f. That change was apparently unpopular. However, given the amount of complaining over how hard it is to change the defaults by rebinding every key, I think the extra option introduced by this commit is justified. Technically not all behaviour is restored, because now --no-osd-bar will not instead display the msg text on seek. I think that feature was a little weird and is now easy enough to remedy with the --osd-on-seek option.
* Revert "command: make pause display the same osd-msg-bar as seek"Kevin Mitchell2018-01-262-6/+4
| | | | | | | | | | | | | | This reverts commit 9812e276aa1bb0bddeb73677aa9e9f87e73cd930. This was apparently unpopular. I still think the pause OSD should be the same as seek even if it's not visible by default, but it seems that whether to display a given property change is currently conflated with what to display. The reverted behaviour can be restored by adding something like the following to input.conf: SPACE cycle pause; show_progress
* ytdl_hook: prefer hls/dash manifest if availableRicardo Constantino2018-01-261-6/+10
| | | | | | | This makes all the video/audio variants available for selection. Might break with non-hls/dash, or even with dash if FFmpeg wasn't compiled with the demuxer.
* ytdl_hook: fix safe url checking with EDL urlsRicardo Constantino2018-01-261-11/+11
|
* ytdl_hook: move url_is_safe earlier in codeRicardo Constantino2018-01-261-9/+9
| | | | lua isn't javascript.
* hwdec: detach d3d and d3d9 hwaccel from anglemyfreeer2018-01-253-9/+10
| | | | Fix https://github.com/mpv-player/mpv/issues/5420
* stream_lavf: remove deprecated hls protocol from whitelistwm42018-01-251-1/+1
| | | | | | The use of the FFmpeg hls protocol (as opposed to demuxer) is "discouraged", and probably only causes additional potential security problems at best, so drop it.
* manpage: mention --network-timeout is broken with RTSPwm42018-01-251-0/+10
| | | | | | Not much we can do, too hard to work around. Fixes #3361.
* options: add string list -toggle actionwm42018-01-252-0/+25
|
* m_option: remove string list -append action code duplicationwm42018-01-251-15/+6
| | | | | | | | Instead of duplicating the append code, reimplement it using the existing code. The difference between -add and -append is that -append does not take multiple items (thus removing the need for escaping), but -append can reuse all code for -add by pretending the separator is never found.
* command: make change-list show changed option on OSDwm42018-01-251-0/+1
|
* command: add a change-list commandwm42018-01-255-0/+53
| | | | | | | | | | | | | Requested. See manpage additions. The main reason why this goes through the trouble to keep the action/operation parameter separate is so that we don't expose some option parser implementation details to the command (although that is a relatively weak reason), and also to make it more different from the "set" command, which can't support this type of option as it goes through the property layer. Fixes #5435.
* client API: be more explicit about what can be done in wakeup callbackswm42018-01-252-6/+15
| | | | Don't leave any room for interpretation.
* options: add an option type for byte sizeswm42018-01-255-25/+108
| | | | | | And use it for 2 demuxer options. It could be used for more options later. (Though the --cache options can not use this, because they use KB as base unit.)
* m_option: add missing print callbackswm42018-01-251-5/+35
| | | | | | | | | | | Add the print callback to all option types (except pseudo option types which don't represent values). This makes it less confusing for client API users (no strange properties that can't be read), and also lists the default properly with --list-options. Fix the option type for audio formats - they use int, not uint32_t. Fix some identation cosmetic issues.
* ao_alsa: reduce verbosity at -vwm42018-01-251-10/+10
| | | | | | | Always make the hw params dump function use MSGL_DEBUG, and remove the MSGL_V use. That means you need -v -v to see them. The detailed information is usually not very interesting, so this reduces the log noise.
* audio: fix annyoing af_get_best_sample_formats() definitionwm42018-01-258-9/+10
| | | | | | | | | | | | | | | | The af_get_best_sample_formats() function had an argument of int[AF_FORMAT_COUNT], which is slightly incorrect, because it's 0 terminated and should in theory have AF_FORMAT_COUNT+1 entries. It won't actually write this many formats (since some formats are fundamentally incompatible), but it still feels annoying and incorrect. So fix it, and require that callers pass an AF_FORMAT_COUNT+1 array. Note that the array size has no meaning in C function arguments (just another issue with C static arrays being weird and stupid), so get rid of it completely. Not changing the af_lavcac3enc use, since that is rewritten in another branch anyway.
* command: make sure to redraw on overlay commandswm42018-01-251-0/+1
| | | | | | | | | | When overlay-add etc. is run, make sure the playlop is rerun so that it considers actually redrawing the screen. (I considered making the OSD code generally wakeup the player, but that will probably lead to redundant wakeups, so I didn't bother.) Fixes #5431.
* video: minor simplificationwm42018-01-251-1/+1
| | | | | The check is redundant - if removed, it will write the same value, so it's a NOP.
* ytdl_hook: whitelist protocols from urls retrieved from youtube-dlRicardo Constantino2018-01-261-7/+47
| | | | | | Not very clean since there's a lot of potential unsafe urls that youtube-dl can give us, depending on whether it's a single url, split tracks, playlists, segmented dash, etc.
* manpage: remove obsolete information on bd://Ricardo Constantino2018-01-251-4/+3
| | | | ISO files have been supported by bd:// for a while.
* sub/osd: remove limits from border and shadow size optionsRicardo Constantino2018-01-241-2/+2
|
* manpage: document using sub-shadow-offset for background sizingRicardo Constantino2018-01-241-1/+2
|
* stream_bluray: always show list of available titlesRicardo Constantino2018-01-232-4/+4
|
* stream_bluray: silence libbluray's debug messages unless we want themRicardo Constantino2018-01-231-0/+4
| | | | libbluray's way too verbose on default loglevel with non-breaking issues.
* video: warn user against FFmpeg's lieswm42018-01-222-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found that at least for mjpeg streams, FFmpeg will set packet pts/dts anyway. The mjpeg raw video demuxer (along with some other raw formats) has a "framerate" demuxer option which defaults to 25, so all mjpeg streams will be played at 25 FPS by default. mpv doesn't like this much. If AVFMT_NOTIMESTAMPS is set, it prints a warning, that might print a bogus FPS value for the assumed framerate. The code was originally written with the assumption that FFmpeg would not set pts/dts for such formats, but since it does, the printed estimated framerate will never be used. --fps will also not be used by default in this situation. To make this hopefully less confusing, explicitly state the situation when the AVFMT_NOTIMESTAMPS flag is set, and give instructions how to work it around. Also, remove the warning in dec_video.c. We don't know what FPS it's going to assume anyway. If there are really no timestamps in the stream, it will trigger our normal missing pts workaround. Add the assumed FPS there. In theory, we could just clear packet timestamps if AVFMT_NOTIMESTAMPS is set, and make up our own timestamps. That is non-trivial for advanced video codecs like h264, so I'm not going there. For seeking and buffering estimation the situation thus remains half-broken. This is a mitigation for #5419.
* m_option: add print callback to color typeOlivier Perret2018-01-221-0/+7
| | | | This lets scripts query the value of 'background' and similar properties
* mpv.desktop: update mime type listsfan52018-01-221-1/+1
| | | | see https://wiki.debian.org/DebianMultimedia/PlayerSupport
* osx: add some more menu bar items as suggested by Apples's HIGAkemi2018-01-201-0/+35
| | | | | | | | | | | | this adds the standard menu bar items Services, Hide Others, Show All and Close, as suggested by Apple's HIG. https://developer.apple.com/macos/human-interface-guidelines/menus/menu-bar-menus/#app-menu - Services are useful to add custom actions and shortcuts via the System Preferences to mpv - Close is important since the menu bar can open secondary windows, like About or the Open dialogue. those couldn't be closed with the standard system shortcut before. this is now possible.
* video: change some remaining vo_opengl mentions to vo_gpuAkemi2018-01-209-11/+11
|
* osx: code cleanups and cosmetic fixesAkemi2018-01-207-18/+4
|
* osx: fix macOS 10.13 deprecation warningAkemi2018-01-202-1/+7
| | | | | | | | NSFileHandlingPanelOKButton is deprecated with macOS 10.13, but the replacement NSModalResponseOK is not available on 10.8 and earlier. added a declaration for 10.8 and earlier since i only officially dropped support for 10.7 and earlier. this is untested.
* cmd_parse: minor cosmeticswm42018-01-181-5/+2
|
* ta: introduce talloc_dup() and use it in some placeswm42018-01-186-12/+12
| | | | | | | It was actually already implemented as ta_dup_ptrtype(), but that seems like a clunky name. Also we still use the talloc_ names throughout the source, and I'd rather use an old name instead of a mixing inconsistent naming conventions.
* demux: reword an outdated commentwm42018-01-181-2/+1
|
* player: redo hack for video keyframe seeks with external audiowm42018-01-186-35/+78
| | | | | | | | | | | | | | | | | | | | | | | | If you play a video with an external audio track, and do backwards keyframe seeks, then audio can be missing. This is because a backwards seek can end up way before the seek target (this is just how this seek mode works). The audio file will be seeked at the correct seek target (since audio usually has a much higher seek granularity), which results in silence being played until the video reaches the originally intended seek target. There was a hack in audio.c to deal with this. Replace it with a different hack. The new hack probably works about as well as the old hack, except it doesn't add weird crap to the audio resync path (which is some of the worst code here, so this is some nice preparation for rewriting it). As a more practical advantage, it doesn't discard the audio demuxer packet cache. The old code did, which probably ruined seeking in youtube DASH streams. A non-hacky solution would be handling external files in the demuxer layer. Then chaining the seeks would be pretty easy. But we're pretty far from that, because it would either require intrusive changes to the demuxer layer, or wouldn't be flexible enough to load/unload external files at runtime. Maybe later.
* sws_utils: don't force callers to provide option structwm42018-01-186-7/+12
| | | | | | | mp_sws_set_from_cmdline() has the only purpose to respect the --sws- command line options. Instead of forcing callers to get the option struct containing these, let callers pass mpv_global, and get it from the option core code directly. This avoids minor annoyances later on.
* vo: log reconfig callswm42018-01-181-0/+2
| | | | Helpful for debugging, sometimes.
* mp_image_pool: add helper functions for FFmpeg hw frames poolswm42018-01-182-0/+81
| | | | | | | FFmpeg has its own rather "special" image pools (AVHWFramesContext) specifically for hardware decoding. So it's not really practical to use our own pool implementation. Add these helpers, which make it easier to use FFmpeg's code in mpv.
* mp_image: fix some metadata loss with conversion from/to AVFramewm42018-01-181-2/+14
| | | | | | | | | | | | | This fixes that AVFrames passing through libavfilter (such as with --lavfi-complex) implicitly stripped some fields. I'm not actually sure what to do with the mp_image_params.color.light field here (what happens if the colorspace changed?) - there is no equivalent in AVFrame or FFmpeg at all. It did not affect the old --vf code, because it doesn't allow libavfilter to change the metadata. Also log the .light field in verbose mode.
* video: make IMGFMT_IS_HWACCEL() return 0 or 1wm42018-01-181-1/+1
| | | | Sometimes helps avoiding usage mistakes.
* video: add utility function to pick conversion image format from a listwm42018-01-182-0/+10
|
* video: avoid some unnecessary vf.h includeswm42018-01-184-5/+0
|
* options: simplify mp_get_config_group() memory managementwm42018-01-182-4/+4
| | | | | | | | | | | | | | | | There is some craziness here: the function allocates m_config_cache, which in turn allocates the actual option struct, which is what the function returns. The user would expect to be able to use talloc_free() to deallocate everything. Of course this didn't work, because the returned pointer is not the root parent in the talloc tree. But with some additional talloc craziness, this can be fixed. We rearrange the parent pointers such that freeing the option struct will free m_config_cache first, which uninits the contents in the option struct, but fortunately not the option struct itself. This change should simplify API use on the caller side, and reduce surprises.
* options: don't warn when reading deprecated option as raw valuewm42018-01-181-1/+1
| | | | | | mp_read_option_raw() should not print the deprecation warning if the option is deprecated. This change also means you can't pass an alias to the function, but all existing uses should be fine.
* manpage: reword some vf command exampleswm42018-01-181-7/+8
| | | | Hopefully this is easier to read.
* Fix undefined preprocessor behaviorwm42018-01-183-4/+15
| | | | | | | | | | | This commit eliminates the following clang warning: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] Going by the clang commit message, this seems to be explicitly specified as UB by the standard, and they added this warning because MSVC apparently results in different behavior. Whatever, we can just avoid the warning with some small changes.
* client API: mention that SIGPIPE is sometimes blockedwm42018-01-181-0/+2
| | | | | | ipc-unix.c does this out of convenience. Since signals are global process state, this deserves a mention, since applications could in theory rely on SIGPIPE being set to something else.
* vo_gpu: skip DR for unsupported image formatswm42018-01-181-0/+3
| | | | | | | | | | | | | | DR (direct rendering) works by having the decoder decode into the GPU staging buffers, instead of copying the video data on texture upload. We did this even for formats unsupported by the GPU or the renderer. This "worked" because the staging memory is untyped, and the video frame was converted by libswscale to a supported format, and then uploaded with a copy using the normal non-DR texture upload path. Even though it "works", we don't gain anything from using the staging buffers for decoding, since we can't use them for upload anyway. Also, staging memory might be potentially limited (what really happens is up to the driver). It's easy to avoid, so just skip it in these cases.
* vo_gpu: fix broken 10 bit via integer textures playbackwm42018-01-171-3/+3
| | | | | | | | | | | The check_gl_features(p) call here checks whether dumb mode can be used. It uses the field use_integer_conversion, which is set _after_ the call in the same function. Move check_gl_features() to the end of the function, when use_integer_conversion is finally set. Fixes that it tried to use bilinear filtering with integer textures. The bug disabled the code that is supposed to convert it to non-integer textures.
* vo_gpu: rpi: defer gl_ctx_resize until after gl_ctx_initNiklas Haas2018-01-151-1/+3
| | | | | | | | This segfaults otherwise. The conditional is needed to break a circular dependency (gl_init depends on mpgl_load_functions which depends on recreate_dispmanx which calls gl_ctx_resize). Fixes #5398
* af_rubberband: add af-command to multiply current pitchVobe2018-01-152-6/+22
| | | | | | | | | | | | | This commit introduces the multiply-pitch af-command. Users may bind keys to this command in order to incrementally adjust the pitch of a track. This will probably mostly be useful for musicians trying to transpose up and down by semi tones without having to calculate the correct ratio beforehand. As an example, here is an input.conf to test this feature: { af-command all multiply-pitch 0.9438743126816935 } af-command all multiply-pitch 1.059463094352953
* demux_lavf: add required format hacks for DASHsfan52018-01-151-0/+1
|
* ytdl_hook: support native dash demuxer, if presentRicardo Constantino2018-01-151-1/+44
| | | | | | Uses track tbr instead of track disposition id for dash selection Works just as expected because youtube-dl also takes tbr from the manifests.
* libmpv/opengl_cb.h: mention OpenGL ES 2.0 supportLeo Izen2018-01-141-3/+4
| | | | | opengl_cb.h should mention GLES 2.0 support, since this support is available. Now it does mention it.
* osc: leave only demuxer cache duration and limit its refresh rateRicardo Constantino2018-01-141-19/+16
| | | | Sorta requested in #5390
* osd: treat user provided term-status-msg the same as the defaultKevin Mitchell2018-01-141-20/+24
| | | | | | | | | | | This is achieved by adding the new function get_term_status_msg that returns the status message specified by the user, or the mpv default. Previously, term_osd_print_status_lazy would exit early as soon as a user status message had been set, which potentially skipped adding the term_osd_bar if the user also requested that. fixes #3280
* osd: reference local pointer to mpctx->optsKevin Mitchell2018-01-131-2/+2
| | | | For brevity, since it's already there. Result should be identical.
* af_lavrresample: deprecate this filterwm42018-01-135-5/+27
| | | | | | The future direction might be not having such a user-visible filter at all, similar to how vf_scale went away (or actually, redirects to libavfilter's vf_scale).
* options: deprecate --vf-defaults and --af-defaultswm42018-01-132-2/+10
|
* audio: add global options for resampler defaultswm42018-01-1312-30/+116
| | | | | | | | This is part of trying to get rid of --af-defaults, and the af resample filter. It requires a complicated mechanism to set the defaults on the resample filter for backwards compatibility.
* audio/aframe: add missing include statementswm42018-01-131-0/+2
| | | | Otherwise it doesn't compile if they are not indirectly included before.
* video: change some mp_image_pool semanticswm42018-01-136-14/+16
| | | | | | | | | | Remove the max_count creation parameter, because it's pointless and rarely ever did anything. Add a talloc parent parameter instead (which is something completely different, but convenient, and all callers needs to be changed anyway). Instead of clearing the pool when the now removed maximum is reached, clear it on image parameter changes instead.
* player: silence config file loading message on resumingwm42018-01-131-6/+7
| | | | | | This is just an implementation detail; seems to be ugly to log it by default. Other cases of the try_load_config() function should be logged, though.
* client API: remove ytdl=no defaultwm42018-01-134-3/+4
| | | | | | | | | | | | | | With the recent changes to the script it does not incur a startup delay by default due to starting youtube-dl and waiting for it. This was the main reason for making libmpv have a different default. Starting sub processes from a library can still be a bit fishy, but I think it's ok. Still mention it in the libmpv header. There were already other cases where libmpv would start its own processes, such as the X11 backend calling xdg-screensaver. (The reason why this is fishy is because UNIX process management sucks: SIGCHLD and the wait() syscall make sub processes non-transparent and could potentially introduce conflicts with code trying to use them.)
* manpage: remove stale vo_wayland entrywm42018-01-131-19/+0
|
* ytdl_hook: look for the right ytdl binary according to systemRicardo Constantino2018-01-121-1/+2
| | | | | | | | package.config is available in 5.1, 5.2, 5.3 and luajit, so should be fine. The first character is the path separator, so it's '\' on windows and '/' on *nix. This should also prevent cases where users download the wrong binary.
* ytdl_hook: be more informative when youtube-dl failsRicardo Constantino2018-01-121-2/+8
|
* build: rpi: add missing linker flags to fix buildIlya Tumaykin2018-01-101-1/+1
| | | | | | | | See https://www.raspberrypi.org/forums/viewtopic.php?f=67&t=20005&p=194090 and https://github.com/raspberrypi/firmware/issues/110 Raspberry-pi upstream also adds '-lGLESv2' when EGL is used: https://github.com/raspberrypi/userland/blob/master/pkgconfig/egl.pc.in
* manpage: update references to gpu VOdaschiller2018-01-103-12/+12
|
* demux: include beginning of stream state in cached seekable rangewm42018-01-101-5/+19
| | | | | | | | | | | | Similar to 1eec7d2315, but for the beginning of the stream (named BOF in this commit). We can know this only if demuxing actually started from the beginning. If there is a seek to the beginning (even if you use --start=-1000), we don't know in general whether the demuxer truly returns the start of the file. We could probably make a heuristic with assuming that this is what happens if the seek target is before the start time or so, but this is not included in this commit.
* demux: fight libavformat cover art hack harderwm42018-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | libavformat's cover art hack (aka attached pictures) breaks the ability of the demuxer cache to keep multiple seek ranges. This happens because the cover art packet has neither position nor timestamp, and libavformat gives us the packet even though we intended to drop it. The cover art hack works by adding the cover art packet to the read packet stream once when demuxing starts (or after seeks). mpv treats cover art in a similar way internally, but we have to compensate for libavformat's shortcomings, and add the cover art packet ourselves when we need it. So we don't want libavformat to return the packet. We normally prevent this in demux_lavc.c/select_tracks() and explicitly disable cover art streams. (We add it in dequeue_packet() instead.) But libavformat will actually add the cover art packet even if we disable the cover art stream, because it adds it at initialization time, and does not bother to check again in av_read_frame() (apparently). The packet is actually read, and upsets the demuxer cache logic. In addition, this also means we probably decoded the cover art picture twice in some situations. Fix this by explicitly checking/discarding this in yet another place. (Screw this hack...)
* demux: add missing seekpoint when cached ranges are joinedwm42018-01-101-0/+8
| | | | | | | | The impact was that you couldn't exactly seek to the join point with a keyframe seek, even though there was a keyframe. This commit fixes it by preserving the necessary metadata that got lost on cached range joining. This is so absurdly obscure that it gets a longer code comment.
* input: make command argument list a dynamic arraywm42018-01-105-55/+63
| | | | | | | | Replace the static array with dynamic memory allocation. This also requires some code to honor mp_cmd.nargs more strictly. Generally allocates more stuff. Fixes #5375 (although we could also just raise the static limit).
* stream_bluray: support detecting UHD BD directoriesRicardo Constantino2018-01-111-10/+7
| | | | Close #5325
* ytdl_hook: don't try to use webpage_url if non-existentRicardo Constantino2018-01-111-1/+1
|
* video, audio: don't actively wait for demuxer inputwm42018-01-092-0/+4
| | | | | | | | | | | | If feed_packet() ended with DATA_WAIT, the player should have gone to sleep, until the demuxer wakes it up again when there is new data. But the call to read_frame() unconditionally overwrote this status code, so it never waited. The consequence was that the core burned CPU by effectively polling the demuxer status, which was noticeable especially when seeking in network streams (since seeking is async, decoders will start out with having to wait for network). Regression since commit 33e5755c.
* command: make pause display the same osd-msg-bar as seekKevin Mitchell2018-01-072-4/+6
| | | | | | Previously, toggling pause would generate no osd response, and changing that wasn't even configurable. This was surprising to users who generally expect to see *where* pause / unpause is taking place (#3028).
* command: default to osd-msg-bar for seeksKevin Mitchell2018-01-072-10/+7
| | | | | | | | The previous default was osd-bar (unless the user specified --no-osd-bar, in which case case it was osd-msg). Aside from requiring some twisted logic to implement, this surprised users since osd-msg3 wasn't displayed when seeking with the keyboard (#3028), so the time seeked to was never displayed.
* manpage: fix typos in osd level descriptionsKevin Mitchell2018-01-071-3/+3
|
* command: remove unnecessary whitespaceKevin Mitchell2018-01-071-67/+69
|
* ytdl_hook: actually use the script option from 87d3af6Ricardo Constantino2018-01-071-1/+1
|
* ytdl_hook: add script option to revert to trying youtube-dl firstRicardo Constantino2018-01-072-2/+8
| | | | | Should only make a difference if most of the URLs you open need youtube-dl parsing.
* player: handle audio playback restart in central playback start codewm42018-01-072-4/+10
| | | | | | | No idea why this wasn't done earlier. This makes playback start in audio only tracks closer to video-only or video/audio restart. It has the consequence that --cache-pause-initial now works for audio-only streams too.
* demux: silence pointless/confusing warningwm42018-01-071-1/+1
| | | | | | | | | | | | | | | | | | | This warning was printed when the demuxer cache tried to join two adjacent seek ranges, but failed if the last keyframe in the second range was within the (overlapping) first range. This is a weird corner case which to support probably would not be worth it. So this code just printed a warning and discarded the second range. As it turns out, this can happen relatively often if you seek a lot, and the seek ranges are very tiny (such as consisting of only 1 keyframe). Dropping the second range in these cases is OK and probably cheaper than trying to actually join them. Change the warning to verbose level. (It seems this could actually be "supported", because if keyframe_latest is not set, there will be no other keyframes, so it could just be unset, with the exception that q1->keyframe_latest in the code below must not be overwritten. But still, too much trouble for a special case that likely does not matter, and it would have to be tested too.)
* cache: fix --cache-initial status messagewm42018-01-071-4/+3
| | | | | | | | | | | | | | | For quite some time, msg.c hasn't output partial log messages anymore, and instead buffered them in memory. This means the MP_INFO() statement here just kept appending the message to memory, instead of outputting it. Easy enough to fix by abusing the status line (which means the frontend and this code will "fight" for the status line, but this code seems to win usually, as the frontend doesn't update it so often). Users should probably really switch to --cache-pause-initial. Fixes #5360.
* player: slightly refactor/simplify cache pausing logicwm42018-01-072-39/+37
| | | | | | | | | | | | | | | | The underlying logic is still the same (basically pausing if the demuxer cache underruns), but clean up the higher level logic a bit. It goes from 3 levels of nested if statements to 1. Also remove the code duplication for the --cache-pause-initial logic. In addition, make sure an earlier buffering state has no influence on the new state after a seek (this is also why some of the state resetting can be removed from loadfile.c). Initialize cache_buffer always to 100. It basically means we start out assuming all buffers are filled enough. This actually matters for verbose messages only, but removes some weird special casing.
* demux_null: mark as seekablewm42018-01-061-0/+1
| | | | | | No reason not to, and enables some strange constructions with --external-file (although the result is not too smooth for certain reasons).
* player: strictly never autoselect tracks from --external-fileswm42018-01-064-1/+9
| | | | | | | | | | | | | | | | Before this commit, some autoselection of tracks coming from files loaded with --external-files was still done. This commit removes all of it, and the only way to select a track is via the explicit stream selection options like --vid/--sid/--aid. I think this was always the original intention. The change could in theory still unintentionally surprise some users, so add a changelog entry. This does not affect --audio-file/--sub-file, even if these contain mismatching track types. E.g. if audio files passed to --audio-file contain subtitles, these should still be selected. Past feature requests indicate that users want this.
* ytdl_hook: check for possible infinite loop in playlist generationRicardo Constantino2018-01-061-7/+8
|
* ytdl_hook: add additional check for comedycentral urlsRicardo Constantino2018-01-061-1/+2
| | | | | | | If this breaks another site again, remove this whole if and just leave them as separate playlist items. Close #5364
* demux: include EOF state in cached seekable rangewm42018-01-051-3/+20
| | | | | | | | | | | | | | | | | | | | | | This means if the user tries to seek past EOF, and we know EOF was seen already, then use a cached seek, instead of triggering a low level seek. This requires some annoying tracking, but seems pretty simple otherwise. One advantage of doing this is that if the user tries to do this kind of seek, there's no unnecessary waiting for a reaction by network (and in most cases, redundant downloading of data just to discard it again). Another is that this avoids creating overlapping seek ranges: previously, the low level seek would naturally create a new range. Then it would read and add data from the end of the stream due to the low level demuxer not being able to seek to the target and selecting the last seek point before the end of the stream. Consequently, this new range would overlap with the previous cached range. But since the cache joining code is written such that you join the current range with the _next_ range (instead of the previous as it would be needed in this case), the overlapping ranges were left alone, until seeking back to the previous range. That was ugly, sort of harmless, and could happen in other cases, but this avoidable case was pretty easy to trigger.
* demux: export some debugging fields about low level demuxer behaviorwm42018-01-053-3/+30
| | | | | | | | | | Export them as explicitly undocumented debugging fields for the "demuxer-cache-state" property. Should be somewhat helpful to debug "wtf is the demuxer" doing situations better, especially when seeking. It also becomes visible how long the demuxer is blocked on an "old" seek when you keep seeking while the first seek hasn't finished.
* demux: fix crash due to incorrect seek range accountingwm42018-01-051-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | update_seek_ranges() has some special code that attempts to correctly adjust seek ranges for subtitle tracks. (Subtitle are a nightmare for seek ranges, because they are sparse, so using the packet list is not enough to reliably determine the valid cached range.) This had code like this inside the modified if statement: range->seek_start = MP_PTS_MAX(range->seek_start, <something>); If seek_start is NOPTS, then seek_start will be set to <something>, breaking some other code that checks seek_start for NOPTS to see if it's empty. Fix this by explicitly checking whether seek_start is NOPTS before adjusting it. The crash happened in prune_old_packets() because the range was marked as non-empty, yet there was no packet in it to prune. This was with files with muxed subtitles, when seeking back to the start. This should not happen anymore with the change. Also add an assert() to check_queue_consistency() that checks for this specific case. There's still some mess. In theory, subtitle tracks could be completely empty, yet their seek range would span the entire file. Seek range tracking of subtitle files is slightly broken (even before this change). Some of this should probably be revisited later, including not just using seek_start to determine whether a seek range should be pruned due to being empty.
* vo_gpu: hwdec_dxva2dxgi: initial implementationJames Ross-Gowan2018-01-065-2/+474
| | | | | | | | | | | | | This enables DXVA2 hardware decoding with ra_d3d11. It should be useful for Windows 7, where D3D11VA is not available. Images are transfered from D3D9 to D3D11 using D3D9Ex surface sharing[1]. Following Microsoft's recommendations, it uses a queue of shared surfaces, similar to Microsoft's ISurfaceQueue. This will hopefully prevent surface sharing from impacting parallelism and allow multiple D3D11 frames to be in-flight at once. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554.aspx
* stream: use native libavformat reconnection featurewm42018-01-044-64/+3
| | | | | | | | | | | | | | | | | | Remove our own hacky reconnection code, and use libavformat's feature for that. It's disabled by default, and until recently it did not work too well. This has been fixed in recent ffmpeg git master[1], so there's no reason to keep our own code. [1] FFmpeg/FFmpeg@8a108bdea06fac43af9f44b6d2538f357451167a We set "reconnect_delay_max" to 7, which limits the maximum time it waits. Since libavformat doubles the wait time on each reconnect attempt (starting with 1), and stops trying to reconnect once the wait time is over the reconnect_delay_max value, this allows for 4 reconnection attempts which should add to 11 seconds maximum wait time. The default is 120, which seems too high for normal playback use. (The user can still override these parameters with --stream-lavf-o.)
* ytdl_hook: update obsolete warning about retrying URL if failedRicardo Constantino2018-01-041-1/+1
|
* vo_gpu: d3d11: check for NULL backbuffer in start_frameJames Ross-Gowan2018-01-041-2/+6
| | | | | | | | | | | | | In a lost device scenario, resize() will fail and p->backbuffer will be NULL. We can't recover from lost devices yet, but we should still check for a NULL backbuffer in start_frame() rather than crashing. Also remove a NULL check for p->swapchain. This was a red herring, since p->swapchain never becomes NULL in an error condition, but p->backbuffer actually does. This should fix the crash in #5320, but it doesn't fix the underlying reason for the lost device (which is probably a driver bug.)
* vo_gpu: d3d11: don't use a bgra8 swapchainJames Ross-Gowan2018-01-041-19/+8
| | | | | | | | | | Previously, mpv would attempt to use a BGRA swapchain in the hope that it would give better performance, since the Windows desktop is also composited in BGRA. In practice, it seems like there is no noticable performance difference between RGBA and BGRA swapchains and BGRA swapchains cause trouble with a42b8b1142fd, which attempts to use the swapchain format for intermediate FBOs, even though D3D11 does not guarantee BGRA surfaces will work with UAV typed stores.
* player: cosmetics: rename internal variable for consistencywm42018-01-033-5/+5
| | | | This was so annoying.
* player: add --cache-pause-initial option to start in buffering statewm42018-01-034-0/+27
| | | | | | Reasons why you'd want this see manpage additions. Disabled by default, because it would increase latency of live streams by default. (Or well, at least it would be another problem when trying getting lower latency.)
* player: use fixed timeout for cache pausing (buffering) durationwm42018-01-035-11/+15
| | | | | | | | | | | | | | | This tried to be clever by waiting for a longer time each time the buffer was underrunning, or shorter if it was getting better. I think this was pretty weird behavior and makes no sense. If the user really wants the stream to buffer longer, he/she/it can just pause the player (the network caches will continue to be filled until they're full). Every time I actually noticed this code triggering in my own use, I didn't find it helpful. Apart from that it was pretty hard to test. Some waiting is needed to avoid that the player just plays the available data as fast as possible (to compensate for late frames and underrunning audio). Just use a fixed wait time, which can now be controlled by the new --cache-pause-wait option.
* manpage: slightly improve description of --cache-pause optionwm42018-01-031-3/+4
|
* av_log: stop accessing private ffmpeg fieldswm42018-01-031-2/+2
| | | | MPlayer legacy added in 3c49701490aecb.
* m_option: add print callback to start/end/lengthRicardo Constantino2018-01-031-0/+18
|
* osc: add seekbarkeyframes as a user optiondudemanguy2018-01-032-2/+12
|
* player: remove internal `vo-resize` command againsfan52018-01-024-10/+1
| | | | Its only usecase was automated in the previous commit.
* vo_gpu/context_android: replace both options with android-surface-sizesfan52018-01-024-8/+11
| | | | This allows us to automatically trigger a VOCTRL_RESIZE (also contained).
* client API: be more explicit about how to make libmpv use config fileswm42018-01-021-1/+5
|
* stream_lavf: minor fixes to HTTP reconnection supportwm42018-01-022-6/+14
| | | | | | | | | | | | | Don't drop the stream buffers, because the read call (that must have been failing) might try to extend an existing read buffer in the first place. Just move the messy seek logic to stream_lavf.c. (In theory, stream_lavf should probably make libavformat connect at the correct offset instead of using a seek to reconnect it again. This patch doesn't fix it, but at least it's a good argument to have the messing with the position not in the generic code.) Also update the comment about avio not supporting reconnecting. It has that feature now. Maybe we should use it, but only after it gets fixed.
* options: move most subtitle and OSD rendering options to sub structswm42018-01-0215-153/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
* sub: move all subtitle timestamp messing code to a central placewm42018-01-026-52/+80
| | | | | | | | | | | | | | | | | It was split at least across osd.c and sd_ass.c/sd_lavc.c. sd_lavc.c actually ignored most of the more obscure subtitle timing things. There's no reason for this - just move it all to dec_sub.c (mostly from sd_ass.c, because it has some of the most complex stuff). Now timestamps are transformed as they enter or leave dec_sub.c. There appear to have been some subtle mismatches about how subtitle timestamps were transformed, e.g. sd_functions.accepts_packet didn't apply the subtitle speed to the timestamp. This patch should fix them, although it's not clear if they caused actual misbehavior. The semantics of SD_CTRL_SUB_STEP are slightly changed, which is the reason for the changes in command.c and sd_lavc.c.
* command: add demuxer-lavf-list propertyRicardo Constantino2018-01-024-0/+37
| | | | | | | | | Was only available with --demuxer-lavf-format=help and the demuxer needed to be used for it to actually print the list. This can be used in the future to check if 'dash' support was compiled with FFmpeg so ytdl_hook can use it instead. For now, dashdec is too rudimentary to be used right away.
* player: add on_load_fail hookRicardo Constantino2018-01-023-5/+19
|
* osc: check if demuxer cache has not reached eofRicardo Constantino2018-01-021-3/+3
| | | | Avoids flickering stream cache status while filling the demuxer cache.
* ytdl_hook: fix single-entry playlistsRicardo Constantino2018-01-021-9/+8
| | | | Close #5313
* video, audio: always read all frames before getting next packetwm42018-01-013-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code tried to make sure at all times to try to read a new packet. Only once that was read, it tried to retrieve new video or audio frames the decoder might already have decoded. Change this to strictly read frames from the decoder until it signals that it wants a new packet, and only then read and feed a new packet. This is in theory nicer, follows the libavcodec recommended data flow, and and reduces the minimum latency by 1 frame. This merely requires switching the order in which those calls are done. Normally, the decoder will return only 1 frame until a new packet is required. If we would just feed it 1 packet, return DATA_AGAIN, and wait until the next frame is decoded, we would run the playloop 1 time too often for no reason (which is fine but might have some overhead). To avoid this, try to read a frame again after possibly feeding a packet. For this reason, move the feed/read code to its own functions each, instead of merely moving the code. The audio and video code for this particular thing is basically duplicated. The idea is to unify them one day, so make the change to both. (Doing this for video is the real motivation for this change, see below.) The video code change is slightly more complicated, because we have to care about the framedrop counting (which is just a heuristic, but for now considered better than nothing, and possibly considered required to warn the user of framedrops happening - maybe). Apparently this change helps with stalling streams on Android with the mediacodec wrapper and mpeg2 decoder implementations which deinterlace on decoding (and return 2 frames per packet). Based on an idea and observations by tmm1.
* vo_gpu/android: fallback to EGL_WIDTH/HEIGHTAman Gupta2018-01-012-5/+19
| | | | | | | | | | Uses the EGL width/height by default when the user fails to set the android-surface-width/android-surface-height options. This means the vo-resize command is optional, and does not need to be implemented on android devices which do not support rotation. Signed-off-by: Aman Gupta <aman@tmm1.net>
* mpv.rc: readd actual version infoRicardo Constantino2018-01-011-2/+2
|
* build: use unicode codepage in windresRicardo Constantino2018-01-011-1/+2
|
* build: move copyright statement to a shared locationwm42018-01-016-5/+9
| | | | | | | Now macosx_menubar.m and mpv.rc (win32) use the same copyright string. (This is a bit roundabout, because mpv.rc can't use C constants. Also the C code wants to avoid rebuilding real source files if only version.h changed, so only version.c includes version.h.)
* Update copyright yearwm42018-01-012-2/+2
|
* build: generate version.h before anything elseStefano Pigozzi2018-01-011-0/+5
| | | | | | This seems to fix issues when building on windows where compiling mpv.rc after a `waf clean` resulted in a failure because version.h was not always present
* main: fix typowm42018-01-011-1/+1
| | | | What the heck. This negated the entire check.
* vo_gpu: d3d11: avoid copying staging buffers to cbuffersJames Ross-Gowan2018-01-011-48/+15
| | | | | | | | | | | | | | | | Apparently some Intel drivers have a bug where copying from staging buffers to constant buffers does not work. We used to keep a copy of the buffer data in a staging buffer to enable partial constant buffer updates. To work around this bug, keep the copy in talloc-allocated system memory instead. There doesn't seem to be any noticable performance difference from keeping the copy in system memory. Our cbuffers are probably too small for it to matter anyway. See also: https://crbug.com/593024 Fixes #5293
* player/playloop.c: Revert --loop-file and --start interactionLeo Izen2017-12-311-13/+5
| | | | | | | | | | | | | | | | | | | This reverts commit 9513165c99c2ab3a945620b260823440f8ad125d and commit 4efe330efba296f6f07089d60087ef4e054bfe04. I had changed --loop-file to interact with --start to work the same way that --loop-playlist does. (That is, --loop-file seeks to the --start time upon looping, not the beginning of the file.) However, the consensus is that the old behavior is preferred and the interaction with --loop-playlist is the one that is incorrect. In addition, this change introduced a bug in the interaction between Quit-Watch-Later and --loop-file, where upon reaching playback end it would seek to the resume timestamp, not the start of the file. As a result, this commit reverts that change.
* demux_mkv: fix x264 hack if video track uses header compressionwm42017-12-301-1/+7
| | | | | | | | | | | | The x264 hack requires reading the first video packet, which in turn we handle with a hack in demux_mkv.c to get the packet without having to add special crap to demux.c. Another useless MKV feature (which they enabled by default at one point and which caused many demuxers to break completely, only to disable it again when it was too late) conflicts with this, because we actually pass a block as packet contents, instead of after "decompression". Fix this by calling demux_mkv_decode().
* manpage: put android surface options on one lineKevin Mitchell2017-12-281-2/+1
| | | | This is required by rst2man.
* demux_mkv: add hack to pass along x264 version to decoderwm42017-12-283-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes when resuming certain broken h264 files encoded by x264. See FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264 bug itself. Normally, the unregistered user data SEI (that contains the x264 version string) is informational only. But libavcodec uses it to workaround a x264 bug, which was recently fixed in both libavcodec and x264. The fact that both encoder and decoder were buggy is the reason that it was not found earlier, and there are apparently a lot of files around created by the broken decoder. If libavcodec sees the SEI, this bug can be worked around by using the old behavior. If you resume a file with mpv (i.e. seeking when the file loads), libavcodec never sees the first video packet. Consequently it has to assume the file is not broken, and never applies the workaround, resulting in garbage being played. Fix this by always feeding the first video packet to the decoder on init, and then flushing the codec (to avoid that an unwanted image is output). Flushing the codec does not remove info such as the x264 version. We also abuse the fact that the first avcodec_send_packet() always pushes the frame into the decoder (so we don't have to trigger the decoder by requsting an output frame).
* vd_lavc: add an option to explicitly workaround x264 4:4:4 bugwm42017-12-282-0/+17
| | | | | | Technically, the user could just use --vd-lavc-o with the same result. But I find it better to make this an explicit option, so we can document the ups and downs, and also avoid setting it for non-h264.
* demux_mkv: maintain a small packet read queuewm42017-12-281-22/+39
| | | | | This is less of a mess than the single-item queue in tmp_block, and also might help us in the future.
* vd_lavc: fix crash with RPI hwdecwm42017-12-281-1/+2
| | | | | | If you use vo_rpi, this could crash, because hwdec_devs is NULL. Untested. Fixes #5301.
* player: add internal `vo-resize` commandsfan52017-12-277-2/+19
| | | | Intended to be used with the properties from previous commit.
* vo_gpu/context: Let embedding application handle surface resizessfan52017-12-274-10/+33
| | | | | The callbacks for this are Java-only and EGL does not reliably return the correct values.
* manpage: fix typo in warningBisaloo2017-12-271-1/+1
|
* vo_gpu: EGL: provide SwapInterval to generic codewm42017-12-271-0/+10
| | | | | | | This means that we now explicitly set an interval of 1. Although that should be the EGL default, some drivers could possibly ignore this (unconfirmed). In any case, this commit also allows disabling vsync, for users who want it.
* vf_vdpaupp: fix error handling and software input modewm42017-12-271-5/+9
| | | | | | | | Crashed when no vdpau device was loaded. Also there was a mistake of not setting p->ctx, which broke software surface input mode. This was not found before, because p->ctx is not needed for anything else. Fixes #5294.
* osc: hide cache if not forced for local filesRicardo Constantino2017-12-261-13/+7
| | | | | Also hide cache if 'cache-used' is 0 (usually means video fits entirely within demuxer-cache-duration or stream cache is disabled).
* stats: enhance cache statsJulian2017-12-261-19/+35
| | | | | | Show total cache as well as demuxer cache separately. This adjusts the presented values to be consistent with status line and OSC modifications made in https://github.com/mpv-player/mpv/pull/5250
* lua: implement mp_utils.format_bytes_humanizedJulian2017-12-261-0/+10
|
* encode: implement --oset-metadata, and --oremove-metadataTheAMM2017-12-263-1/+48
| | | | | | | | | | | | This commit introduces a new --oset-metadata key-value-list option, allowing the user to specify output metadata when encoding (eg. --oset-metadata=title="Hello",comment="World"). A second option --oremove-metadata is added to exclude existing metadata from the output file (assuming --ocopy-metadata is enabled). Not all output formats support all tags, but luckily libavcodec simply discards unsupported keys.
* encode: rename option --ometadata to --ocopy-metadataTheAMM2017-12-265-5/+7
| | | | | | --copy-metadata describes the result of the option better, (copying metadata from the source file to the output file). Marks the old --no-ometadata OPT_REMOVED with a suggestion for the new --no-ocopy-metadata.
* tags: add mp_tags_removeKevin Mitchell2017-12-262-0/+21
| | | | | This removes all tags matching the provided key. This will be used for removing metadata tags during encoding.
* options: add -add/-append actions to key/value listswm42017-12-262-4/+32
| | | | Requested.
* DOCS/interface-changes.rst: fix minor typoswm42017-12-251-2/+2
|
* osc: make seek ranges rendering optionalpavelxdd2017-12-262-0/+9
| | | | | This commit adds a new osc setting `seekranges` to control the seek ranges visibility.
* options: drop some previously deprecated optionswm42017-12-2510-95/+5
| | | | | | | | A release has been made, so drop options deprecated for that release. Also drop some options which have been deprecated a much longer time before. Also fix a typo in client-api-changes.rst.
* wscript: remove redundant libraries check for shaderc-staticshinchiro2017-12-241-2/+1
| | | | | | | libshaderc_combined.a already bundles every libs it depends on References: https://github.com/google/shaderc/tree/master/libshaderc#build-artifacts
* vo_gpu: vulkan: fix segfault due to index mismatchNiklas Haas2017-12-251-5/+8
| | | | | | | | The queue family index and the queue info index are not necessarily the same, so we're forced to do a check based on the queue family index itself. Fixes #5049
* vo_gpu: vulkan: fix some image barrier odditiesNiklas Haas2017-12-251-10/+5
| | | | | | | | | | | A vulkan validation layer update pointed out that this was wrong; we still need to use the access type corresponding to the stage mask, even if it means our code won't be able to skip the pipeline barrier (which would be wrong anyway). In additiona to this, we're also not allowed to specify any source access mask when transitioning from top_of_pipe, which doesn't make any sense anyway.
* vo_gpu: vulkan: omit needless #defineNiklas Haas2017-12-251-5/+0
|
* vo_gpu: vulkan: fix sharing mode on malloc'd buffersNiklas Haas2017-12-251-1/+0
| | | | Might explain some of the issues in multi-queue scenarios?
* vo_gpu: vulkan: fix dummyPass creationNiklas Haas2017-12-251-1/+1
| | | | This violates vulkan spec
* vo_gpu: vulkan: fix the rgb565a1 names -> rgb5a1Niklas Haas2017-12-251-2/+2
| | | | This is 5 bits per channel, not 565
* vo_gpu: vulkan: allow disabling async tf/compNiklas Haas2017-12-254-4/+38
| | | | | | | | | Async compute in particular seems to cause problems on some drivers, and even when supprted the benefits are not that massive from the tests I have seen, so it's probably safe to keep off by default. Async transfer on the other hand seems to work better and offers a more substantial improvement, so it's kept on.
* vo_gpu: vulkan: refine queue family selection algorithmNiklas Haas2017-12-251-2/+7
| | | | | | This gets confused by e.g. SPARSE_BIT on the TRANSFER_BIT, leading to situations where "more specialized" is ambiguous and the logic breaks down. So to fix it, only compare the subset we care about.
* vo_gpu: vulkan: prefer vkCmdCopyImage over vkCmdBlitImageNiklas Haas2017-12-251-8/+31
| | | | | | blit() implies scaling, copy() is the equivalent command to use when the formats are compatible (same pixel size) and the rects have the same dimensions.
* vo_gpu: attempt re-using the FBO format for p->output_texNiklas Haas2017-12-254-1/+13
| | | | | | | | | This allows RAs with support for non-opaque FBO formats to use a more appropriate FBO format for the output tex, possibly enabling a more efficient blit operation. This requires distinguishing between real formats (which can be used to create textures) and fake formats (e.g. ra_gl's FBO hack).
* vo_gpu: vulkan: properly depend on the swapchain acquire semaphoreNiklas Haas2017-12-253-15/+25
| | | | | This is now associated with the ra_tex directly and used in the correct way, rather than hackily done from submit_frame.
* vo_gpu: vulkan: use correct access flag for presentNiklas Haas2017-12-251-2/+3
| | | | This needs VK_ACCESS_MEMORY_READ_BIT (spec)
* vo_gpu: vulkan: make the swapchain more robustNiklas Haas2017-12-251-23/+50
| | | | | Now handles both VK_ERROR_OUT_OF_DATE_KHR and VK_SUBOPTIMAL_KHR for both vkAcquireNextImageKHR and vkQueuePresentKHR in the correct way.
* vo_gpu: aggressively prefer async computeNiklas Haas2017-12-253-1/+12
| | | | | | | | | | On AMD devices, we only get one graphics pipe but several compute pipes which can (in theory) run independently. As such, we should prefer compute shaders over fragment shaders in scenarios where we expect them to be better for parallelism. This is amusingly trivial to do, and actually improves performance even in a single-queue scenario.
* vo_gpu: vulkan: support split command poolsNiklas Haas2017-12-257-164/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a single primary queue, we generate multiple vk_cmdpools and pick the right one dynamically based on the intent. This has a number of immediate benefits: 1. We can use async texture uploads 2. We can use the DMA engine for buffer updates 3. We can benefit from async compute on AMD GPUs Unfortunately, the major downside is that due to the lack of QF ownership tracking, we need to use CONCURRENT sharing for all resources (buffers *and* images!). In theory, we could try figuring out a way to get rid of the concurrent sharing for buffers (which is only needed for compute shader UBOs), but even so, the concurrent sharing mode doesn't really seem to have a significant impact over here (nvidia). It's possible that other platforms may disagree. Our deadlock-avoidance strategy is stupidly simple: Just flush the command every time we need to switch queues, and make sure all submission and callbacks happen in FIFO order. This required lifting the cmds_pending and cmds_queued out from vk_cmdpool to mpvk_ctx, and some functions died/got moved as a result, but that's a relatively minor change. On my hardware this is a fairly significant performance boost, mainly due to async transfers. (Nvidia doesn't expose separate compute queues anyway). On AMD, this should be a performance boost as well due to async compute.
* vo_gpu: invalidate fbotex before drawingNiklas Haas2017-12-254-10/+11
| | | | | Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
* vo_gpu: allow invalidating FBO in renderpass_runNiklas Haas2017-12-253-5/+22
| | | | | | | | | This is especially interesting for vulkan since it allows completely skipping the layout transition as part of the renderpass. Unfortunately, that also means it needs to be put into renderpass_params, as opposed to renderpass_run_params (unlike #4777). Closes #4777.
* vo_gpu: vulkan: properly track image dependenciesNiklas Haas2017-12-253-44/+121
| | | | | | | | | | | | | | | | | | | | | | | | This uses the new vk_signal mechanism to order all access to textures. This has several advantageS: 1. It allows real synchronization of image access across multiple frames when using multiple queues for parallelism. 2. It allows using events instead of pipeline barriers, which is a finer-grained synchronization primitive that allows for more efficient layout transitions over longer durations. This commit also restructures some of the implicit transition code for renderpasses to be more flexible and correct. (Note: this technically drops the ability to transition the image out of undefined layout when not blending, but that was a bug anyway and needs to be done properly) vo_gpu: vulkan: remove no-longer-true optimization The change to the output_tex format makes this no longer true, and it actually seems to hurt performance now as well. So just don't do it anymore. I also realized it hurts performance when drawing an OSD, so it's probably not a good idea anyway.
* vo_gpu: vulkan: add a vk_signal abstractionNiklas Haas2017-12-253-0/+144
| | | | | | | | | This combines VkSemaphores and VkEvents into a common umbrella abstraction which can resolve to either. We aggressively try to prefer VkEvents over VkSemaphores whenever the conditions are met (1. we can unsignal the semaphore, i.e. it comes from the same frame; and 2. it comes from the same queue).
* vo_gpu: vulkan: refactor command submissionNiklas Haas2017-12-255-72/+90
| | | | | | | | | | | | | | | Instead of being submitted immediately, commands are appended into an internal submission queue, and the actual submission is done once per frame (at the same time as queue cycling). Again, the benefits are not immediately obvious because nothing benefits from this yet, but it will make more sense for an upcoming vk_signal mechanism. This also cleans up the way the ra_vk submission interacts with the synchronization/callbacks from the ra_vk_ctx. Although currently, the way the dependency is signalled is a bit hacky: normally it would be associated with the ra_tex itself and waited on in the appropriate stage implicitly. But that code is just temporary, so I'm keeping it in there for a better commit order.
* vo_gpu: vulkan: reorganize vk_cmd slightlyNiklas Haas2017-12-255-57/+58
| | | | | | | | Instead of associating a single VkSemaphore with every command buffer and allowing the user to ad-hoc wait on it during submission, make the raw semaphores-to-signal array work like the raw semaphores-to-wait-on array. Doesn't really provide a clear benefit yet, but it's required for upcoming modifications.
* vo_gpu: vulkan: refactor vk_cmdpoolNiklas Haas2017-12-256-194/+189
| | | | | | 1. No more static arrays (deps / callbacks / queues / cmds) 2. Allows safely recording multiple commands at the same time 3. Uses resources optimally by never over-allocating commands
* Update VERSIONMartin Herkt2017-12-251-1/+1
|
* Release 0.28.0v0.28.0Martin Herkt2017-12-253-58/+118
|
* ytdl_hook: use table concat for playlist buildingRicardo Constantino2017-12-241-5/+4
| | | | Faster and more efficient than string concat with large playlists.
* ytdl_hook: don't preappend ytdl:// to non-youtube links in playlistsRicardo Constantino2017-12-241-1/+5
| | | | Close #5003
* player: update duration based on highest timestamp demuxedwm42017-12-245-0/+28
| | | | | | | | This will help with things like livestreams. As a minor detail, subtitles are excluded, because they sometimes have "unused" events after video and audio ends. To avoid this annoying corner case, just ignore them.
* player: allow seeking in cached parts of unseekable streamswm42017-12-243-28/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change and before the seekable stream cache became a thing, we could possibly seek using the stream cache. But we couldn't know whether the seek would succeed. We knew the available byte range, but could in general not tell whether a demuxer would stay within the range when trying to seek to a specific time position. We preferred to have safe defaults, so seeking in streams that were detected as unseekable were not honored. We allowed overriding this via --force-seekable=yes, in which case it depended on your luck whether the seek would work, or the player crapped its pants. With the demuxer packet cache, we can tell exactly whether a seek will work (at least if there's only 1 seek range). We can just let seeks go through. Everything to allow this is already in place, and this commit just moves around some minor things. Note that the demux_seek() return value was not used before, because low level (i.e. network level) seeks are usually asynchronous, and if they fail, the state is pretty much undefined. We simply repurpose the return value to signal whether cache seeking worked. If it didn't, we can just resume playback normally, because demuxing continues unaffected, and no decoder are reset. This should be particularly helpful to people who for some reason stream data into stdin via streamlink and such.
* stream_libarchive: fix seeking fallbackwm42017-12-241-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | In commit 1199c1e3, we added checks to every libarchive API call to make sure the archive was closed on ARCHIVE_FATAL - otherwise, libarchive could endow us with free CVEs (such as it apparently happens when you continue reading a rar archive that uses features not yet supported by libarchive). This broke the fallback for seeking in unseekable archive formats. Of course libarchive won't tell us directly whether a format implementation has seek support or not - and OF COURSE it returns ARCHIVE_FATAL if it has no seek support. (The error string, which you can retrieve via API, is actually more detailed, and also claims it's an "internal error". I don't think so, libarchive.) Returning ARCHIVE_FATAL means we have to assume free CVEs are ahead, and we have to close the archive. Which breaks the fallback in a dumb way (we have no way of telling which of those cases happened anyway). Fix this by assuming that all seek errors are potentially due to lack of seek support. If the seek call fails, reopen the archive, and set a flag so the seek API is never tried again. (This means we can still skip ahead for forward seeks, which is more efficient than skipping from the start of the archive entry.) Also fix an old typo in an error message.
* cache: propagate underlying stream seek errors in some caseswm42017-12-241-1/+12
| | | | | This just put the cache into an endless loop. This can happen simply if any seek call of the underlying stream returns an error.
* command: use IEC symbols for file size formattingMartin Herkt2017-12-241-4/+4
|
* wscript: support static linking of shadercMartin Herkt2017-12-241-1/+16
| | | | | These idiots have no idea how to design a library, so we’ll have to work around their bullshit for now.
* player: make track language matching case insensitivewm42017-12-232-2/+2
| | | | | | | | | There is no reason not to do this, and probably saves the user some trouble. Mostly untested. Closes #5272.
* demux_mkv: fix off by one errorwm42017-12-231-3/+1
| | | | | | | | | | | | Caused by the relatively recent change to packet parsing. This time it was probably triggered by lace type 0, which reduces the byte length of a 0 sized packet to 3 (timestamp + flag) instead of 4 (lace count for other lace types). The thing about laces is just my guess why it worked for other 0 sized packets, though. Also remove the redundant and now incorrect check below. Fixes #5271.
* demux: note refresh state separately in debug outputwm42017-12-231-5/+5
| | | | | | | This log line tells us why the demuxer is trying to read more, which us useful when debugging queue overflows. Probably barely useful, but I think keeping that flag separately also makes the code slightly easier to understand.
* osc: show demuxer cache buffered amount in byteswm42017-12-231-2/+6
| | | | | | | | Same as previous commit, but for the OSC. (A bit of a waste to request demuxer-cache-state at least twice per frame, but the OSC queries so many properties it probably doesn't matter anymore.)
* player: show demuxer cache buffered amount in bytes in the status linewm42017-12-233-6/+13
| | | | | | | | I don't want to add another field to display stream and demuxer cache separately, so just add them up. This strangely makes sense, since the forward buffered stream cache amount consists of data not read by the demuxer yet. (If the demuxer cache has buffered the full stream, the forward buffered stream cache amount is 0.)
* cache: lower default size to 2*10MBwm42017-12-232-4/+4
| | | | | | | | | | | | Reduce it from 75MB in both directions (forward/backwards) to 10MB each. The stream cache is kind of becoming useless in favor of the demuxer cache. Using both doesn't make much sense, because they will contain duplicated data for no reason. Still leave it at 10MB, which may help with mp4 a bit. libavformat's mp4 demuxer tends to seek too much, so we try to avoid triggering network level seeks by having some caching in the stream layer.
* demux: bump the demuxer cache readahead durationwm42017-12-232-2/+4
| | | | | | Set it to 10 hours, which is practically unlimited. (Avoiding use of "inf", since that might interact strangely with the option parser and such.)
* demux: always discard cached packets on track switcheswm42017-12-231-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes weird behavior in the following case: - open a file - make sure the max. demuxer forward cache is smaller than the file's video track - make sure the max. readahead duration is larger than the file's duration - disable the audio track - seek to the beginning of the file - once the cache has filled enable the audio track - a queue overflow warning should appear (- looking at the seek ranges is also interesting) The queue overflow warning happens because the packed queue for the video track will use up the full quota set by --demuxer-max-bytes. When the audio track is enabled, reading an audio packet would technically overflow the packet cache by the size of whatever packet is read next. This means the demuxer signals EOF to the decoder, and once playback has consumed enough video packets so that audio packets can be read again, the decoder resumes from EOF. This interacts badly with A/V synchronization and the whole thing can randomly crap itself until audio has fully recovered. We didn't care about this so far, but we want to raise the readahead duration to something very high, so that the demuxer cache is fully used. This means this case can be hit quite quickly by switching audio or subtitle tracks, and is not really an obscure corner case anymore. Fix this by always losing all cache. Since the cache can't be used anyway until the newly selected track has been read, this is not much of a disadvantage. The only thing that could be brought up is that unselecting the track again could resume operation normally. (Maybe this would be useful if network died completely without chance of recovery. Then you could watch the already buffered video anyway by deselecting the audio track again.) But given the headaches, this seems like the better solution. Unfortunately this requires adding new new strange fields and strangely fragmenting state management functions again. I'm sure whoever works on this in the future will hate me. Currently it seems like the lesser evil, and much simpler and robust than the other potential solutions. In case this needs to be revisited, here is a reminder for readers from the future what alternative solutions were considered, without those disadvantages: A first attempted solution allowed the demuxer to buffer some additional packets on track switching. This would allow it to read enough data to feed the decoder at least. But it was still awkward, as it didn't allow the demuxer to continue prefetching the newly selected track. It also barely worked, because you could make the forward buffer "over full" by seeking back with seekable cache enabled, and then it couldn't read packets anyway. As alternative solution, we could always demux and cache all tracks, even if they're deselected. This would also not require a network-level seek for the "refresh" logic (it's the thing that lets the video decoder continue as if nothing happened, while actually seeking back in the stream to get the missing audio packets, in the case of enabling a previously disabled audio track). But it would also possibly waste network and memory resources, depending on what the user actually wants. A second solution would just account the queue sizes for each stream separately. We could freely fill up the audio packet queue, even if the video queue is full. Since the demuxer API returns interleaved packets and doesn't let you predict which packet type comes next, this is not as simple as it sounds, but it'd probably tie in nicely with the "refresh" logic. A third solution would be removing buffered video packets from the end of the packet queue. Since the "refresh" logic gets these anyway, there is no reason to keep them if they prevent the audio packet queue from catching up with the video one. But this would require additional logic, would interact badly with a bunch of other corner cases. And as far as the code goes, it's rather complex, because all the logic is written with FIFO behavior in mind (including the fact that the packet queue is a singly linked list with no backwards links, making removal from the end harder).
* travis: stop excluding ffmpeg-gitRicardo Constantino2017-12-222-3/+1
| | | | Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>