summaryrefslogtreecommitdiffstats
path: root/demux/demux.c
Commit message (Collapse)AuthorAgeFilesLines
* 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, unrelated streams, like the awful libavformat cover art hack. Fixes #5577.
* demux: lower demuxer cache default sizeswm42018-02-131-2/+2
| | | | | | | | | Reduce backward/forward from 400MB/400MB to 50MB/150MB. Too many complaints about high memory usage. Note that external tracks (like ytdl DASH with external audio tracks) will double the amounts, because an external track uses its own demuxer and cache.
* demux: add a per stream wakeup callbackwm42018-01-301-13/+54
| | | | | | | | | | 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.
* options: add an option type for byte sizeswm42018-01-251-4/+4
| | | | | | And use it for 2 demuxer options. It could be used for more options later. (Though the --cache options can not use this, because they use KB as base unit.)
* ta: introduce talloc_dup() and use it in some placeswm42018-01-181-2/+2
| | | | | | | It was actually already implemented as ta_dup_ptrtype(), but that seems like a clunky name. Also we still use the talloc_ names throughout the source, and I'd rather use an old name instead of a mixing inconsistent naming conventions.
* player: redo hack for video keyframe seeks with external audiowm42018-01-181-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | 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: include beginning of stream state in cached seekable rangewm42018-01-101-5/+19
| | | | | | | | | | | | Similar to 1eec7d2315, but for the beginning of the stream (named BOF in this commit). We can know this only if demuxing actually started from the beginning. If there is a seek to the beginning (even if you use --start=-1000), we don't know in general whether the demuxer truly returns the start of the file. We could probably make a heuristic with assuming that this is what happens if the seek target is before the start time or so, but this is not included in this commit.
* demux: fight libavformat cover art hack harderwm42018-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | libavformat's cover art hack (aka attached pictures) breaks the ability of the demuxer cache to keep multiple seek ranges. This happens because the cover art packet has neither position nor timestamp, and libavformat gives us the packet even though we intended to drop it. The cover art hack works by adding the cover art packet to the read packet stream once when demuxing starts (or after seeks). mpv treats cover art in a similar way internally, but we have to compensate for libavformat's shortcomings, and add the cover art packet ourselves when we need it. So we don't want libavformat to return the packet. We normally prevent this in demux_lavc.c/select_tracks() and explicitly disable cover art streams. (We add it in dequeue_packet() instead.) But libavformat will actually add the cover art packet even if we disable the cover art stream, because it adds it at initialization time, and does not bother to check again in av_read_frame() (apparently). The packet is actually read, and upsets the demuxer cache logic. In addition, this also means we probably decoded the cover art picture twice in some situations. Fix this by explicitly checking/discarding this in yet another place. (Screw this hack...)
* demux: add missing seekpoint when cached ranges are joinedwm42018-01-101-0/+8
| | | | | | | | The impact was that you couldn't exactly seek to the join point with a keyframe seek, even though there was a keyframe. This commit fixes it by preserving the necessary metadata that got lost on cached range joining. This is so absurdly obscure that it gets a longer code comment.
* demux: silence pointless/confusing warningwm42018-01-071-1/+1
| | | | | | | | | | | | | | | | | | | This warning was printed when the demuxer cache tried to join two adjacent seek ranges, but failed if the last keyframe in the second range was within the (overlapping) first range. This is a weird corner case which to support probably would not be worth it. So this code just printed a warning and discarded the second range. As it turns out, this can happen relatively often if you seek a lot, and the seek ranges are very tiny (such as consisting of only 1 keyframe). Dropping the second range in these cases is OK and probably cheaper than trying to actually join them. Change the warning to verbose level. (It seems this could actually be "supported", because if keyframe_latest is not set, there will be no other keyframes, so it could just be unset, with the exception that q1->keyframe_latest in the code below must not be overwritten. But still, too much trouble for a special case that likely does not matter, and it would have to be tested too.)
* demux: include EOF state in cached seekable rangewm42018-01-051-3/+20
| | | | | | | | | | | | | | | | | | | | | | This means if the user tries to seek past EOF, and we know EOF was seen already, then use a cached seek, instead of triggering a low level seek. This requires some annoying tracking, but seems pretty simple otherwise. One advantage of doing this is that if the user tries to do this kind of seek, there's no unnecessary waiting for a reaction by network (and in most cases, redundant downloading of data just to discard it again). Another is that this avoids creating overlapping seek ranges: previously, the low level seek would naturally create a new range. Then it would read and add data from the end of the stream due to the low level demuxer not being able to seek to the target and selecting the last seek point before the end of the stream. Consequently, this new range would overlap with the previous cached range. But since the cache joining code is written such that you join the current range with the _next_ range (instead of the previous as it would be needed in this case), the overlapping ranges were left alone, until seeking back to the previous range. That was ugly, sort of harmless, and could happen in other cases, but this avoidable case was pretty easy to trigger.
* demux: export some debugging fields about low level demuxer behaviorwm42018-01-051-3/+22
| |