summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* img_format: add format description table for mpv-only formatswm42020-04-233-135/+150
| | | | | | | Make this slightly less ad-hoc. Also correct the missing alpha flag for yap8/yap16. Despite reduced redundancy, the LOC is going up anyway... whatever.
* drm_common: set frsig to a valid signalJan Beich2020-04-221-0/+3
| | | | | | | | | | | On FreeBSD and DragonFly kernel checks if `frsig` is valid and aborts with `EINVAL` if not. However, `frsig` was never implemented. $ build/mpv --gpu-context=drm /path/to/video.mkv [...] [vo/gpu] VT_SETMODE failed: Invalid argument [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [...]
* build: detect VT_GETMODE on FreeBSD and DragonFlyJan Beich2020-04-222-2/+15
| | | | | | | | | | | | | | | | $ ./waf configure Checking for vt.h : no Checking for DRM : vt.h not found [...] ../test.c:1:10: fatal error: 'sys/vt.h' file not found #include <sys/vt.h> ^~~~~~~~~~ $ build/mpv --gpu-context=drm /path/to/video.mkv Error parsing option gpu-context (option parameter could not be parsed) Setting commandline option --gpu-context=drm failed. Exiting... (Fatal error)
* wayland: use mp_time deltas for presentation timeDudemanguy2020-04-204-30/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One not-so-nice hack in the wayland code is the assumption of when a window is hidden (out of view from the compositor) and an arbitrary delay for enabling/disabling the usage of presentation time. Since you do not receive any presentation feedback when a window is hidden on wayland (a feature or misfeature depending on who you ask), the ust is updated based on the refresh_nsec statistic gathered from the previous feedback event. The flaw with this is that refresh_nsec basically just reports back the display's refresh rate (1 / refresh_rate * 10^9). It doesn't tell you how long the vsync interval really was. So as a video is left playing out of view, the wl->last_queue_display_time becomes increasingly inaccurate. This led to a vsync spike when bringing the mpv window back into sight after it was hidden for a period of time. The hack for working around this is to just wait a while before enabling presentation time again. The discrepancy between the "bogus" wl->last_queue_display_time and the actual value you get from the feedback only happens initially after a switch. If you just discard those values, you avoid the dramatic vsync spike. It turns out that there's a smarter way to do this. Just use mp_time_us deltas. The whole reason for these hacks is because wl->last_queue_display_time wasn't close enough to how long it would take for a frame to actually display if it wasn't hidden. Instead, mpv's internal timer can be used, and the difference between wayland_sync_swap calls is a close enough proxy for the vsync interval (certainly better than using the monitor's refresh rate). This avoids the entire conundrum of massive vsync spikes when bringing the player back into view, and it means we can get rid of extra crap like wl->hidden.
* draw_bmp: silence another ridiculous ubsan warningwm42020-04-181-4/+4
| | | | | | | | | | | | | | UB sanitizer complains that aval<<24 (if >=128) cannot be represented as int. Indeed, we would shift a bit into the sign of an int, which is probably UB or implementation defined (I can't even remember, but the stupidity of it burns). So technically, ubsan might be right. Change aval to uint32_t, which I don't think has a chance of getting promoted to int. Change the other *val to uint32_t too for cosmetic symmetry. So we have to obscure the intention of the code (*val can take only 8 bits) out of language stupidity. How nice. (What a shitty language.)
* sd_lavc: mitigate evil rounding issue that could lead to off-by-1 frameswm42020-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A mkv sample file was provided to me, which contained a moving PGS subtitle track, with the same track rendered into the video as reference. The subtitle track appeared to stutter (while the video one was smooth). It turns out this was a timestamp rounding issue in mpv. The subtitle timestamps in the file match the video ones exactly. They're the same within the mpv demuxer too. Unfortunately, the conversion from and to libavcodec timestamps is lossy, because mpv uses a non-integer timebase, while libavcodec supports integers only. See mp_pts_to_av() and mp_pts_from_av(). The recovered timestamp is almost the same, but is off by a very minor part. As a result, the timestamps won't compare equal, and if that happens, display of the subtitle frame is skipped. Subtitle timestamps don't go through this conversion because... libavcodec is special? The libavcodec subtitle API is special. Fix this by giving it a microsecond of slack. This is basically as if we used an internal microseconds integer timebase, but only for the purpose of image subtitle display. The same could happen to sd_ass, except in practice it doesn't. ASS subtitles (well, .ass files) inherently use a timebase incompatible to video, so to ensure frame exactness, ASS timestamps are usually set to slightly before the video frame's. Discussion of better solutions: One could rewrite mpv not to use float timestamps. You'd probably pick some integer timebase instead (like microseconds), which would avoid the libavcodec interop issue. At the very least this would be a lot of work. It would be interesting to know whether the rounding in ther mpv<->lavc timestamp conversion could be fixed to round-trip in this case. The conversion tries to avoid problems by using the source timebase (e.g. milliseconds with mkv). But in general some rounding is unavoidable, because something between decoder and lowest demuxer layer could transform the timestamps. One could extend libavcodec to attach arbitrary information to avpacket and return it in the resulting avframe. To some degree, such a mechanism already exists (side data). But there are certain problems that make this unfeasible and broken. One could pass through exact mpv float timestamps by reinterpret-casting them to int64_t, the FFmpeg timestamp type. Actually mpv used to do this. But there were problems, such as FFmpeg (or things used by FFmpeg) wanting to interpret the timestamps. Awful shit that make mpv change to the current approach. There's probably more but I'm getting bored. With some luck I wasted precious seconds of your life with my nonsense.
* stats: move chapter/edition info below titleLaserEyess2020-04-161-3/+3
| | | | | | | | It is more consistent for editions/chapters to go below either the title or filename. They are all descriptive strings about the media itself and not file metadata like filesize. Suggested by Argon-
* stats: add edition information to page 1LaserEyess2020-04-161-1/+13
| | | | | | Edition information is conditional based on there being more than one edition present. It is printed on the same line as Chapters to save vertical space.
* demux_mkv: add png intra supportwm42020-04-161-0/+1
| | | | | | | Evil, non-standard shit. Sample file and script: https://github.com/mpv-player/random-stuff/tree/master/matroska/png
* player: remove duplicated track option setter codewm42020-04-153-17/+11
| | | | Well whatever.
* player: slightly improve use of secondary track selection limitswm42020-04-156-20/+28
| | | | | | Apparently, this was a bit of a mess, which caused the bug fixed by commit ec7f2388af2df. Try to improve this, and only use track selection entries that exist.
* player: remove mysterious declarationwm42020-04-151-2/+0
| | | | ??????????
* terminal-unix: add key_entry defs for DECCKM modeMurray Campbell2020-04-151-0/+4
| | | | | | | | zsh often sets DECCKM (i.e. Cursor Key Mode) meaning the arrow keys send `SS3 A/B/C/D` instead of `CSI A/B/C/D`. Add `key_entry` definitions for this alongside the existing DECCKM Reset definitions.
* player: don't segfault when unloading tracksNiklas Haas2020-04-151-0/+2
| | | | | | | | | e1e714ccc introduced a regression here when unloading a track (e.g. on VO/AO initilization error), due to no corresponding option existing for video/audio tracks with orders above 0, but the loop in `mp_deselect_track` being hard-coded to clear tracks up to NUM_PTRACKS. Introduce the simplest possible hackaround.
* vo_gpu: opengl: make sure to always clean up debug callbacksNiklas Haas2020-04-151-0/+4
| | | | | | | | | In theory this mostly happens automatically, especially after the 5 vsync limit disables this already. But if we uninit before 5 vsyncs are rendered, this can get left in a dangling 'enabled' state, which leaks a debug report callback. Always explicitly disable it just to be on the safe side.
* manpage: fix wrong option name for --fbo-formatwm42020-04-141-1/+1
| | | | Fixes: #7609
* zimg: fix swapped chroma planes with packed YUV bullshitwm42020-04-141-4/+4
| | | | | | | | | I must have messed this up when I actually added the Y210 format (because that one is correct). So my comment in the commit adding this about the FFmpeg pixfmt doxygen being wrong was wrong. I'd like to use this opportunity to complain once more about the existence of these terrible pixel formats.
* zimg: fix build with older FFmpeg (troublesome Intel dude format)wm42020-04-141-0/+2
|
* zimg: add support for 1 bit per pixel formatswm42020-04-132-2/+54
| | | | | | | | | | | | | | Again worthless, slow, and only for libswscale parity. With this, we support all formats libswscale supports, except bayer input, and rgb4/bgr4 output. We even support some formats libswscale doesn't. It's possible that the zimg wrapper isn't always as fast as libswscale. But there is optimization potential: the inner repack loops are self-contained enough that they could be reasonably be implemented in assembler (probably), and doing everything slice-wise should reduce the overhead of the separate pack/unpack stages.
* zimg: add packed YUV bullshitwm42020-04-132-6/+116
| | | | | | | | | | | | | | | | | Just lazily tested. The comment on AV_PIX_FMT_Y210LE seems to be wrong. It claims it's "like YUYV422", bit it seems more like YVYU422, at last the way libswscale input treats it. Maybe Intel pays its developers too much? The repacker inner lop is probably rather inefficient. In theory we could optimize it by reading the packed pixels as words, doing the component reshuffling using compile time values etc., but I'd rather keep the code size small. It's already bad enough that we have to support 16 bit per component variants, just because this one Intel guy couldn't keep it in his pants. In general, I can't be bothered to spend time on optimizing it; I'm only doing this for fun (i.e. masochistic obligation).
* demux_mkv: concatenate multiple tagswm42020-04-131-2/+8
| | | | | | | | | | | Instead of just picking the last tag that was encountered. The order of the tags still depends on the file order. This is probably wrong, and we should respect TargetTypeValue. But despite staring at the spec, I have no idea what the hell this should do, so fuck that. Fixes: #7604
* test: add list of zimg/sws conversionswm42020-04-132-0/+217
| | | | | | | Generic statement about how this is not really appropriate, etc., and only useful for temporary debugging things, and how I commit it anyway despite violating my own principles (and how I'd reject this change if it came from you).
* player: do not fall back to a default track with explicit selectionswm42020-04-132-0/+20
| | | | | | | | | | | | | | | | | | Consider e.g. --aid=2 with a file that has only 1 track. Then it would fall back to selecting track 1. Stop doing this. If no matching track is found, this will not select any track now. Note that the fingerprint stuff (track_layout_hash in the source) prevents softens the impact of this change. Without the fingerprint, playing a dual-audio file with the second track selected, and then a single-audio file, would play the second file without audio. But the fingerprint resets it due to differences in the track list. Try to exhaustively document this and tricky interactions between the other features. What a damn mess, I think it's simply cursed. Of course it's still my fault. See: #7608
* player: mess with track selection details againwm42020-04-133-12/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some time ago, properties and options were mostly unified. However, the track selection properties/options semantics are incompatible to this change. I'm still trying to handle the fallout. There are two things that are in the way: 1. Track properties somehow return the runtime selection, not the option value (all while properties are supposed to be aliases to options with the same name). 2. The user's track options are not supposed to be changed without interaction. If a track is auto-selected, the property should return its ID, but the option value should remain at "auto". Only if the user actually writes to the property the option should change. E.g. playing e.g. an audio-only file and then a normal video file not play the video file with --vid=no just because the audio file had no video track. In addition to each of them being in conflict with the property/option unification, attempt to fix one of them breaks the other one. Today, we're trying to fix parts of this and avoiding an unfortunate case where you can get a conflicting option/property value, and where trying to select a track does nothing if the track to select has the same ID as the option value. This breaks 2. from above in certain situations. See manpage additions. See: #7608
* demux: don't let --sub-create-cc-track add a track for attached pictureswm42020-04-131-1/+1
| | | | | | | | Unfortunately, attached pictures (from tags etc.) are treated as video tracks. That meant --sub-create-cc-track added a CC track for them as well. Stop doing that. See: #7608
* zimg: add support for some RGB fringe formatswm42020-04-131-0/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers 8 and 16 bit packed RGB formats. It doesn't really help with any actual use-cases, other than giving the finger to libswscale. One problem is with different color depths. For example, rgb565 provides 1 bit more resolution to the green channel. zimg can only dither to a uniform depth. I tried dithering to the highest depth and shifting away 1 bit for the lower channels, but that looked ugly (or I messed up somewhere), so instead it dithers to the lowest depth, and adjusts the value range if needed. Testing with bgr4_byte (extreme case with 1/2/1 depths), it looks more "grainy" (ordered dithering artifacts) than libswscale, but it also looks cleaner and smoother. It doesn't have libswscale's weird red-shift. So I call it a success. Big endian formats need to be handled explicitly; the generic big endian swapper code assumes byte-aligned components. Unpacking is done with shifts and 3 LUTs. This is symmetric to the packer. Using a generated palette might be better, but I preferred to keep the symmetry, and not having to mess with a generated palette and the pal8 code. This uses FFmepg pixfmts constants directly. I would have preferred keeping zimg completely separate. But neither do I want to add an IMGFMT alias for every of these formats, nor do I want to extend our imgfmt code such that it can provide a complete description of each packed RGB format (similar to FFmpeg pixdesc). It also appears that FFmpeg pixdesc as well as the FFmpeg pixfmt doxygen have an error regarding RGB8: the R/B bit depths are swapped. libswscale appears to be handling them differently. Not completely sure, as this is the only packed format case with R/B havuing different depths (instead of G, the middle component, where things are symmetric).
* zimg: add support for big endian input and outputwm42020-04-134-50/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the extremely annoying dumb things in ffmpeg is that most pixel formats are available as little endian and big endian variants. (The sane way would be having native endian formats only.) Usually, most of the real codecs use native formats only, while non-native formats are used by fringe raw codecs only. But the PNG encoders and decoders unfortunately use big endian formats, and since PNG it such a popular format, this causes problems for us. In particular, the current zimg wrapper will refuse to work (and mpv will fall back to sws) when writing non-8 bit PNGs. So add non-native endian support to zimg. This is done in a fairly "generic" way (which means lots of potential for bugs). If input is a "regular" format (and just byte-swapped), the rest happens automatically, which happens to cover all interesting formats. Some things could be more efficient; for example, unpacking is done on the data before it's passed to the unpacker. You could make endian swapping part of the actual unpacking process, which might be slightly faster. You could avoid copying twice in some cases (such as when there's no actual repacker, or if alignment needs to be corrected). But I don't really care. It's reasonably fast for the normal case. Not entirely sure whether this is correct. Some (but not many) formats are covered by the tests, some I tested manually. Some I can't even test, because libswscale doesn't support them (like nv20*).
* vf_format: add gross mechanism for forcing scaler for testingwm42020-04-138-3/+53
| | | | | | | | | | | This sucks, but is helpful for testing. Obviously, it would be much nicer if there were a way to specify _all_ scaler options per filter (if the user wanted), instead of always using the global options. But this is "too hard" for now. For testing, it is extremely convenient to select the scaler backend, so add this option, but make clear that it could go away. We'd delete it once there is a better mechanism for this.
* ta: minor simplification for talloc_stealwm42020-04-133-11/+1
| | | | Since commit f6615f00eeb0, it can't fail anymore.
* ta: remove a macro indirectionwm42020-04-131-4/+2
| | | | No idea what purpose this was supposed to serve.
* player, ta: remove use of an old macrowm42020-04-132-4/+1
| | | | | I thought that would make a nice idiom, but it ended up being useless or clunky.
* command: print edition title to OSD when cyclingLaserEyess2020-04-131-5/+26
| | | | | | Edition title is already exposed in demux_edition, it was just never added to the display. If no edition title exists it will fall back to the edition number.
* DOCS/interface-changes: add d3d11-exclusive-fs to list of changesJan Ekström2020-04-121-0/+2
| | | | Was forgotten in finishing up the pull request.
* vo_gpu: d3d11: also utilize config cache for d3d11-specific optionsJan Ekström2020-04-121-1/+9
| | | | | Update the cache whenever we utilize p->opts, as recommended by wm4.
* vo_gpu: d3d11: add support for exclusive fullscreenJames Ross-Gowan2020-04-122-1/+92
| | | | | Lets the application fully control the rendering onto the screen instead of the compositor.
* stats: support UP/DOWN to scroll at page 4 (perf)Avi Halachmi (:avih)2020-04-112-14/+86
| | | | | | | | | | | | | | Keys and lines-to-scroll are configurabe, and the scroll keys are only bound on pages which support scrolling (currently only page 4) - also during oneshot (like the page-switching keys). Scroll offset is reset for all pages on any key - except scroll keys, so that entering or switching to a page resets the scroll, as well as when "re-entering" the same page or "re-activating" the stats oneshot view. TODO: print_page(..) is highly associated with extending the oneshot timer if required. The timer handling can probably move into print_page and removed from all the places which boilerplate its management.
* stream_dvb: Remove call to stream_drop_buffers in fill_buffer.Oliver Freyermuth2020-04-101-2/+0
| | | | | | | | The call was hidden very well, via dvb_streaming_read -> dvb_update_config -> dvb_streaming_start -> dvb_set_channel, and broke the stream buffering logic. Dropping that call does not noticeably slow down channel switches.
* console: reduce memory usage in default modewm42020-04-101-73/+82
| | | | | | | | | | | | | | | This used 1 MB due to building the complete command and property list when starting the script. These are needed only for auto-completion, so build them only on demand. Since building them is fast enough, rebuild them every time. The key bindings table is not that much, but saves some KBs. Oddly, the code to build it uses less memory than the table at runtime (???), so build it at runtime as well. Add 2 tactic collectgarbage() calls as well. This frees unused heap when it is known that the script is going to be completely inactive until re-enabled by the user.
* common: fix mp_round_next_power_of_2()wm42020-04-101-5/+6
| | | | | | | Who write this dumb shit¹? It didn't handle 1<<31, and was unnecessarily slow. ¹ it was me
* stream: actually drop unneeded bufferwm42020-04-101-16/+21
| | | | | | | | | | | | | | | | | | The buffer can be larger than the normal size when "peeking" is used (such as done with some file formats, where a large number of bytes masy need to be "peeked" at the beginning, because FFmpeg). Once normal operation resumes, it's supposed to free this buffer again. Apparently this didn't happen as intended, because normal reading did have no way to discard back buffer before/while resizing the buffer. There's only a path for discarding the back buffer when actually reading. It seems like this unfortunately needs 2 code paths for discarding old data. Just put it into stream_resize_buffer(), where it's rather non-tricky (discarding can be done by adjusting the copy offset when moving data to the new allocation). The function now drops old data if it doesn't fit into the allocation. The caller must ensure that the new size is sufficient; the function signature changes only so the size of the implicitly guaranteed kept part can be checked with assert().
* stream: add assert, a cosmetic changewm42020-04-101-1/+3
| | | | This shouldn't change anything.
* stream: minor adjustment to buffer size limit logicwm42020-04-101-6/+6
| | | | | Instead of having 2 inconsistent limits on the upper possible buffer size (option limit and allocation code), use a shared constant for them.
* stream: fix whitespace within commentwm42020-04-101-1/+1
| | | | arrrrrrrghh
* vo: further reduce redundant wakeupswm42020-04-101-1/+7
| | | | | | | | | | | | | | | In display-sync mode, the core doesn't need to woken up every vsync, but only every time a new actual video frame needs to be queued. So don't wake up if there are still frames to repeat. In audio-sync mode, the wakeup is simply redundant, since there's a separate timer (in->wakeup_pts) to control when to queue a new frame. I think. This finally brings the required playloop iterations down to almost the number of video frames. (As originally intended, really.) Also a fairly risky change.
* video: remove another redundant wakeupwm42020-04-103-20/+46
| | | | | | | | | | | | | | | The wakeup at the end of VO frame rendering seems redundant, because after rendering almost no state changes. The player core can queue a new frame once frame rendering begins, and there's a separate wakeup for this. The only thing that actually changes is in->rendering. The only thing that seems to depend on it and can trigger a wakeup is the vo_still_displaying() function. Change it so that it needs an explicit call to a new API function, so we can avoid wakeups in the common case. The vo_still_displaying() code is mostly just moved around due to locking and for avoiding forward declarations. Also a somewhat risky change (tasty new bugs).
* video: avoid redundant self-wakeup on each queued framewm42020-04-101-1/+2
| | | | | | | | | This should be unnecessary, since the VO itself performs wakeups once a new frame can be queued. The only situation I can think of where this might be required are EOF situations (which are always strange). If I'm wrong, there'll be fun new bugs, probably causing frame drops or temporary stalls.
* player, stats: more silly debug stuffwm42020-04-106-2/+26
| | | | | In addition to stats.c being gross, I don't think master branch code should be littered with debug code. But it's a helpful abomination.
* filter: reduce redundant re-iterationswm42020-04-101-8/+29
| | | | | | | | | | | | | | | | | | |