summaryrefslogtreecommitdiffstats
path: root/demux/demux.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
|/ | | | | | | | | | | | | | | | | | | | | | 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, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-241-2/+4
| | | | | | | | | | | | | | | Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux: support for some kinds of timed metadatawm42018-04-181-107/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: mark eia608 packets as keyframesAman Gupta2018-04-171-0/+1
| | | | | | This fixes an issue where captions stop rendering after an in-demuxer-cache seek, because the demuxer keeps waiting to find a keyframe (ds->skip_to_keyframe set to true in execute_cache_seek).
* demux: fix deadlock on "program" property changeswm42018-04-151-0/+6
| | | | | Tries to recursively lock a non-recursive lock, which usually ends in a deadlock. Must have been broken by some past refactor.
* demux, stream: ignore packets and errors on forced exitwm42018-03-261-2/+2
| | | | | | | | | | When this happens, network calls are forcibly aborted (more or less), but demuxers might keep going, as most of them do not check for forced exits properly. This can possibly lead to broken packets being added. Also do not attempt to read more packets in this situation. Also do not print a stream open failed message if opening was aborted anyway.
* demux: fix comment typoAman Gupta2018-03-111-1/+1
|
* demux: correctly report buffered size as 0 if there are no packetswm42018-03-081-1/+1
| | | | | | | | | | Since the demuxer cache addition, ds->queue->head can actually be set to non-NULL, but the decoder can still be at EOF (with no packets to come). This made it report an unknown buffered size, instead of 0. Fix this by checking the decoder part of the packet queue instead. Probably doesn't matter much, but fixes an annoying "???" on the CLI status line in some situations.
* demux: move some code to a separate functionwm42018-03-031-33/+41
| | | | No functional changes.
* demux: improve audio tag merging for OGG fileswm42018-03-031-4/+17
| | | | | | | | | | | | | | It's a mess: mp3 files have user tags as global metadata (because the id3v2 tag is global and there is only 1 stream), while OGG files have it per-track (because it's per-stream on the lowest level). mpv needs to try to make something nice out of the mess. It did so by trying to detect audio-only OGG files, and then copying the per-stream metadata to the global metadata. Make the heuristic for detecting this slightly more clever, so it works for files with extra, un