summaryrefslogtreecommitdiffstats
path: root/demux/demux.h
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | Even though only 1 seek range is supported at the time. Other than preparation for possibly future features, the main gain is actually that we finally separate the reporting for the buffering, and the seek ranges. These can be subtly different, so it's good to have a clear separation. This commit also fixes that the ts_reader wasn't rebased to the start time, which could make the player show "???" for buffered cache amount in some .ts files and others (especially at the end, when ts_reader could become higher than ts_max). It also fixes writing the cache-end field in the demuxer-cache-state property: it checked ts_start against NOPTS, which makes no sense. ts_start was never used (except for the bug mentioned above), so get rid of it completely. This also makes it convenient to move the segment check for last_ts to the demux_add_packet() function.
* demux: drop redundant SEEK_BACKWARD flagwm42017-10-231-2/+2
| | | | | | | | | | | | | Seems like most code dealing with this was for setting it in redundant cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one out. Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache(). In demux_mkv_seek(), make the arbitrary decision that a video stream is not required for the subtitle prefetch logic to be active. We might want subtitles with long duration even with audio only playback, or if the file is used as external subtitle.
* command: read the diff if you want to knowwm42017-10-211-1/+1
|
* demux: add a back buffer and the ability to seek into itwm42017-10-211-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | This improves upon the previous commit, and partially rewrites it (and other code). It does: - disable the seeking within cache by default, and add an option to control it - mess with the buffer estimation reporting code, which will most likely lead to funny regressions even if the new features are not enabled - add a back buffer to the packet cache - enhance the seek code so you can seek into the back buffer - unnecessarily change a bunch of other stuff for no reason - fuck up everything and vomit ponies and rainbows This should actually be pretty usable. One thing we should add are some properties to report the proper buffer state. Then the OSC could show a nice buffer range. Also configuration of the buffers could be made simpler. Once this has been tested enough, it can be enabled by default, and might replace the stream cache's byte ringbuffer. In addition it may or may not be possible to keep other buffer ranges when seeking outside of the current range, but that would be much more complex.
* demux: change license to LGPLwm42017-06-201-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | As usual, the history of these files is a bit murky. It starts with the initial commit. (At which some development had already been done, according to the AUTHORS and ChangeLog files at the time, we should be but covered with relicensing agreements, though.) then it goes on with complete lack of modularization, which was cleaned up later (cd68e161). As usual, we don't consider the copyright of the stuff that has been moved out cleanly. There were also contributions to generic code by people who could not be reached or who did not agree to the relicensing, but this was all removed. The only patches that we could not relicense and which were still in the current code in some form are from Dénes Balatoni: 422b0d2a, 32937181. We could not reach him, so commits f34e1a0d and 18905298 remove his additions. It still leaves the demux_control() declaration itself, but we don't consider it copyrightable. It's basically an idiom that existed in MPlayer before that change, applied to the demuxer struct. (We even went as far as making sure to remove all DEMUXER_CTRLs the original author added.) Commit be54f481 might be a bit of a corner case, but this was rewritten, and we consider the old copyright removed long ago.
* demux: get rid of DEMUXER_CTRL_GET_TIME_LENGTHwm42017-06-201-3/+1
| | | | | | | | | | | | Similar purpose as f34e1a0deea45e. Somehow this is much more natural too, and needs less code. This breaks runtime updates to duration. This could easily be fixed, but no important demuxer does this anyway. Only demux_raw and demux_disc might (the latter for BD/DVD). For the latter it might actually have some importance when changing titles at runtime (I guess?), but guess what, I don't care.
* demux: replace custom return codes with CONTROL_ oneswm42017-06-191-5/+0
| | | | | | | | This is more uniform, and potentially gets rid of some past copyrights. It might be that this subtly changes caching behavior (it seems before this, it synced to the demuxer if the length was unknown, which is not what we want.)
* ytdl_hook, edl: implement pseudo-DASH supportwm42017-02-041-0/+2
| | | | | | | | | We use the metadata provided by youtube-dl to sort-of implement fragmented DASH streaming. This is all a bit hacky, but hopefully a makeshift solution until libavformat has proper mechanisms. (Although in danger of being one of those temporary hacks that become permanent.)
* player: remove --stream-capture option/propertywm42017-01-211-3/+0
| | | | | |