summaryrefslogtreecommitdiffstats
path: root/demux/demux.h
<
Commit message (Collapse)AuthorAgeFilesLines
* demux: redo timed metadatawm42019-09-191-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: refactor cache range init/deinitwm42019-09-191-1/+0
| | | | | | | | | | | | | | | | | | | | Remove the duplicated creation of the first range. Explicitly destroy ranges, including the last one on final deinit. It looks like this also fixes a leak of removed range structs, which was never noticed because they're so small, and were freed on final deinit due to having the demuxer as talloc parent. This improves upon the previous commit too (that change should have been part of it I guess). Sub-demuxers (demux_timeline only) now automatically don't use the cache (like it was intended by the previous commit). The cache is "initialized" (or disabled) last in the recursive call chain, which is messy, but this sub demuxer stuff FUCKING SUCKS, as mentioned in the previous commit message. This would be no problem if the caching layer and actual demuxer implementations were separate. Most of this change has no purpose. Might make (de-)initialization of further cache exerpiments simpler.
* demux: really disable cache for sub-demuxerswm42019-09-191-0/+1
| | | | | | | | | | | | | | | | | | 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.
* 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 streams