summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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