summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* player: disable DS with spdif transcoding toowm42016-07-241-2/+5
| | | | | | Otherwise it behaves dumb. (Although you could argue it shouldn't try to guess whether speed changes work, but instead simply disable DS if they don't work.)
* audio: refactor mixer code and delete mixer.cwm42016-07-176-33/+88
| | | | | | | | | | | | | | | | | mixer.c didn't really deserve to be separate anymore, as half of its contents were unnecessary glue code after recent changes. It also created a weird split between audio.c and af.c due to the fact that mixer.c could insert audio filters. With the code being in audio.c directly, together with other code that unserts filters during runtime, it will be possible to cleanup this code a bit and make it work like the video filter code. As part of this change, make the balance code work like the volume code, and add an option to back the current balance value. Also, since the balance semantics are unexpected for most users (panning between the audio channels, instead of just changing the relative volume), and there are some other volumes, formally deprecate both the old property and the new option.
* player: do not cut off terminal status line if it contains newlineswm42016-07-151-1/+1
| | | | | | | Just a heuristic to preserve the status line in odd corner cases. Probably a crap idea. Fixes #3340.
* Use - as command-name separator everywhereTimotej Lazar2016-07-143-12/+12
| | | | | | | Old-style commands using _ as separator (e.g. show_progress) were still used in some places, including documentation and configuration files. This commit updates all such instances to the new style (show-progress) so that commands are easier to find in the manual.
* command: add properties for HDR metadataNiklas Haas2016-07-131-0/+2
| | | | | | | | | Since it turns out that knowing what exactly a file was tagged with can be useful for debugging purposes, expose this as a property so I can check it more easily. This is mostly useful for sig-peak (since nom-peak is currently entirely calculated by us), but I added both for consistency.
* video: respect --deinterlace=autowm42016-07-121-1/+2
| | | | | | | | | | | | | | | | | | | | --deinterlace=auto is the default, and has the obscure semantics that deinterlacing is disabled, unless the user has manually inserted a deinterlacing filter. While in software decoding this doesn't matter, and we will happily insert 2 yadif filters (if the user has already added one), or not remove the yadif filter (if deinterlacing is disabled, but the user has added the filter manually), this is different with hardware deinterlacer filters. These support VFCTRL_SET_DEINTERLACE for toggling deinterlacing filtering at runtime. It exists mainly for legacy reasons, and possibly because it makes switching deinterlacing modes more efficient. It might also gives us an entry-point for VO deinterlacing, maybe. For whatever reasons this mechanism exists, we still support and use it. This commit fixes that video.c always used VFCTRL_SET_DEINTERLACE to disable deinterlacing, even if --deinterlace=auto was set. Fix this by checking the value of the option directly.
* audio: show an osd bar when changing ao-volumeUros Vampl2016-07-101-1/+17
| | | | also, make the osd msg prettier
* audio: drop --softvol=no and --softvol=autowm42016-07-093-42/+71
| | | | | | | | | | | | | | Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
* command: don't delay progress updates to next video framewm42016-07-081-0/+1
|
* video: fix midstream video configuration changeswm42016-07-081-0/+1
| | | | | | | Commit 771a8bf5 added code to avoid unnecessary vf_reconfig() calls for unrelated reasons, but forget to consider that it has to be called at least once if the input format changes. As a consequence it got "stuck" due to not being able to decode more frames.
* video: limit number of frames sent to VO to the VO requested amountwm42016-07-071-1/+3
| | | | | | | | | | vo_frame can have more than 1 frame - the extra frames are future references, which are sometimes useful for filtering (vo_opengl interpolation). There's no harm in reducing the number of frames sent to the VO requested amount of future frames, so do that. Doesn't actually reduce the number of concurrently in use frames in practice.
* player: cut off status line on terminal widthwm42016-07-061-0/+6
| | | | | | | | | | If the status line is wider than the reported terminal size, then cut it off instead of causing the terminal to scroll down for the next line. This is done in the most primitive way possible, assuming ASCII. This was actually done in the past as far as I'm aware; do it again. (Probably differently.)
* video: fix deinterlace filter handling for VFCTRL_SET_DEINTERLACE filterswm42016-07-061-18/+20
| | | | | | | | | | | | | | | | | | | | Some filters support VFCTRL_SET_DEINTERLACE. This affects most hardware deinterlace filters. They can be inserted by the user manually, or auto- inserted by vf.c itself as conversion filter (vf_d3d11vpp). In these cases, we shouldn't insert or remove filters outselves, and instead VFCTRL_SET_DEINTERLACE should be invoked to switch the mode. This wasn't done correctly in the recently refactored code and could have broken with --deinterlace. (The refactor only considered switching via property in this case.) Fix it by making it a proper part of the filter_reconfig() function, and making set_deinterlacing() (which is called by the property handler) merely call filter_reconfig() in all cases to do the real work. We can even avoid rebuilding the filter chain - though only if no other auto-filters are inserted. It probably also provides a slightly cleaner way to implement functionality in the VO while still inserting video filter fallbacks correctly if required.
* video: fix deinterlace filter handling on pixel format changeswm42016-07-061-7/+4
| | | | | | | | | | | | | | | | | The test scenario at hand was hardware decoding a file with d3d11 and with deinterlacing enabled. The file switches to a non-hardware dedocdeable format mid-stream. This failed, because it tried to call vf_reconfig() with the old filters inserted, with was fatal due to vf_d3d11vpp accepting only hardware input formats. Fix this by always strictly removing all auto-inserted filters (including the deinterlacing one), and reconfiguring only after that. Note that this change is good for other situations too, because we generally don't want to use a hardware deinterlacer for software decoding by default. They're not necessarily optimal, and VAAPI VPP even has incomprehensible deinterlacer bugs specifically with software frames not coming from a hardware decoder.
* player: it's not --force-seeking but --force-seekablewm42016-07-061-1/+1
| | | | Oops. Fuck.
* player: rewrite deinterlace filter auto-insertionwm42016-07-054-107/+84
| | | | | | | | | | | | | | Instead of using the "vf" command code (which changes filters at runtime on user input), use the general filter-insertion code. The latter was added later, and is more suitable for automatically inserted filters. The old code failed in particular when using watch-later saving, which stored the filter list in the resume config file. If a user changed the hardware decoding mode via command line, the stored filter chain was out of date and could cause failure due to not working with hardware or software decoding mode. Storing the deinterlace filter in the filter list was unavoidable, because it was part of the user state. (The new code only edits the actually instantiated filters.)
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-4/+4
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* player: add missing space to error messagewm42016-07-021-1/+1
|
* player: fatal error if linked and compiled FFmpeg versions mismatchwm42016-07-011-0/+12
| | | | | | | | | We don't support this anymore. This tries to exit in a controlled way after command line options are applied in order to honor logging options and, in case of libmpv, not to kill the host. Not sure if it would be better to just vomit text to stderr and call abort().
* command: pack sub image data in overlay-add commandwm42016-07-011-33/+98
| | | | | | | | | | | | | | Working towards refcounted sub images, and also for removing bitmap packers from VOs. I'm not sure why we even have this overlay-add command. It was sort of "needed" before opengl-cb was introduced, and before Lua scripts could put ASS drawings on OSD without conflicting with the OSC. But now trying to use it doesn't make too much sense anymore. Still keep it because we're trying to be nice, but throw performance out of the window. Now image data is copied 2 more times before displaying it. This also makes using the command a bit simpler.
* command: improve playlist* properties change notificationswm42016-06-202-6/+10
| | | | | | | Until now, only the "playlist" property itself had proper change notification. Extend it to all other properties as well. Fixes #3267 (hopefully).
* player: fix previous commitwm42016-06-121-0/+3
| | | | | | | Of course we can't just skip updating the OSD if the playloop was woken up for the purpose of removing OSD after an OSD timer expired. Fixes e.g. OSD bars sometimes sticking along when seeking while paused.
* player: do not update OSD all the time when pausedwm42016-06-113-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, OSD is updated every time the playloop is run. This has to be done, because the OSD may implicitly reference various properties, without knowing whether they really need to be updated or not. (There's a property update mechanism, but it's mostly unavailable, because OSD is special-cased and can not use the client API mechanism properly.) Normally, these updates are no problem, because the OSD is only actually printed when the OSD text actually changes. But commit d23ffd24 added a rate-limiting mechanism, which tries to limit OSD updates at most every 50ms (or the next video frame). Since it can't know in advance whether the OSD is going to change or not, this simply waked up the player every 50ms. Change this so that the player is updated only as part of general updates determined through mp_notify(). (This function also notifies the client API of changed properties.) The desired result is that the player will not wake up at all in normal idle mode, but still update properties that can change when paused, such as the cache. This is mostly a cosmetic change (in the sense of making runtime behavior just slightly better). It has the slightly more negative consequence that properties which update implicitly (such as "clock") will not update periodically anymore.
* vo_opengl: refactor performance data propertiesNiklas Haas2016-06-081-43/+34
| | | | | | | | | | | | | | | Instead of having 9 different properties, requiring 18 different VOCTRLs to read them all, they are now exposed as a single property. This is not only cleaner (since they're all together) but also allows querying all 9 of them with only a single VOCTRL (by using mp.get_property_native). (The extra factor of 2 was due to an extra query being needed to get the type, which is now also unnecessary) This makes it much easier to access performance metrics from within a lua script, and also makes it easier to just show a readable, formatted version via show-text.
* player: remove unused return valuewm42016-06-081-6/+3
|
* player: tell user about --force-seeking if demuxer is not seekablewm42016-06-081-1/+2
| | | | | | | | | | | | | This comes up often, see e.g. #3220. The issue is that if the stream input is not seekable, the demuxer is marked as not seekable. But if the stream cache is enabled, the file still _might_ be seekable to a degree. We recently disabled seeking in this mode because it can cause very weird issues, mostly because if stream-layer seeking fails, the demuxers will arbitrarily misbehave. On the other hand, it can work if the seek is within the cached range, which is why the user can still enable it with --force-seeking. There is a weird trade-off between allowing this and not crapping up too easily, so just informing the user about the possibility seems best.
* build: silence -Wunused-resultNiklas Haas2016-06-072-3/+3
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* vo_opengl: expose performance timers as propertiesNiklas Haas2016-06-071-0/+43
| | | | | | | | | | | This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
* ytdl: fix brightcove urlsRicardo Constantino2016-05-301-3/+5
|
* video: remove d3d11 video processor use from OpenGL interopwm42016-05-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now have a video filter that uses the d3d11 video processor, so it makes no sense to have one in the VO interop code. The VO uses it for formats not directly supported by ANGLE (so the video data is converted to a RGB texture, which ANGLE can take in). Change this so that the video filter is automatically inserted if needed. Move the code that maps RGB surfaces to its own inteorp backend. Add a bunch of new image formats, which are used to enforce the new constraints, and to automatically insert the filter only when needed. The added vf mechanism to auto-insert the d3d11vpp filter is very dumb and primitive, and will work only for this specific purpose. The format negotiation mechanism in the filter chain is generally not very pretty, and mostly broken as well. (libavfilter has a different mechanism, and these mechanisms don't match well, so vf_lavfi uses some sort of hack. It only works because hwaccel and non-hwaccel formats are strictly separated.) The RGB interop is now only used with older ANGLE versions. The only reason I'm keeping it is because it's relatively isolated (uses only existing mechanisms and adds no new concepts), and because I want to be able to compare the behavior of the old code with the new one for testing. It will be removed eventually. If ANGLE has NV12 interop, P010 is now handled by converting to NV12 with the video processor, instead of converting it to RGB and using the old mechanism to import that as a texture.
* vf_d3d11vpp: add a D3D11 video processor filterwm42016-05-281-0/+3
| | | | | | | | | | | | | | | | | Main use: deinterlacing. I'm not sure how to select the deinterlacing mode at all. You can enumate the available video processors, but at least on Intel, all of them either signal support for all deinterlacers, or none (the latter is apparently used for IVTC). I haven't found anything that actually tells the processor _which_ algorithm to use. Another strange detail is how to select top/bottom fields and field dominance. At least I'm getting quite similar results to vavpp on Linux, so I'm content with it for now. Future plans include removing the D3D11 video processor use from the ANGLE interop code.
* command: add playlist-pos-1 propertywm42016-05-261-6/+20
| | | | | | | | | | This has often been requested for use on OSD. I don't really like having such "special" properties, but whatever. Hopefully this will be the only case. Untested because I'm too damn lazy. Fixes #2828.
* ytdl_hook: support multi-arc subtitlesRicardo Constantino2016-05-231-1/+20
| | | | While at it, pass durations of segments from ytdl if available.
* ta: remove old and redundant macrowm42016-05-171-1/+1
|
* lua: add timer:is_enabled() functionJulian2016-05-141-0/+4
| | | | | Allows to query if some timer is currently running or was stopped/killed.
* ytdl_hook: Just check if protocol is rtmpRicardo Constantino2016-05-141-1/+1
| | | | Partial fix to #3090
* video: add --hwdec=auto-copy modewm42016-05-111-2/+0
| | | | | | | | This uses the normal autoprobing rules like "auto", but rejects anything that isn't flagged as copying data back to system memory. The chunk in command.c was dead code, so remove it instead of updating it.
* player: restore usual seeking behaviorwm42016-05-091-16/+31
| | | | | | | | | | | | | | | | | | | | | | Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
* video: refactor how VO exports hwdec device handleswm42016-05-094-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* win32: make taskbar progress indication optionalmaniak13492016-05-082-4/+31
| | | | | | | | | | | Add --taskbar-progress command line option and property which controls taskbar progress indication rendering in Windows 7+. This option is on by default and can be toggled during playback. This option does not affect the creation process of ITaskbarList3. When the option is turned off the progress bar is just hidden with TBPF_NOPROGRESS. Closes #2535
* command: use NBSP for spacing after current marker for OSD listswm42016-05-041-2/+2
| | | | | Requested. Will prevent odd layout for playlists with URLs longer than the screen.
* command: change some hwdec propertieswm42016-05-041-0/+47
| | | | | | | | Introduce hwdec-current and hwdec-interop properties. Deprecate hwdec-detected, which never made a lot of sense, and which is replaced by the new properties. hwdec-active also becomes useless, as hwdec-current is a superset, so it's deprecated too (for now).
* command: slightly nicer OSD list formattingwm42016-05-031-19/+17
| | | | | | | | | For "current" markers on OSD properties like chapter-list. The marker is now an actual arrow instead of "> ", and non-current entries will have the same indentation as the current entry. While I'm not entirely sure about the new look of those lists, it's a bit better than the visual mess that was before.
* osd: make osd_ass_0/1 defineswm42016-05-031-2/+2
| | | | So we can concatenate them with strings at compile time.
* command: don't seek immediately when setting a-b loop when pausedwm42016-04-281-5/+5
| | | | | | | | | | Because it's annoying and feels unnatural. If the B point is set while paused, don't seek. If not paused, it should properly loop immediately. In theory there's a chance that it will show at least 1 frame after the loop point when setting the B point. But let's not care about that.
* player: strictly wait until done when backsteppingwm42016-04-271-1/+1
| | | | | | | | | | | This fixes backstepping getting "stuck" when e.g. holding down a key bound to the backstep command. The reason is that even if the backstep itself is finished, the next backstep might not take the new video PTS as reference if the hr-seek itself isn't finished yet. The intention of not waiting for the hr-seek to finish was faster backstepping by possibly skipping audio decoding. But it probably doesn't matter enough to make the rest of the code more complex.
* lavfi: shut up false positive compiler warningswm42016-04-261-2/+8
| | | | | | | As a positive side-effect, this also errors out gracefully for the extremely unlikely but possible case certain builtin filters are not available. (This could happen only with crippled libavfilter builds that can't be used by anything using its public API.)
* player: fix memleak when using video-frame-infotrUSTssc2016-04-241-0/+1
|
* player: always show the first frame in DS modewm42016-04-241-0/+4
| | | | Fixes bogus frame drop counter in cover art mode.
* player: assume video forwards timestamps jumps only with some formatswm42016-04-241-1/+1
| | | | | | | | | Another crappy fix for timestamp reset issues. This time, we try to fix files which have very weird but legitimate frame durations, such as cdgraphics. It can have many short frames, but once in a while there are potentially very long frames. Fixes #3027.
* player: force VO reconfig when unselecting video trackwm42016-04-231-1/+1
| | | | | Switches to a black window if --force-window is used while coverart "video" is playing.
* player: cleaner determination of current playback PTSwm42016-04-232-9/+11
| | | | | In particular, this won't overwrite the playback PTS in coverart mode, which actually fixes relative seeks.
* player: eagerly redraw OSD when seeking with coverartwm42016-04-231-1/