summaryrefslogtreecommitdiffstats
path: root/demux/demux.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: factor out a some packet queue codewm42019-09-191-11/+22
| | | | | Might be helpful for later. The "duplicated" ds->reader_head check above the function call is redundant, but leaving it also for later.
* demux: fix typos in commentswm42019-09-191-2/+2
| | | | How does this happen?
* player: add --demuxer-cache-wait optionwm42019-09-191-0/+11
|
* demux: fix typo in a commentwm42019-09-191-2/+2
|
* demux: fix SEEK_FORWARD into end of cached rangewm42019-09-191-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes that there were weird delay ("buffering") when seeking into the last part of a seekable range. The exact case which triggers it if SEEK_FORWARD is used, and the seek pts is after the second-last keyframe, but before the end of the range. In that case, find_seek_target() returned NULL, and the cache layer waited until the _next_ keyframe the underlying demuxer returned until resuming playback. find_seek_target() returned NULL, because the last keyframe had kf_seek_pts unset. This field contains the lowest PTS in the packet range from the keyframe until the next keyframe (or EOF). For normal seeks, this is needed because keyframes don't necessarily have the minimum PTS in the packet range, so it needs to be computed by waiting for all packets until the next keyframe (or EOF). Strictly speaking, this behavior was correct, but it meant that the caller would set ds->skip_to_keyframe, which waits for the next newly demuxed keyframe. No packets were returned to the decoder until this happened, usually resulting in the frontend entering "buffering" mode. What it really needs to do is returning the last keyframe in the cache. In this situation, the seek target points in the middle of the last completely cached packet range (as delimited by keyframes), and SEEK_FORWARD is supposed to skip to the next keyframe. This is in line with the basic assumptions the packet cache makes (e.g. the keyframe flag means it's possible to start decoding, and the frames decoded from it and following packets will strictly have PTS values above the previous keyframe range). This means in this situation the kf_seek_pts value doesn't matter either. So fix this situation by explicitly detecting it and then returning the last cached keyframe. Should the search loop look at all packets, instead of only keyframe ones? This would mean it can know that it's within the last keyframe range (without looking at queue->seek_end). Maybe this would be a bit more natural for the SEEK_FORWARD case, but due to PTS reordering it doesn't sound like a useful thing to do. Should skip_to_keyframe be checked by the code that sets kf_seek_pts to a known value? This wouldn't help too much; the frontend would still go into "buffering" mode for no reason until the packet range is completed, although it would resume from the correct range. Should a NULL return always unconditionally use keyframe_latest? This makes sense because the seek PTS is usually already in the cached range, so this is the only case that should happen. But there are scary special cases, like sparse subtitle streams, or other uses of find_seek_target() which could be out of range now or in future. Basically, don't "risk" it. One other potential problem with this is that the "adjust seek target" code will be disabled in this case. It checks kf_seek_pts, and if it's unset, the adjustment is not done. Maybe this could be changed to use the queue's seek_end time, but I'm not sure if this is fully kosher. On the other hand, I think the main use for this adjustment is with backwards seeks, so this shouldn't matter. A previous commit dealing with audio/video stream merging mentioned how seeking forward entered "buffering" mode for unknown reasons; this commit fixes this issue.
* demux_timeline: report network speed of slave connectionswm42019-09-191-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+29
| | | | | | | | | | | | 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: make demuxer list static, remove ancient commentwm42019-09-191-5/+1
| | | | | I'd actually very much encourage demuxer implementations outside problematic libavformat.
* demux: another unused functionwm42019-09-191-12/+0
|
* demux: autoselection is gonewm42019-09-191-8/+0
| | | | Was used by DVD, I think.
* demux: remove some more minor dead codewm42019-09-191-6/+4
| | | | Also add clarifications.
* demux: get rid of ->control callbackwm42019-09-191-2/+2
| | | | | | | | 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-21/+20
| | | | | | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | | | | | 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-121/+52
| | | | | | | | 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-36/+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.
* stream_libarchive: remove base filename stuffwm42019-09-191-18/+0
| | | | | | | | Apparently this was so that when playing a video file from a .rar file, it would load external subtitles with the same name (instead of looking for mpv's rar:// mangled URL). This was requested on github almost 5 years ago. Seems like a weird feature, and I don't care. Drop it, because it complicates some in progress change.
* demux: return packets directly from demuxer instead of using sh_streamwm42019-09-191-8/+12
| | | | | | | Preparation for other potential changes to separate demuxer cache/thread and actual demuxers. Most things are untested, but it seems to work somewhat.
* demux, stream: remove old rar support in favor of libarchivewm42019-09-131-1/+0
| | | | | | The old rar code could do uncompressed rar, libarchive supports at least some rar compression algorithms. There is no need to keep the old rar code.
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-131-4/+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-3/+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: ignore forced demuxer type for directoriesTom Yan2019-09-021-1/+1
| | | | this for example allows --demuxer=rawaudio to work on directories
* Merge branch 'master' into pr6360Jan Ekström2019-03-111-2/+7
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * demux: fix seek range update after head packets are prunedGunnar Marten2019-03-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | The seek range update was to early and did not take the removed head packets into account. And therefore missed that the queue was not BOF anymore. This led to not be able to backward seek before the first packet of the first seek range. Fix it by moving the seek range update after the possible removal and the change of the BOF flag. Fixes: #6522
| * demux: make ALBUM ReplayGain tags optional when using libavformatBenjamin Barenblat2019-01-161-0/+5
| | | | | | | | | | | | | | Commit e392d6610d1e35cc0190c794c151211b0aae83e6 modified the native demuxer to use track gain as a fallback for album gain if the latter is not present. This commit makes functionally equivalent changes in the libavformat demuxer.
* | demux: fix regression in decision about stream cachingsfan52018-12-061-1/+1
| | | | | | | | | | The `streaming` flag covers more cases than just networked streams, such as files read from NFS, SMB or FUSE mountpoints.
* | demux: fix memleak in allocation with params=NULLNiklas Haas2018-12-061-1/+1
| | | | | | | | | | The default behavior for `does not own stream` should be false, but this condition is inverted so we need to default the base case to `true`.
* | demux: fix some theoretical UB with no impactwm42018-12-061-2/+4
| | | | | | | | | | | | If the number of chapters is 0, the chapter list can be NULL. clang complains that we pass NULL to qsort(). This is yet another pointless UB that exists for no reason other than wasting your time.
* | demux: remove some dead codewm42018-12-061-8/+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/+40
| | | | | | | | | | | | --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-1/+32
| | | | | | | | it's more like an input speed rather than a cache speed, but who cares.
* | Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-60/+175
|\ \ | |/ |/| | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-311-33/+21
| | | | | | | | | | | | 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: allow cache sizes > 2GBwm42018-08-241-4/+8
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
| * demux: add a way to destroy the demuxer asynchronouslywm42018-05-241-8/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+23
| | | | | | | | | | | | | | | | | | | | 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-15/+16
| | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | Instead of relying on demuxer->stream->cancel. This is better because the stream is potentially closed and replaced.
| * misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | It seems a bit inappropriate to have dumped this into stream.c, even if it's roughly speaking its main user. At least it made its way somewhat unfortunately to other components not related to the stream or demuxer layer at all. I'm too greedy to give this weird helper its own file, so dump it into thread_tools.c. Probably a somewhat pointless change.
| * demux: late streams on start shouldn't restrict the seek rangewm42018-05-241-1/+9
| | | | | | | | | | | | If a stream starts later than the others at the start of the file, it shouldn't restrict the seek range to the time stamp where it begins. This is similar to the previous commit, just for the other end.
| * demux: streams that reached EOF shouldn't restrict the seek rangewm42018-05-241-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, the seek range is the minimum overlap of the cached ranges of each stream. But if one of the streams ends earlier, this leads to the seek range getting cut off, even if you could seek there. Change it so that EOF streams cannot restrict the end of the seek range. They can only extend it. This is the opposite from not-EOF streams, so they need to be handled separately. In particular, they get exluded from normal end range calculation, but when full EOF is reached, all streams are EOF, and the maximum end time can be used to set the seek end time. (In theory we could also take the max with the demuxer signaled total file duration, but let's not for now.) Also, if a stream is completely empty, essentially skip it, instead of considering the range unseekable. (Also, we don't need to mess with seek_start in this case, because it will be NOPTS and is skipped anyway.)
| * demux: fix/improve aspects of EOF signalingwm42018-05-241-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current packet queue was completely empty, and EOF was reached, the queue->is_eof flag was not correctly set to true. Change this by reading ds->eof to check whether the stream is considered EOF. We also need to make sure update_seek_ranges() is called in this case, so change the code to simply call it when queue->is_eof changes. Also, read_packet() needs to call adjust_seek_range_on_packet() if ds->eof changes. In that case, the decoder also needs to be notified about EOF. So both of these should be called when ds->eof changes to true. (Other code outside of this function deals with the case when ds->eof is changed to false.) In addition, this code was kind of shoddy about calling wakeup_ds() correctly. It looks like there was an inverted condition, and sent a wakeup to the decoder only when ds->eof was already true, which is obviously bogus. The final EOF case tried to be somehow clever about checking in->last_eof for notifying the codec, which is sort of OK, but seems to be strictly worse than just checking whether ds->eof changed. Fix these things.
* | demux: allow cache sizes > 2GBwm42018-10-011-4/+9
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
* | demux: fix/improve aspects of EOF signalingwm42018-05-251-9/+14
|/ | | | | | | | | | | |