summaryrefslogtreecommitdiffstats
path: root/demux/demux.h
Commit message (Collapse)AuthorAgeFilesLines
* Implement backwards playbackwm42019-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux, command: export bof/eof flagswm42019-09-191-0/+1
| | | | | Export these flags with demuxer-cache-state. Useful for debugging, but any client API users could also make use of it.
* sub: remove only user of demux_read_packet()wm42019-09-191-1/+0
| | | | | | | | | | | | | | | | | | | There are 3 packet reading functions in the demux API, which all function completely differently. One of them, demux_read_packet(), has only 1 caller, which is in dec_sub.c. Change this caller to use demux_read_packet_async() instead. Since it really wants to do a blocking call, setup some proper waiting. This uses mp_dispatch_queue, because even though it's overkill, it needs the least code. In practice, waiting actually never happens. This code is only called on code paths where everything is already read into memory (libavformat's subtitle demuxers simply behave this way). It's still a bit of a "coincidence", so implement it properly anyway. If suubtitle decoder init fails, we still need to unset the demuxer wakeup callback. Add a sub_destroy() call to the failure path. This also happens to fix a missed pthread_mutex_destroy() call (in practice this was a nop, or a memory leak on BSDs).
* player: add --demuxer-cache-wait optionwm42019-09-191-0/+1
|
* demux_timeline: report network speed of slave connectionswm42019-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | demux_timeline doesn't do any transport accesses itself. The slave demuxers do this (these will actually access the stream layer and perform e.g. network accesses). As a consequence, demux_timeline always reported 0 bytes read, and network speed display didn't work. Fix this by awkwardly reporting the amount of read bytes upwards. This is not very nice, and requires explicit calls whenever the slave "might" have read data. Due to the way the reporting is done, it only works if the slaves do not run demuxer threads, which makes things even less nice. (Fortunately they don't anyway, because it would be a waste of resources.) Some identifiers contain the word "hack" as a warning. Some of the stupidity comes from the fact that demux.c itself resets the stats randomly in order to calculate the bytes_per_second value, which is useless for a slave, but of course is still done, because demux.c itself is not aware of whether it's on the slave or top-level layer. Unfortunately, this must do. In theory, the demuxer thread/cache layer should be separated from demuxer implementations. This would get rid of all the awkwardness and nonsense. For example, the only threading involved would be the caching layer, completely separate from demuxers themselves. It'd be the only thing calculates speed rates for the player frontend, too (instead of doing it for each demuxer, even if unused).
* demux: slightly cleanup network speed reportingwm42019-09-191-3/+2
| | | | | | | | | | | | It was an ugly hack, and the next commit will make it even uglier. Slightly reduce the ugliness to prevent death of too many brain cells, though it's still an ugly hack. The cleanup is really minor, but I guess the following commit would be much worse otherwise. In particular, this commit checks accesses (instead of having a public field with evil access rules), which should avoid misunderstandings and incorrect use. Strictly speaking, the added field is redundant, but the next commit complicates it a bit.
* demux: another unused functionwm42019-09-191-1/+0
|
* demux: autoselection is gonewm42019-09-191-1/+0
| | | | Was used by DVD, I think.
* demux: remove some more minor dead codewm42019-09-191-2/+0
| | | | Also add clarifications.
* demux: get rid of ->control callbackwm42019-09-191-5/+1
| | | | | | | | The only thing left is the notification for track switching. Just get rid of that. There's probably no real reason to get rid of control(), but why not. I think I was actually trying to do some real work but fuck that.
* demux: change hack for closing subtitle files earlywm42019-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | Subtitles (and a few other file types, like playlists) are not streamed, but fully read on opening. This means keeping the file handle or network socket open is a waste of resources and could cause other weird behavior. This is why there's a hack to close them after opening. Change this hack to make the demuxer itself do this, which is less weird. (Until recently, demuxer->stream ownership was more complex, which is why it was done this way.) There is some evil shit due to a huge ownership/lifetime mess of various objects. Especially EDL (the currently only nested demuxer case) requires being careful about mp_cancel and passing down stream pointers. As one defensive programming measure, stop accessing the "stream" variable in open_given_type(), even where it would still work. This includes removing a redundant line of code, and removing the peak call, which should not be needed anymore, as the remaining demuxers do this mostly correctly.
* demux: make demux_open() privatewm42019-09-191-3/+0
| | | | | | | | | | I always wanted to get rid of this, because it makes the ownership rules for the stream pointer really awkward. demux_edl.c was the only remaining user of this. Replace it with a semi-clever idea: the init segment shit can be used to pass the "file" contents as memory block, and "memory://" itself provides an empty stream. I have no idea if this actually works, because I didn't immediately find a test stream (would have to be some youtube DASH shit).
* demux: simplify API for returning cache statuswm42019-09-191-10/+3
| | | | | | | | Instead of going through those weird DEMUXER_CTRLs, query this information directly. I'm not sure which kind of brain damage made me use CTRLs for these. Since there are no other DEMUXER_CTRLs that make sense for the frontend, remove the remaining infrastructure for them too.
* demux: return stream file size differently, rip out stream ctrlswm42019-09-191-5/+1
| | | | | | | The stream size return was the only thing that still required doing STREAM_CTRLs from frontend through the demuxer layer. This can be done much easier, so rip it out. Also rip out the now unused infrastructure for STREAM_CTRLs via demuxer layer.
* demux: return packets directly from demuxer instead of using sh_streamwm42019-09-191-2/+5
| | | | | | | Preparation for other potential changes to separate demuxer cache/thread and actual demuxers. Most things are untested, but it seems to work somewhat.
* command, demux: remove program propertywm42019-09-131-5/+0
| | | | | | | | | The "program" property could switch between TS programs. It was rather complex and rather obscure (even if you deal with TS captures, you usually don't need it). If anyone actually needs it (did anyone ever attempt to even use it?), it should be rewritten. The demuxer should export a program list, and the frontend should handle the "cycling" logic.
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Linux analog TV support (via tv://) was excessively complex, and whenever I attempted to use it (cameras or loopback devices), it didn't work well, or would have required some major work to update it. It's very much stuck in the analog past (my favorite are the frequency tables in frequencies.c for analog TV channels which don't exist anymore). Especially cameras and such work fine with libavdevice and better than tv://, for example: mpv av://v4l2:/dev/video0 (adding --profile=low-latency --untimed even makes it mostly realtime) Adding a new input layer that targets such "modern" uses would be acceptable, if anyone is interested in it. The old TV code is just too focused on actual analog TV. DVB is rather obscure, but has an active maintainer, so don't remove it. However, the demux/stream ctrl layer must go, so remove controls for channel switching. Most of these could be reimplemented by using the normal method for option runtime changes.
* Remove optical disc fancification layerswm42019-09-131-1/+0
| | | | | | | | | | | | | | | | | This removes anything related to DVD/BD/CD that negatively affected the core code. It includes trying to rewrite timestamps (since DVDs and Blurays do not set packet stream timestamps to playback time, and can even have resets mid-stream), export of chapters, stream languages, export of title/track lists, and all that. Only basic seeking is supported. It is very much possible that seeking completely fails on some discs (on some parts of the timeline), because timestamp rewriting was removed. Note that I don't give a shit about optical media. If you want to watch them, rip them. Keeping some bare support for DVD/BD is the most I'm going to do to appease the type of lazy, obnoxious users who will care. There are other players which are better at optical discs.
* demux: remove some dead codewm42018-12-061-2/+0
| | | | | No idea what that shit is. Likely forgotten when timed metadata was introduced, and some of the old mechanisms were replaced.
* demux: add another stream recording featurewm42018-12-061-0/+1
| | | | | | --record-file is nice, but only sometimes. If you watch some sort of livestream which you want to record, it's actually much nicer not to record what you're currently "seeing", but anything you're receiving.
* demux, stream: readd cache-speed in some other formwm42018-12-061-0/+4
| | | | it's more like an input speed rather than a cache speed, but who cares.
* demux, stream: rip out the classic stream cachewm42018-08-311-2/+1
| | | | | | The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
* demux: add a way to destroy the demuxer asynchronouslywm42018-05-241-0/+5
| | | | | | | | | | | | | | This will enable the player core to terminate the demuxers in a "nicer" way without having to block on network. If it just used demux_free(), it would either have to block on network, or like currently, essentially kill all I/O forcefully. The API is slightly awkward, because demuxer lifetime is bound to its allocation. On the other hand, changing that would also be awkward, and introduce weird in-between states that would have to be handled in tons of places. Currently unused, to be user later.
* player: some further cleanup of the mp_cancel crapwm42018-05-241-0/+1
| | | | | | | | | | Alway give each demuxer its own mp_cancel instance. This makes management of the mp_cancel things much easier. Also, instead of having add/remove functions for mp_cancel slaves, replace them with a simpler to use set_parent function. Remove cancel_and_free_demuxer(), which had mpctx as parameter only to check an assumption. With this commit, demuxers have their own mp_cancel, so add demux_cancel_and_free() which makes use of it.
* demux: get rid of free_demuxer[_and_stream]()wm42018-05-241-2/+2
| | | | | | | Them being separate is just dumb. Replace them with a single demux_free() function, and free its stream by default. Not freeing the stream is only needed in 1 special case (demux_disc.c), use a special flag to not free the stream in this case.
* command: whitelist some blocking accesses for certain demuxers/streamswm42018-05-241-0/+1
| | | | | | | | | | | | | | | | | | | | | The properties/commands touched in this commit are all for obscure special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream layer. For network streams, this blocking is very unwelcome. They will affect playback and probably introduce pauses and frame drops. The player can even freeze fully, and the logic that tries to make playback abortable even if frozen complicates the player. Since the mentioned accesses are not needed for network streams, but they will block on network streams even though they're going to fail, add a flag that coarsely enables/disables these accesses. Essentially it establishes a whitelist of demuxers/streams which support them. In theory you could to access BD/DVD images over network (or add such support, I don't think it's a thing in mpv). In these cases these controls still can block and could even "freeze" the player completely. Writing to the "program" and "cache-size" properties still can block even for network streams. Just don't use them if you don't want freezes.
* demux: add a "cancel" fieldwm42018-05-241-0/+3
| | | | | Instead of relying on demuxer->stream->cancel. This is better because the stream is potentially closed and replaced.
* demux: support for some kinds of timed metadatawm42018-04-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes ICY title changes show up at approximately the correct time, even if the demuxer buffer is huge. (It'll still be wrong if the stream byte cache contains a meaningful amount of data.) It should have the same effect for mid-stream metadata changes in e.g. OGG (untested). This is still somewhat fishy, but in parts due to ICY being fishy, and FFmpeg's metadata change API being somewhat fishy. For example, what happens if you seek? With FFmpeg AVFMT_EVENT_FLAG_METADATA_UPDATED and AVSTREAM_EVENT_FLAG_METADATA_UPDATED we hope that FFmpeg will correctly restore the correct metadata when the first packet is returned. If you seke with ICY, we're out of luck, and some audio will be associated with the wrong tag until we get a new title through ICY metadata update at an essentially random point (it's mostly inherent to ICY). Then the tags will switch back and forth, and this behavior will stick with the data stored in the demuxer cache. Fortunately, this can happen only if the HTTP stream is actually seekable, which it usually is not for ICY things. Seeking doesn't even make sense with ICY, since you can't know the exact metadata location. Basically ICY metsdata sucks. Some complexity is due to a microoptimization: I didn't want additional atomic accesses for each packet if no timed metadata is used. (It probably doesn't matter at all.)
* demux: add a per stream wakeup callbackwm42018-01-301-0/+2
| | | | | | | | | | This is supposed to help making data flow easier and wakeup handling more efficient. Once that change is done, reading a packet on any stream won't have to wakeup and poll all decoders (which helps reducing the mess even if all decoders are on the same thread). This also improves the accuracy of wakeups by tracking better whether a wakeup is needed.
* demux: reword an outdated commentwm42018-01-181-2/+1
|
* player: redo hack for video keyframe seeks with external audiowm42018-01-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | If you play a video with an external audio track, and do backwards keyframe seeks, then audio can be missing. This is because a backwards seek can end up way before the seek target (this is just how this seek mode works). The audio file will be seeked at the correct seek target (since audio usually has a much higher seek granularity), which results in silence being played until the video reaches the originally intended seek target. There was a hack in audio.c to deal with this. Replace it with a different hack. The new hack probably works about as well as the old hack, except it doesn't add weird crap to the audio resync path (which is some of the worst code here, so this is some nice preparation for rewriting it). As a more practical advantage, it doesn't discard the audio demuxer packet cache. The old code did, which probably ruined seeking in youtube DASH streams. A non-hacky solution would be handling external files in the demuxer layer. Then chaining the seeks would be pretty easy. But we're pretty far from that, because it would either require intrusive changes to the demuxer layer, or wouldn't be flexible enough to load/unload external files at runtime. Maybe later.
* demux: export some debugging fields about low level demuxer behaviorwm42018-01-051-0/+3
| | | | | | | | | | 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.
* player: update duration based on highest timestamp demuxedwm42017-12-241-0/+1
| | | | | | | | This will help with things like livestreams. As a minor detail, subtitles are excluded, because they sometimes have "unused" events after video and audio ends. To avoid this annoying corner case, just ignore them.
* player: allow seeking in cached parts of unseekable streamswm42017-12-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change and before the seekable stream cache became a thing, we could possibly seek using the stream cache. But we couldn't know whether the seek would succeed. We knew the available byte range, but could in general not tell whether a demuxer would stay within the range when trying to seek to a specific time position. We preferred to have safe defaults, so seeking in streams that were detected as unseekable were not honored. We allowed overriding this via --force-seekable=yes, in which case it depended on your luck whether the seek would work, or the player crapped its pants. With the demuxer packet cache, we can tell exactly whether a seek will work (at least if there's only 1 seek range). We can just let seeks go through. Everything to allow this is already in place, and this commit just moves around some minor things. Note that the demux_seek() return value was not used before, because low level (i.e. network level) seeks are usually asynchronous, and if they fail, the state is pretty much undefined. We simply repurpose the return value to signal whether cache seeking worked. If it didn't, we can just resume playback normally, because demuxing continues unaffected, and no decoder are reset. This should be particularly helpful to people who for some reason stream data into stdin via streamlink and such.
* demux_timeline: disable pointless packet cache for sub-demuxerswm42017-12-101-0/+2
| | | | | | | | | | | | | | | | | It seems like there's nothing stopping from sub-demuxers from keeping packets in the cache, even if it's completely pointless. The top-most demuxer (demux_timeline) already takes care of caching, so sub-demuxers only waste space and time with this. Add a function that can disable the packet cache even at runtime and after packets are read. (It's not clear whether it really can happen that packets are read before demux_timeline gets the sub-demuxers, but there's no reason to make it too fragile.) Call it on all sub-demuxers. For this to work, it seems we have to move the code for setting the seekable_cache flag to before demux_timeline is potentially initialized, because otherwise the cache would be reenabled if the demuxer triggering timeline support is a timeline segment itself (e.g. ordered chapters).
* demux: export demuxer cache sizes in byteswm42017-11-101-0/+2
| | | | | | Plus sort of document them, together with the already existing undocumented fields. (This is mostly for debugging, so use is discouraged.)
* demux: support multiple seekable cached rangeswm42017-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, the demuxer cache was limited to a single range. Extend this to multiple range. Should be useful for slow network streams. This commit changes a lot in the internal demuxer cache logic, so there's a lot of room for bugs and regressions. The logic without demuxer cache is mostly untouched, but also involved with the code changes. Or in other words, this commit probably fucks up shit. There are two things which makes multiple cached ranges rather hard: 1. the need to resume the demuxer at the end of a cached range when seeking to it 2. joining two adjacent ranges when the lowe range "grows" into it (and resuming the demuxer at the end of the new joined range) "Resuming" the demuxer means that we perform a low level seek to the end of a cached range, and properly append new packets to it, without adding packets multiple times or creating holes due to missing packets. Since audio and video never line up exactly, there is no clean "cut" possible, at which you could resume the demuxer cleanly (for 1.) or which you could use to detect that two ranges are perfectly adjacent (for 2.). The way how the demuxer interleaves multiple streams is also unpredictable. Typically you will have to expect that it randomly allows one of the streams to be ahead by a bit, and so on. To deal with this, we have heuristics in place to detect when one packet equals or is "behind" a packet that was demuxed earlier. We reuse the refresh seek logic (used to "reread" packets into the demuxer cache when enabling a track), which checks for certain packet invariants. Currently, it observes whether either the raw packet position, or the packet DTS is strictly monotonically increasing. If none of them are true, we discard old ranges when creating a new one. This heavily depends on the file format and the demuxer behavior. For example, not all file formats have DTS, and the packet position can be unset due to libavformat not always setting it (e.g. when parsers are used). At the same time, we must deal with all the complicated state used to track prefetching and seek ranges. In some complicated corner cases, we just give up and discard other seek ranges, even if the previously mentioned packet invariants are fulfilled. To handle joining, we're being particularly dumb, and require a small overlap to be confident that two ranges join perfectly. (This could be done incrementally with as little overlap as 1 packet, but corner cases would eat us: each stream needs to be joined separately, and the cache pruning logic could remove overlapping packets for other streams again.) Another restriction is that switching the cached range will always trigger an asynchronous low level seek to resume demuxing at the new range. Some users might find this annoying. Dealing with interleaved subtitles is not fully handled yet. It will clamp the seekable range to where subtitle packets are.
* demux: refactor to export seek rangeswm42017-10-301-7/+12