summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* osc: add feature to bottombar to not cover the videowm42019-09-191-1/+47
| | | | | | | | | | | | | | | | | | | | | | Normally I use the OSC like this: not at all, but have a key binding that does "cycle osc" to show it. And in that case, I don't really want it to overlap the damn video. I could use the zoom/pan options to move the video out of the way, but this is also sort of annoying. Likewise, you could write a script or so which does this automatically if the OSC appears, but that's still annoying, and computing values for these options such that the video is moved correctly is tricky. So I added a bunch of options that set explicit video borders (previous commit), and a option for the OSC to use them (this commit). Disabled by default, since I'm afraid this is too awkward and unpolished, especially with OSC default settings. I'm also using "osc-visibility=always". Effectively, making the OSC appear will box the video, and making it disappear (by unloading osc.lua) will restore the video back to normal.
* stats.lua: add cache info pagewm42019-09-191-4/+69
| | | | Uses page 3, which was apparently reserved for filter info.
* demux: add a on-disk cachewm42019-09-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat similar to the old --cache-file, except for the demuxer cache. Instead of keeping packet data in memory, it's written to disk and read back when needed. The idea is to reduce main memory usage, while allowing fast seeking in large cached network streams (especially live streams). Keeping the packet metadata on disk would be rather hard (would use mmap or so, or rewrite the entire demux.c packet queue handling), and since it's relatively small, just keep it in memory. Also for simplicity, the disk cache is append-only. If you're watching really long livestreams, and need pruning, you're probably out of luck. This still could be improved by trying to free unused blocks with fallocate(), but since we're writing multiple streams in an interleaved manner, this is slightly hard. Some rather gross ugliness in packet.h: we want to store the file position of the cached data somewhere, but on 32 bit architectures, we don't have any usable 64 bit members for this, just the buf/len fields, which add up to 64 bit - so the shitty union aliases this memory. Error paths untested. Side data (the complicated part of trying to serialize ffmpeg packets) untested. Stream recording had to be adjusted. Some minor details change due to this, but probably nothing important. The change in attempt_range_joining() is because packets in cache have no valid len field. It was a useful check (heuristically finding broken cases), but not a necessary one. Various other approaches were tried. It would be interesting to list them and to mention the pros and cons, but I don't feel like it.
* demux: redo timed metadatawm42019-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old implementation didn't work for the OGG case. Discard the old shit code (instead of fixing it), and write new shit code. The old code was already over a year old, so it's about time to rewrite it for no reason anyway. While it's true that the old code appears to be broken, the main reason to rewrite this is to make it simpler. While the amount of code seems to be about the same, both the concept and the actual tag handling are simpler. The result is probably a bit more correct. The packet struct shrinks by 8 byte. That fact that it wasted 8 bytes per packet for a rather obscure use case was the reason I started this at all (and when I found that OGG updates didn't work). While these 8 bytes aren't going to hurt, the packet struct was getting too bloated. If you buffer a lot of data, these extra fields will add up. Still quite some effort for 8 bytes. Fortunately, it's not like there are any managers that need to be convinced whether it's worth doing. The freedom to waste time on dumb shit. The old implementation attached the current metadata to each packet. When the decoder read the packet, the packet's metadata was made current. The new implementation stores metadata as separate list, and requires that the player frontend tells it the current playback time, which will be used to find the currently valid metadata. In both cases, the objective was to correctly update metadata even if a lot of data is buffered ahead (and to update them correctly when seeking within the demuxer cache). The new implementation is actually slightly more correct, because it uses the playback time for the metadata lookup. Consider if you have an audio filter which buffers 15 seconds (unfortunately such a filter exists), then the old code would update the current title 15 seconds too early, while the new one does it correctly. The new code also simplifies mixing the 3 metadata sources (global, per stream, ICY). We assume these aren't mixed in a meaningful way. The old code tried to be a bit more "exact". I didn't bother to look how the old code did this, but the new code simply always "merges" with the previous metadata, so if a newer tag removes a field, it's going to stick around anyway. I tried to keep it simple. Other approaches include making metadata a special sh_stream with metadata packets. This would have been conceptually clean, but the implementation would probably have been unnatural (and doesn't match well with libavformat's API anyway). It would have been nice to make the metadata updates chapter points (makes a lot of sense for the intended use case, web radio current song information), but I don't think it would have been a good idea to make chapters suddenly so dynamic. (Still an idea to keep in mind; the new code actually makes it easier to work towards this.) You could mention how subtitles are timed metadata, and actually are implemented as sparse packet streams in some formats. mp4 implements chapters as special subtitle stream, AFAIK. (Ironically, this is very not-ideal for files. It would be useful for streaming like web radio, but mp4 is extremely bad for streaming by design for other reasons.) bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
* demux: really disable cache for sub-demuxerswm42019-09-191-1/+4
| | | | | | | | | | | | | | | | | | It seems the so called demuxer cache wasn't really disabled for sub-demuxers (timeline stuff). This was relatively harmless, since the actual packet data was shared anyway via refcounting. But with the addition of a mmap cache backend, this may change a lot. So strictly disable any caching for sub-demuxers. This assumes that users of sub-demuxers (only demux_timeline.c by now?) strictly use demux_read_any_packet(), since demux_read_packet_async() will require some minor read-ahead if a low level packet read returned a packet for a different stream. This requires some awkward messing with this fucking heap of trash. The thing that is really wrong here is that the demuxer API mixes different concepts, and sub-demuxers get the same API as decoders, and use the cache code.
* player: ensure backward playback state is propagated on track switchingwm42019-09-194-5/+14
| | | | | | | | Track switching doesn't run reset_playback_state(), so a track enabled at runtime during backward playback would lead to a messed up state. This commit just does a bad code monkey fix to this. It feels like there needs to be a much better way to propagate this state.
* command: show number of hidden items in OSD listswm42019-09-191-6/+12
| | | | Affects the "classic" OSD rendering of some properties, like playlists.
* options: rename --play-direction to --play-dirwm42019-09-191-1/+1
| | | | | | | | | | | | | | | | | | | And add simpler aliases for the modes. I'm not sure how to name things, and the option list is in general full of different conventions. Some names are shortened, some are explicit and long. I guess options that have a chance to be used normally (i.e. not obscure tuning or debugging) should have a short and convenient names. In this specific case, play-direction is like a mixture of both. It should be either playback-direction or play-dir, not shorten one word but not the other. The convenience aliases are because I got sick of typing out "backward". I guess "back" would also do it, but there's no proper antonym (and maybe it's "wrong" in the strict sense of the word).
* player: partially fix seek_to_last_frame in backward modewm42019-09-191-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Another shitty obscure feature that usually nobody notices. Unsurprisingly, it doesn't go well with backward playback mode. If you use --keep-open in forward playback mode, and seek past the end of the file, it tries to seek to the very last frame. The demuxer will seek to the last "keyframe" before the end (i.e. some frames to go in most cases), and trying to hr-seek to the file duration often won't cut it, so this requires some special code. The function at hand seeks "close" to the end, and then stops hr-seek when the last frame us encountered (simple enough and very effective). In backward playback mode, start and end are reversed, and we need to seek "close" to the start of the file instead. Simple enough to do, and it works. One problem is that command.c has some weird logic to make going beyond the last chapter either end playback (--keep-open=no), or jump to the last frame. Now this will jump to the first frame, which is weird, but let's ignore this. Another problem is that seeking before playback start position hits EOF in backward playback mode, which is a demuxer bug, and has nothing to do with this code. But it triggers this code, so seeking before the start will show the "last" frame. (My description is a mess with directions. Figure it out yourself.)
* player: fix --loop with backward playbackwm42019-09-194-10/+19
| | | | | | | | | | | Obviously should seek back to the end of the file when it loops. Also remove some minor code duplication around start times. This isn't the correct solution by the way. Rather than hoping we know a reasonable start/end time, this stuff should instruct the demuxer to seek to the exact location. It'll work with 99% of all normal files, but add an appropriate comment (that basically says the function is bullshit) to get_start_time() anyway.
* player: remove some duplication between normal looping and ab-loopswm42019-09-191-14/+19
| | | | | | Not sure if this is better or worse. Some minor behavior changes.
* player: modify/simplify AB-loop behaviorwm42019-09-196-80/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
* player: replace a magic numer by another magic numberwm42019-09-191-1/+1
| | | | | | | | | | | | | | | | | This code attempts to seek to the last frame by seeking close to the end, and then decoding until the last frame has been reached. To do so it sets hrseek_lastframe, which for video enables some logic to "catch" this last frame, and completely ignores hrseek_pts. But audio still may use hrseek_pts I don't know if the original author (me) was thinking, if anything, when setting this variable to 1e99, essentially a random, number. It's very large, and a timestamp like this will never happen, so it does its job. But it's random. Use INFINITY instead. It will skip all audio samples in the audio code correctly. This change doesn't fix anything, but it does get rid of the random looking number.
* player: simplify/fix --start/--end handling with --rebase-start-time=nowm42019-09-192-27/+10
| | | | | | | | | | | | | | | | | | | | | | The get_play_start_pts() function was supposed to return "rebased" (relative to 0) timestamps. This was roundabout, because one of 2 callers just added the offset back, and the other caller actually expected an absolute timestamp. Change rel_time_to_abs() (whose return value get_play_start_pts() returns without further changes) to return absolute times. This should fix that absolute and relative times passed to --start and --end were treated the same, which can't be right. It probably also fixes --end if --rebase-start-time=no is used (which can't have been correct either). All in all I'm not sure why --rebase-start-time=no or absolute vs. relative times in --start/--end even exist, when they were incorrectly implemented for years. Untested, because no sample file and I don't care. However, if anyone cares, and I got it wrong, I hope it's simple to fix.
* player: minor --end simplificationwm42019-09-191-4/+1
|
* options: remove --chapterwm42019-09-191-23/+1
| | | | | | | | | Has been deprecated for almost 3 years. Manpage didn't mention the deprecation, but CLI and release notes did. It wouldn't be much effort to keep this option working, but I just don't see the damn point. --start/--end can specify chapters using special syntax, which is equivalent.
* player: fix --end for backwards playbackwm42019-09-192-0/+4
| | | | | | | | We need to transform the timestamp returned by get_play_end_pts(). I considered making it return the transformed timestamp directly. There are 4 callers; 2 need a transformed timestamps, 2 don't. So I guess it doesn't matter.
* osd: simplify AB-loop rendering on progress barwm42019-09-191-9/+10
| | | | | | This adds the stops using the same logic get_play_end_pts() and handle_loop_file(). It did that before, it just looks slightly different now. It also won't try to add MP_NOPTS_VALUE as stop value.
* player: make a function staticwm42019-09-192-2/+1
|
* player: fix --hr-seek-demuxer-offset with backward playbackwm42019-09-191-1/+1
|
* demux: set SEEK_HR for backstep seeks, move a hr-seek detail to playloopwm42019-09-191-4/+8
| | | | | | Just rearranging shit. Setting SEEK_HR for backstep seeks actually doesn't have much meaning, but disables the weird audio snapping for "keyframe" seeks, and I don't know it's late.
* sub: fix typo in commentwm42019-09-191-1/+1
|
* Implement backwards playbackwm42019-09-195-5/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn't have to change a single line in the timing code past decoder (just something minor to make external/cached text subtitles display). I committed it immediately while avoiding thinking about it. But there really likely are subtle problems of all sorts. As far as I'm aware, gstreamer also supports backward playback. When I looked at this years ago, I couldn't find a way to actually try this, and I didn't revisit it now. Back then I also read talk slides from the person who implemented it, and I'm not sure if and which ideas I might have taken from it. It's possible that the timestamp reversal is inspired by it, but I didn't check. (I think it claimed that it could avoid large changes by changing a sign?) VapourSynth has some sort of reverse function, which provides a backward view on a video. The function itself is trivial to implement, as VapourSynth aims to provide random access to video by frame numbers (so you just request decreasing frame numbers). From what I remember, it wasn't exactly fluid, but it worked. It's implemented by creating an index, and seeking to the target on demand, and a bunch of caching. mpv could use it, but it would either require using VapourSynth as demuxer and decoder for everything, or replacing the current file every time something is supposed to be played backwards. FFmpeg's libavfilter has reversal filters for audio and video. These require buffering the entire media data of the file, and don't really fit into mpv's architecture. It could be used by playing a libavfilter graph that also demuxes, but that's like VapourSynth but worse.
* command: put seek ranges at the end of outputwm42019-09-191-12/+12
| | | | | | | | | | | | | | | | | | This is a minor benign hack that reorders the MPV_FORMAT_NODE output. The order of members is not supposed to matter, but it's how the OSD renders them as raw output. Normally this isn't used, but demuxer-cache-state is a "prominent" case. Moving the seek ranges to the end avoids that the more important other fields are not cut off by going out of the screen on the bottom. Also output the seek ranges in reverse. The order doesn't matter either (as declared by input.rst). Currently, the demuxer orders them by least recent use. Reversing it makes the most recently used range (the current range) show up on top. In other words, this commit does basically nothing but fudge stuff in a cosmetic way to make debugging easier for me, and you've wasted your time reading this commit message and the diff. Good.
* demux, command: export bof/eof flagswm42019-09-191-0/+3
| | | | | Export these flags with demuxer-cache-state. Useful for debugging, but any client API users could also make use of it.
* command: make demuxer-cache-state property observablewm42019-09-191-1/+1
| | | | The update is throttled by the normal playloop cache update mechanism.
* playloop: update cache properties in idle statewm42019-09-191-3/+4
| | | | | | | | | This will properly notify observed properties if the player hasn't started actual playback yet, such as with --demuxer-cache-wait. This also happens to cause the main loop more often, which triggers MPV_EVENT_IDLE, and fixes the OSC display. (See previous commit message.)
* player: send MPV_EVENT_TICK during init for the sake of the oscwm42019-09-191-1/+4
| | | | | | | | | | | | | | | | | | | | The OSC's (osc.lua) event handling is fundamentally broken. It waits for MPV_EVENT_TICK to update the UI, and MPV_EVENT_TICK has become entirely meaningless, except as a hack for the OSC. There are many situations where the OSC doesn't properly update because the TICK event it expects isn't sent. Fix one of them: it doesn't update the cache state if the VO window is forced and --demuxer-cache-wait is used. Make it so that the tick event is sent even if playback initialization is taking time. This is still slightly broken, because it works only if the mainloop is actually run, which depends on random circumstances (such as moving the mouse over the VO window). The next commit will add another such circumstance which will make it appear to work, although it's still conceptually broken. If we "fixed" it and strictly woke up the player if the idle timer ran out, we'd send tick events all the time, even if nothing is going on, which we don't want. Fucking shitshow.
* player: don't print "Playing:" message if there's only 1 filewm42019-09-191-1/+4
| | | | | | | | This is just redundant and slightly annoying, at least for normal command line usage. If there are multiple entries, still print it (because you want to know where you are). Also still print it if the player was redirected (because you want to know where you got redirected to).
* player: add --demuxer-cache-wait optionwm42019-09-191-0/+13
|
* demux_edl, cue, mkv: clean up timeline stuff slightlywm42019-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | Remove the singly linked list hack, replace it with a slightly more proper data structure. This probably gets rid of a few minor bugs along the way, caused by the awkward nonsensical sharing/duplication of some fields. Another change (because I'm touching everything related to timeline anyway) is that I'm removing the special semantics for parts[num_parts]. This is now strictly out of bounds, and instead of using the start time of the next/beyond-last part, there is an end time field now. Unfortunately, this also requires touching the code for cue and mkv ordered chapters. From some superficial testing, they still seem to mostly work. One observable change is that the "no_chapters" header is per-stream now, which is arguably more correct, and getting the old behavior would require adding code to handle it as special-case, so just adjust ytdl_hook.lua to the new behavior.
* ytdl_hook: use no_clip for separate audio streamswm42019-09-191-1/+1
| | | | | | | | | | | | I noticed that some ytdl streams have a start time other than 0. There's currently no mechanism inside of the EDL stuff that determines this start time correctly, so it can happen that if the start time is high, demux_timeline.c tries to clip off the entire video and audio, resulting in failure of playback. As a counter measure, use the no_clip header, which entirely disables clipping against time ranges in demux_timeline.c. (It's basically a hack.)
* video: fix player not exiting if no video frame was renderedwm42019-09-191-2/+3
| | | | | | | | | | | | E.g. "mpv null:// --demuxer=rawvideo" will "hang" by waiting for video EOF forever. It's not signalled correctly because of the last-frame corner case, which attempts to wait until the current frame is finally displayed (which is signalled by whether a new frame can be queued, see commit 1a339fa09d for some details). If no frame was ever queued, the VO is not configured, and vo_is_ready_for_frame() never returns true. Fix this by using vo_has_frame(), which seems to be exactly the correct thing we need.
* ytdl_hook: fix pseudo-DASH if no init fragment is presentwm42019-09-191-5/+11
| | | | | | | | | | | | | | Init fragments are not a necessity for DASH, but this code assumed so. Maybe the check was to prevent worse. But using normal EDL here leads to very shitty behavior where it tries to open hundreds or thousands of fragments, each with its own demuxer and HTTP connection. (This behavior is fine for normal uses of EDLs, but completely unacceptable when emulating fragmented streaming protocols. I'm not sure why the normal EDL code is needed here, but I think someone claimed some obscure sites just need it.) This happens in the same situation as the one