summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* wscript: merge libavfilter check into the main ffmpeg checkwm42017-01-271-7/+2
| | | | | It used to be optional. That's why it was separate. No need for that anymore.
* atomic: drop __sync builtinswm42017-01-272-28/+1
| | | | | | | | | | The correctness of the stdatomic.h emulation via the __sync builtins is questionable, and we've been relying on exact stdatomic semantics for a while, so just get rid of it. Compilers which support __sync but not stdatomic.h will use to the slow mutex fallback. Not sure about the __atomic builtins. It doesn't seem to harm either, so leave it for now.
* stream: minor cleanup to previous commitwm42017-01-271-12/+7
| | | | | | | This is almost cosmetic, but removes the duplicated EOF-setting. Somewhat oddly, this will enter the reconnect path and exit it immediately again - should be fine.
* stream: set EOF if stream is canceledwm42017-01-261-1/+3
| | | | | | | | | Commit 7be495b3 added the cancellation test, but forgot to set the eof flag. This could lead to demux_mkv.c not terminating if the stream was cancelled in some code paths. This function is what is supposed to set the EOF flag in the first place, so just add the missing code.
* command: shorten long playlists on OSDwm42017-01-264-9/+107
| | | | | | | | | | | | A hacky, convoluted, half-working mess that attempts to cut off overlong playlists. It does so by relying on the ASS formatting rule that the font size is specified in the virtual PlayResY resolution. This means we can (normally) easily tell how many lines fit on the screen. On the other hand, this does not work if the text is wrapped. This as a kludge until a Better™ solution is available.
* osd: move some internal declarations to internal headerswm42017-01-263-10/+7
|
* vd_lavc: allocate 8 ref frames for VP9wm42017-01-261-2/+6
| | | | | | Apparently this is the maximum that can be preserved. There is also something about the decoder being able only to use 3 frames at a time, and I'm assuming these are part of the 8 frames.
* vo_opengl: egl_helpers: fix variable namewm42017-01-261-3/+3
| | | | | | It was basically inverted. Not sure how this even happened. Hopefully it's more an "I don't know what I was doing" instead of an "I don't know what I am doing" case.
* client API: adjust opengl_cb hardware decoding commentswm42017-01-261-3/+6
| | | | | | Replace the reprecated --hwdec-preload option. Add a comment about cuvid/cuda decoding.
* stream_lavf: add support for data URIsRicardo Constantino2017-01-253-1/+6
| | | | | | | Only FFmpeg supports them and they need to be in the format data:// like other protocols or prefixed with ffmpeg:// or lavf://. Closes #4058
* vf_lavfi: don't crash with VOs without hardware decoding supportwm42017-01-251-5/+7
| | | | | | | | | When playing with VOs which do not provide mp_hwdec_ctx, vf->hwdec_devs will remain NULL. This would make it crash on hwdec_devices_get_first(), even if no hardware decoding or filters using hardware decoding were involved. Fixes #4064.
* ad_lavc, vd_lavc: preserve codec_id/codec_type when setting paramswm42017-01-251-0/+8
| | | | | | | | | | avcodec_parameters_to_context() overwrites codec_type and codec_id. But we already set these by passing the selected AVCodec to avcodec_alloc_context3(). It's entirely possible that at least codec_id is different when forcing codecs with --ad/--vd. It's probably better not to cause confusion by overwriting them. It might even trigger undefined behavior in libavcodec (how it behaves or whether codec_id is supposed to be strictly set is unknown, though).
* ad_lavc, vd_lavc: move mpv->lavc decoder parameter setup to common codewm42017-01-254-38/+79
| | | | | | | | This can be useful in other contexts. Note that we end up setting AVCodecContext.width/height instead of coded_width/coded_height now. AVCodecParameters can't set coded_width, but this is probably more correct anyway.
* manpage: add "A/V sync" to make it findable with Ctrl+foctos2017-01-251-1/+1
|
* osc: fix crashes related to field eventresponder being nilRoland Hieber2017-01-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm still getting some crashes after issue #3210 was fixed in commit 5beb2306904b4437b5acf136b02aeaa073c351c7. It's hard to reproduce those crashes, they happen maybe once a month, so I guess it could be a race condition. But in any case, I don't see anything wrong in applying some defensive programming here. For reference, here is what was happening on 0.23.0-1 from Debian testing: Playing: ytdl://usL5CeP_row (+) Video --vid=1 (*) (h264) (+) Audio --aid=1 --alang=und (*) (aac) [osc] [osc] stack traceback: [osc] @osc.lua:2074: in function 'process_event' [osc] @osc.lua:2246: in function 'cb' [osc] mp.defaults:107: in function 'fn' [osc] mp.defaults:60: in function 'handler' [osc] mp.defaults:339: in function 'handler' [osc] mp.defaults:448: in function 'call_event_handlers' [osc] mp.defaults:485: in function 'dispatch_events' [osc] mp.defaults:441: in function <mp.defaults:440> [osc] [C]: in ? [osc] [C]: in ? [osc] Lua error: @osc.lua:2074: attempt to index field 'eventresponder' (a nil value) Note that the location is different from where issue #3210 happens. Signed-off-by: Roland Hieber <rohieb@rohieb.name>
* command: fix potential crash for script-binding with multi-commandswm42017-01-241-1/+2
| | | | | | | | "show-text test; script-binding display_stats" can potentially crash. It sends a message event. None of the string arguments can be NULL, which fails if cmd->key_name is NULL. This in turn can be due to commands combined with ";" (basically the key association doesn't consider nested commands).
* cue: accept lower-case cue commandswm42017-01-241-1/+1
| | | | | | | | | | Some files appear to use them. In the sample I've seen, one field was "Performer" instead of "PERFORMER". This change is slightly risky, because it increases the chance of misdetecting other formats as cue files. Fixes #4057.
* stream: check for playback aborts on reading toowm42017-01-241-0/+2
| | | | | | | | | Benefits demux_mkv.c, or demux_lavf.c during probing. In particular demux_lavf.c can sometimes get "stuck" when reading from a slow/blocking source, and if probing needs more than a few iterations. Since this is a read of an atomic variable with relaxed semantics, this should have no impact on reading speed at all, not even theoretically.
* av_common: remove old/unused timestamp passthrough codewm42017-01-241-21/+8
| | | | | | | | | | | | | | | | | | This attempted to pass through double float timestamps in a bit exact way by reinterpret casting them to int64_t. This usually worked, because libavcodec (in decoding mode) is mostly not allowed to interpret timestamps. libavcodec doesn't even know the unit of the timestamps, unless the API user sets a timebase. We've stopped doing this, and always set a timebase. Only ad_spdif.c still used this (indirectly through mp_set_av_packet()), but doesn't actually need timestamps on the packet. In fact, it's already explicitly setting the packet timestamp fields to 0 before passing it to FFmpeg API. This code is unused, and the passthrough method wasn't terribly elegant to begin with. Drop this code. Arbitrarily use AV_TIME_BASE_Q as fallback in situations the passthrough was used.
* build: new vaapi hwaccel API does not use av_image_copy_uc_from()wm42017-01-241-1/+1
| | | | | | | | | | | Not even Libav does. Whoops. The developer who wrote the FFmpeg code for this said he could not find any improvements when using the "GPU memcpy" ; instead, it made it actually slower on some hardware. It's not clear to what extent the "GPU memcpy" was needed for vaapi, but hopefully not very much (see #2317). This commit enables use of the new vaapi API by default with FFmpeg.
* av_common: drop unused functionwm42017-01-242-24/+0
| | | | Unused since the AVCodecParameters change.
* build: replace some FFmpeg API checks with version checkswm42017-01-247-32/+8
| | | | | | The FFmpeg versions we support all have the APIs we were checking for. Only Libav missed them. Simplify this by explicitly checking for FFmpeg in the code, instead of trying to detect the presence of the API.
* ad_lavc: respect AV_FRAME_FLAG_DISCARDwm42017-01-241-0/+5
| | | | | | | Since we set "skip_manual", we can actually get frames with this set. Currently, only AV_PKT_FLAG_DISCARD will trigger this flag, and only mov.c sets the latter flags, so this is related to FFmpeg's half-broken mp4 edit list support.
* sub: add option to force using video resolution for image subtitleswm42017-01-234-1/+10
| | | | Basically for debugging and dealing with broken files.
* sd_lavc: remove old broken heuristicwm42017-01-232-39/+10
| | | | | | | | | | | | | | | | | This core of this heuristic was once copied from MPlayer's spudec.c. I think it was meant for the case when the resolution field was missing or so. I couldn't find a file for which this actually does something. On the other hand, there are samples which actually have a smaller resolution than 720x576, and which are broken by this old hack. For subtitles that set no resolution (I'm not sure which codec/container that would be), there's still the fallback on video resolution. Just get rid of this hack. Also cleanup a bit. SD_CTRL_GET_RESOLUTION hasn't been used since DVD menu removal. get_resolution() is left with 1 call site, and would be quite awkward to keep, so un-inline it.
* player: actually initialize/destroy MPContext.lockwm42017-01-221-0/+3
| | | | | | | | Seems like quite on oversight. For most of the better pthread implementations, pthread_mutex_init() on an already 0-initialized memory block is probably a no-op, but of course we should do things correctly. Also could setup analysis tools.
* charset_conv: fallback to interpreting subs as latin1 if iconv failswm42017-01-221-1/+1
| | | | | | | | | | | | | | | For display purposes, it's better to show scrambled text - at least that's a more actionable failure mode than spamming the terminal with FFmpeg nonsense error messages. This avoids the obnoxious and pointless "Invalid UTF-8 in decoded subtitles text; maybe missing -sub_charenc option" FFmpeg error, which will be spammed on every single subtitle event. We don't even have a -sub-charenc option, fuck FFmpeg. Did I mention fuck FFmpeg yet? Because fuck FFmpeg.
* charset_conv: support minimum compatibility to utf8:... syntaxwm42017-01-221-1/+5
| | | | Because it's the most commonly used one, and trivial to support.
* player: remove --stream-capture option/propertywm42017-01-2112-119/+38
| | | | | | | | | | | | | | | This was excessively useless, and I want my time back that was needed to explain users why they don't want to use it. It captured the byte stream only, and even for types of streams it was designed for (like transport streams), it was rather questionable. As part of the removal, un-inline demux_run_on_thread() (which has only 1 call-site now), and sort of reimplement --stream-dump to write the data directly instead of using the removed capture code. (--stream-dump is also very useless, and I struggled coming up with an explanation for it in the manpage.)
* command: rename framedrop propertieswm42017-01-203-8/+20
| | | | | | | | | | "drop-frame-count" -> "decoder-frame-drop-count" "vo-drop-frame-count" -> "frame-drop-count" This gets rid of the backwards "drop-frame" part in the name. Maybe calling the new property "frame-drops" would be better, but there are already a bunch of similar properties that end in "-count".
* options: refacactor how --opengl-dwmflush is declaredwm42017-01-205-12/+17
| | | | | Same deal as previous commit, except this time we just readd it as lone global option, and read it directly.
* options: refactor how --opengl-dcomposition is declaredwm42017-01-206-8/+30
| | | | | | | | | | | | | | | | | vo_opengl used to have it as sub-option, which made it very hard to pass down option values to backends in a generic way (even if these options were completely backend-specific). For --opengl-dcomposition we used a VOFLAG to deal with this. Fortunately, sub-options are gone, and we can just add it as global option. Move the option to context_angle.c and add it as global option. I thought about adding a mechanism to let backends declare options, which would get magically picked up my m_config instead of having to add them to the global option list manually (similar to VO vo_driver.options), but decided against this complexity just for 1 or 2 backends. Likewise, it could have been added as a single option to avoid the boilerplate of an option struct, but then again there are probably going to be more angle suboptions, and it's cleaner.
* x11: pseudo HiDPI scalingwm42017-01-195-6/+39
| | | | | | | | | | | | | | | | Scale the window by the assumed DPI scaling factor, using 96 DPI as base. For example, a screen that reports 192 DPI is assumed to have a DPI scale factor 2. The window will then be created with twice the size. For robustness reasons, we accept only integer DPI scales between 1 and 9. We also error out if the X and Y scales are very different, as this most likely indicates a multiscreen system with botched size reporting. I'm not sure if reading the X server's DPI is such a good idea - maybe the Xrdb "Xft.dpi" value should be used instead. The current method follows what xdpyinfo does. This can be disabled with --hidpi-window-scale=no.
* options: drop deprecated --sub-codepage syntaxwm42017-01-193-72/+9
|
* options: drop deprecated --vd/--ad codecs selection featureswm42017-01-193-70/+14
| | | | | Only simple selection works now. Using "-" to terminate codec selection remains in the code (might get undeprecated).
* cocoa: don't constrain window frame for fullscreenAkemi2017-01-191-3/+4
| | | | | | | | | | | | | our constrainFrameRect prevents our window from positioning itself ontop of the menubar, which is unwanted for a fullscreen window. this always positioned our window vertically at -22/-23pt when going into fullscreen because of the menubar. this bug doesn't show on newer versions of OS X since the various flags we set force the window position. on OS X 10.9 though the fullscreen window was shifted 22pt downwards. even though this bug doesn't show on newer OS X versions, it should still be fixed for a possible behaviour changes in future version. Fixes #4044
* cocoa: don't init displaylink on reconfigAkemi2017-01-191-1/+1
| | | | | | | | | | | everytime we switched to a new video file a new displaylink was initialised and started, but the old one was not stopped and released beforehand. this lead to several displaylink callback calls per swap, depending on how many files were switched beforehand. moving the displaylink init call to the cocoa init functions will ever only init one displaylink. Fixes #4031
* cocoa: move updateBorder method to the protocolAkemi2017-01-192-5/+6
| | | | | | we are calling the method on a NSWindow object that may not respond to that call, since its a method of MpvVideoWindow. add the method to our protocol and rename that protocol to reflect the change.
* cocoa: properly recover from toggleFullscreen failAkemi2017-01-191-8/+20
| | | | | | | | | | | in some circumstances cocoa isn't able to enter or exit fullscreen but we still set window sizes and flags accordingly. this leaves us in a hanging state between fullscreen and window. it also prevents the toggleFullscreen method and its events to work properly afterwards. in that state it's impossible to enter or exit this 'semi-fullscreen'. add a proper fallback to recover from this state. Fixes #4035
* cocoa: fix window size in certain circumstancesAkemi2017-01-191-8/+2
| | | | | | a combination of starting from bundle and fullscreen used the standard window size (960x480) from the pseudo GUI instead of the wanted video size.
* ad_spdif: log avformat errorswm42017-01-191-1/+3
|
* player: actually let cache readahead after opening demuxer for prefetchwm42017-01-193-1/+4
| | | | | | | | | | | Disabling cache readahead by default until at least 1 track is selected is mainly for external files and such, where you don't want them to use up resources until they're actually used. It doesn't make sense to disable the cache for the demuxer opened for prefetch. Also, it's fine to let it do that for the main file too (doing or not doing it is of little consequence). That saves us from having to distinguish them.
* player: also log if completely prefetched URL is discardedwm42017-01-191-1/+4
| | | | Seems like quite an important/interesting case?
* player: add prefetching of the next playlist entrywm42017-01-188-91/+165
| | | | | | | | | | | | Since for mpv CLI, the player state is a singleton, full prefetching is a bit tricky. We do it only on the demuxer layer. The implementation reuses the old "open thread". This means there is significant potential for regressions even if the new option is not used. This is made worse by the fact that I barely tested this code. The generic mpctx_run_reentrant() wrapper is also removed - this was its only user, and its remains become part of the new implementation.
* player: restructure cancel callbackwm42017-01-187-11/+47
| | | | | | | | | | | | As preparation for file prefetching, we basically have to get rid of using mpctx->playback_abort for the main demuxer (i.e. the thing that can be prefetched). It can't be changed on a running demuxer, and always using the same cancel handle would either mean aborting playback would also abort prefetching, or that playback can't be aborted anymore. Make this more flexible with some refactoring. Thi is a quite shitty solution if you ask me, but YOLO.
* player: move some minor demuxer setup codewm42017-01-181-3/+4
| | | | | In particular, move demux_set_ts_offset() out of the loader thread. There's no discernible reason for that, probably.
* vo: log timings around flipping/waitingwm42017-01-181-3/+6
| | | | Found those useful.
* ad_spdif: fix obscure cases of AC3 passthroughwm42017-01-181-7/+28
| | | | | | | | | Apparently you set the native sample rate when passing through AC3. This fixes passthrough with 44100 Hz AC3. Avoid opening a decoder for this and only open the parser. (Hopefully DTS will also support this some time in the future or so - having to open a decoder just to get the profile is dumb.)
* vaapi: detect new API on FFmpeg too, and disable it by defaultwm42017-01-181-2/+11
| | | | | | | | | | | | | | | Since the only way to detect the API is by a version check, this had to wait until the patches were actually pushed to FFmpeg git (which now happened). Since this does not include the new magic GPU memcpy libavutil function yet, the new vaapi code would be slower if copy mode (like vaapi-copy) is used. This would be quite bad to use by default, so check for the function, and if not present, disable the new vaapi code. This effectively disables it by default on FFmpeg. (We assume that if the new GPU memcpy exists, vaapi's AVHWFramesContext implementation will use it.)
* vaapi: fix va_surface_get_uncropped_size() for libavutil surfaceswm42017-01-181-3/+9
| | | | Fixes vf_vavpp crashing with the new vaapi decode API.
* vaapi: we don't need SSE intrinsics with the new APIwm42017-01-171-1/+1
| | | | | | | libavutil does this for us. Although the new vaapi decode API does not strictly introduce or even need av_image_copy_uc_from(), it's implied that it will be present if the new decode API is present - even if it's not, we can't use our own SSE code with it anyway.
* vo_opengl, vo_opengl_cb: better hwdec interop backend selectionwm42017-01-179-23/+109
| | | | | | | | | | | Introduce the --opengl-hwdec-interop option, which replaces --hwdec-preload. The new option allows explicit selection of the interop backend. This is relatively complex, and I would have preferred not to add this, but it's probably useful to debug certain problems. In exchange, the "new" option documents that pretty much any but the simplest use of it will not be forward compatible.
* vo_opengl_cb: cleanup messy option synchronizationwm42017-01-171-24/+16
| | | | | | | | Replace the old code, that played games to evade thread-safety issues, with newer thread-safe option access functions. This also means mp_opengl_create() doesn't need to cache the hwdec settings anymore. (They're applied in mpv_opengl_cb_init_gl() instead.)
* vdpau: reject decoding of non-4:2:0wm42017-01-171-0/+5
| | | | | | | | | | | Tried to decode a High 4:2:2 file, since libavcodec code seemed to indicate that it's supported. Well, it decodes to garbage. I couldn't find out why ffmpeg.c actually appears to reject this correctly. The API seems to be fine with, just that the output is garbage. Add a hack for now.
* vd_lavc: always fail decoding immediately if copying hw surface failswm42017-01-171-0/+1
| | | | | | | | | | Successful decoding of a frame resets ctx->hwdec_fail_count to 0 - which us ok, but prevents fallback if it fails if --vd-lavc-software-fallback is set to something higher than 1. Just fail it immediately, since failing here always indicates some real error (or OOM), not e.g. a video parsing error or such, which we try to tolerate via the error counter.
* vdpau: use libavutil for surface allocation during decodingwm42017-01-174-83/+38
| | | | | | | | | | | | | | | | Use the libavutil vdpau frame allocation code instead of our own "old" code. This also uses its code for copying a video surface to normal memory (used by vdpau-copy). Since vdpau doesn't really have an internal pixel format, 4:2:0 can be accessed as both nv12 and yuv420p - and libavutil prefers to report yuv420p. The OpenGL interop has to be adjusted accordingly. Preemption is a potential problem, but it doesn't break it more than it already is. This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well as taking screenshots) will fail. Libav has fixed this bug ages ago.
* vaapi: move AVHWFramesContext setup code to common codewm42017-01-173-52/+63
| | | | | | | | | | In a way it can be reused. For now, sw_format and initial_pool_size determination are still vaapi-specific. I'm hoping this can be