summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* tv: Recognise v4l2 'JPEG' fourccPhilip Langdale2018-03-041-1/+1
| | | | | | | | | | | | | Naturally, there's more than one fourcc that indicates an mjpeg stream. I have a particular ancient webcam here (Logitech QuickCam Messanger) that only supports the single 'JPEG' format, but there are other devices out there which support both 'JPEG' and 'MJPG' with no visible differences, and others where the streams are slightly different. Regardless of those details, it remains correct to treat 'JPEG' the same as 'MJPG' from a stream consumption perspective.
* demux_lavf: add some hacks for SDPwm42018-03-031-0/+6
| | | | | | | Just the usual guess-what-opaque-ffmpeg-thing-supports. See #5550. It looks like we can reduce packet drop by having the cache enabled automatically.
* demux_lavf: add --demuxer-lavf-probe-info=nostreamswm42018-03-031-3/+6
| | | | Another attempt to try to make it behave in certain 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_lavf: don't mess up in streams with unknown size and init segmentwm42018-03-031-1/+2
| | | | | The return value of stream_get_size() will be -1 if it fails. We shouldn't mess up this value if a mp4 init segment is used.
* demux_mkv: enable libavcodec parser for eac3wm42018-03-031-1/+1
| | | | | | | | | | | | | | It appears some (or all) mkv files with EAC3 are muxed in a way that breaks FFmpeg's spdifenc. I suspect it's because either dependent substream packets are localted in their own packets, or the reverse. Or possibly this is case where the muxer did not respect packet boundaries at all. Enabling the EAC3 parser seems to fix this anyway, because why waste your precious time on retarded Dolby bullshit technology? (Which idiot came up with this shitty substream garbage?) Observed with dolby_digital_plus_channel_check_lossless-DWEU.mkv. Fixes #5578.
* demux_edl: fix undefined behavior if mp4 init segment is not providedwm42018-03-031-1/+1
| | | | param_names[n] is only valid for n<nparam.
* Fix recent FFmpeg deprecationswm42018-02-131-2/+3
| | | | | | | | | This includes codec/muxer/demuxer iteration (different iteration function, registration functions deprecated), and the renaming of AVFormatContext.filename to url (plus making it a malloced string). Libav doesn't have the new API yet, so it will break. I hope they will add the new APIs too.
* 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.
* Revert "demux_mkv: remove remaining GPL code"wm42018-01-311-1/+4
| | | | | | | | This reverts commit b7f90be567c3c19eb3fec30be2b76775296a6ed1. The author agreed to the relicensing now (if that code is affected by the original copyright at all - that was the only line possibly left of it).
* cue: strip quotes and leading whitespace from tagswm42018-01-301-2/+10
| | | | | | | | If tags like TITLE have the whole parameter in " quotes, strip them. Also remove the leading whitespace, since even with a single space it was always included. Fixes #5462.
* video: make decoder wrapper a filterwm42018-01-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
* demux: add a per stream wakeup callbackwm42018-01-302-13/+56
| | | | | | | | | | 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_lavf: work around another aspect of libavformat garbage APIwm42018-01-261-1/+6
| | | | | | | | | | | | | | | | AV_DISPOSITION_ATTACHED_PIC usually means the video track isn't real, and merely reflects the presence of an embedded image in tag data (such as ID3v2 tags), with some inconsistent hack to make libavformat return it as video packet once. Except it doesn't mean that. It can be randomly set on other streams that do sort of behave like video streams, such as chapter thumbnail tracks in mp4 files. AV_DISPOSITION_TIMED_THUMBNAILS is set in these cases. In theory, there can supposedly be more such cases, but only the chapter thumbnail one currently exists. So add it as exception. This restores displaying these thumbnails as video frames, for better or worse. (Before, only the first thumbnail was displayed.)
* demux_lavf: export correct seekability state for HLS live streamswm42018-01-261-0/+5
| | | | | | | Requires newest FFmpeg git, which has a change that makes the HLS demuxer set an AVFMTCTX_UNSEEKABLE flag if seeking is not available, which is the case for HLS live streams. This should make the player frontend behave pretty well, instead of crapping up irrecoverably.
* 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.)
* video: warn user against FFmpeg's lieswm42018-01-221-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found that at least for mjpeg streams, FFmpeg will set packet pts/dts anyway. The mjpeg raw video demuxer (along with some other raw formats) has a "framerate" demuxer option which defaults to 25, so all mjpeg streams will be played at 25 FPS by default. mpv doesn't like this much. If AVFMT_NOTIMESTAMPS is set, it prints a warning, that might print a bogus FPS value for the assumed framerate. The code was originally written with the assumption that FFmpeg would not set pts/dts for such formats, but since it does, the printed estimated framerate will never be used. --fps will also not be used by default in this situation. To make this hopefully less confusing, explicitly state the situation when the AVFMT_NOTIMESTAMPS flag is set, and give instructions how to work it around. Also, remove the warning in dec_video.c. We don't know what FPS it's going to assume anyway. If there are really no timestamps in the stream, it will trigger our normal missing pts workaround. Add the assumed FPS there. In theory, we could just clear packet timestamps if AVFMT_NOTIMESTAMPS is set, and make up our own timestamps. That is non-trivial for advanced video codecs like h264, so I'm not going there. For seeking and buffering estimation the situation thus remains half-broken. This is a mitigation for #5419.
* ta: introduce talloc_dup() and use it in some placeswm42018-01-182-5/+4
| | | | | | | 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.
* demux: reword an outdated commentwm42018-01-181-2/+1
|
* player: redo hack for video keyframe seeks with external audiowm42018-01-182-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | 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_lavf: add required format hacks for DASHsfan52018-01-151-0/+1
|
* 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_null: mark as seekablewm42018-01-061-0/+1
| | | | | | No reason not to, and enables some strange constructions with --external-file (although the result is not too smooth for certain reasons).
* 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-052-3/+25
| | | | | | | | | | 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.
* demux: fix crash due to incorrect seek range accountingwm42018-01-051-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | update_seek_ranges() has some special code that attempts to correctly adjust seek ranges for subtitle tracks. (Subtitle are a nightmare for seek ranges, because they are sparse, so using the packet list is not enough to reliably determine the valid cached range.) This had code like this inside the modified if statement: range->seek_start = MP_PTS_MAX(range->seek_start, <something>); If seek_start is NOPTS, then seek_start will be set to <something>, breaking some other code that checks seek_start for NOPTS to see if it's empty. Fix this by explicitly checking whether seek_start is NOPTS before adjusting it. The crash happened in prune_old_packets() because the range was marked as non-empty, yet there was no packet in it to prune. This was with files with muxed subtitles, when seeking back to the start. This should not happen anymore with the change. Also add an assert() to check_queue_consistency() that checks for this specific case. There's still some mess. In theory, subtitle tracks could be completely empty, yet their seek range would span the entire file. Seek range tracking of subtitle files is slightly broken (even before this change). Some of this should probably be revisited later, including not just using seek_start to determine whether a seek range should be pruned due to being empty.
* demux_mkv: fix x264 hack if video track uses header compressionwm42017-12-301-1/+7
| | | | | | | | | | | | The x264 hack requires reading the first video packet, which in turn we handle with a hack in demux_mkv.c to get the packet without having to add special crap to demux.c. Another useless MKV feature (which they enabled by default at one point and which caused many demuxers to break completely, only to disable it again when it was too late) conflicts with this, because we actually pass a block as packet contents, instead of after "decompression". Fix this by calling demux_mkv_decode().
* demux_mkv: add hack to pass along x264 version to decoderwm42017-12-282-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes when resuming certain broken h264 files encoded by x264. See FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264 bug itself. Normally, the unregistered user data SEI (that contains the x264 version string) is informational only. But libavcodec uses it to workaround a x264 bug, which was recently fixed in both libavcodec and x264. The fact that both encoder and decoder were buggy is the reason that it was not found earlier, and there are apparently a lot of files around created by the broken decoder. If libavcodec sees the SEI, this bug can be worked around by using the old behavior. If you resume a file with mpv (i.e. seeking when the file loads), libavcodec never sees the first video packet. Consequently it has to assume the file is not broken, and never applies the workaround, resulting in garbage being played. Fix this by always feeding the first video packet to the decoder on init, and then flushing the codec (to avoid that an unwanted image is output). Flushing the codec does not remove info such as the x264 version. We also abuse the fact that the first avcodec_send_packet() always pushes the frame into the decoder (so we don't have to trigger the decoder by requsting an output frame).
* demux_mkv: maintain a small packet read queuewm42017-12-281-22/+39
| | | | | This is less of a mess than the single-item queue in tmp_block, and also might help us in the future.
* player: update duration based on highest timestamp demuxedwm42017-12-242-0/+24
| | | | | | | | This will help with things like livestreams. As a minor detail, subtitles are excluded, because they sometimes have "unused" events after video and audio ends. To avoid this annoying corner case, just ignore them.
* player: allow seeking in cached parts of unseekable streamswm42017-12-242-21/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change and before the seekable stream cache became a thing, we could possibly seek using the stream cache. But we couldn't know whether the seek would succeed. We knew the available byte range, but could in general not tell whether a demuxer would stay within the range when trying to seek to a specific time position. We preferred to have safe defaults, so seeking in streams that were detected as unseekable were not honored. We allowed overriding this via --force-seekable=yes, in which case it depended on your luck whether the seek would work, or the player crapped its pants. With the demuxer packet cache, we can tell exactly whether a seek will work (at least if there's only 1 seek range). We can just let seeks go through. Everything to allow this is already in place, and this commit just moves around some minor things. Note that the demux_seek() return value was not used before, because low level (i.e. network level) seeks are usually asynchronous, and if they fail, the state is pretty much undefined. We simply repurpose the return value to signal whether cache seeking worked. If it didn't, we can just resume playback normally, because demuxing continues unaffected, and no decoder are reset. This should be particularly helpful to people who for some reason stream data into stdin via streamlink and such.
* demux_mkv: fix off by one errorwm42017-12-231-3/+1
| | | | | | | | | | | | Caused by the relatively recent change to packet parsing. This time it was probably triggered by lace type 0, which reduces the byte length of a 0 sized packet to 3 (timestamp + flag) instead of 4 (lace count for other lace types). The thing about laces is just my guess why it worked for other 0 sized packets, though. Also remove the redundant and now incorrect check below. Fixes #5271.
* demux: note refresh state separately in debug outputwm42017-12-231-5/+5
| | | | | | | This log line tells us why the demuxer is trying to read more, which us useful when debugging queue overflows. Probably barely useful, but I think keeping that flag separately also makes the code slightly easier to understand.
* demux: bump the demuxer cache readahead durationwm42017-12-231-1/+1
| | | | | | Set it to 10 hours, which is practically unlimited. (Avoiding use of "inf", since that might interact strangely with the option parser and such.)
* demux: always discard cached packets on track switcheswm42017-12-231-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes weird behavior in the following case: - open a file - make sure the max. demuxer forward cache is smaller than the file's video track - make sure the max. readahead duration is larger than the file's duration - disable the audio track - seek to the beginning of the file - once the cache has filled enable the audio track - a queue overflow warning should appear (- looking at the seek ranges is also interesting) The queue overflow warning happens because the packed queue for the video track will use up the full quota set by --demuxer-max-bytes. When the audio track is enabled, reading an audio packet would technically overflow the packet cache by the size of whatever packet is read next. This means the demuxer signals EOF to the decoder, and once playback has consumed enough video packets so that audio packets can be read again, the decoder resumes from EOF. This interacts badly with A/V synchronization and the whole thing can randomly crap itself until audio has fully recovered. We didn't care about this so far, but we want to raise the readahead duration to something very high, so that the demuxer cache is fully used. This means this case can be hit quite quickly by switching audio or subtitle tracks, and is not really an obscure corner case anymore. Fix this by always losing all cache. Since the cache can't be used anyway until the newly selected track has been read, this is not much of a disadvantage. The only thing that could be brought up is that unselecting the track again could resume operation normally. (Maybe this would be useful if network died completely without chance of recovery. Then you could watch the already buffered video anyway by deselecting the audio track again.) But given the headaches, this seems like the better solution. Unfortunately this requires adding new new strange fields and strangely fragmenting state management functions again. I'm sure whoever works on this in the future will hate me. Currently it seems like the lesser evil, and much simpler and robust than the other potential solutions. In case this needs to be revisited, here is a reminder for readers from the future what alternative solutions were considered, without those disadvantages: A first attempted solution allowed the demuxer to buffer some additional packets on track switching. This would allow it to read enough data to feed the decoder at least. But it was still awkward, as it didn't allow the demuxer to continue prefetching the newly selected track. It also barely worked, because you could make the forward buffer "over full" by seeking back with seekable cache enabled, and then it couldn't read packets anyway. As alternative solution, we could always demux and cache all tracks, even if they're deselected. This would also not require a network-level seek for the "refresh" logic (it's the thing that lets the video decoder continue as if nothing happened, while actually seeking back in the stream to get the missing audio packets, in the case of enabling a previously disabled audio track). But it would also possibly waste network and memory resources, depending on what the user actually wants. A second solution would just account the queue sizes for each stream separately. We could freely fill up the audio packet queue, even if the video queue is full. Since the demuxer API returns interleaved packets and doesn't let you predict which packet type comes next, this is not as simple as it sounds, but it'd probably tie in nicely with the "refresh" logic. A third solution would be removing buffered video packets from the end of the packet queue. Since the "refresh" logic gets these anyway, there is no reason to keep them if they prevent the audio packet queue from catching up with the video one. But this would require additional logic, would interact badly with a bunch of other corner cases. And as far as the code goes, it's rather complex, because all the logic is written with FIFO behavior in mind (including the fact that the packet queue is a singly linked list with no backwards links, making removal from the end harder).
* demux_timeline: disable pointless packet cache for sub-demuxerswm42017-12-103-8/+35
| | | | | | | | | | | | | | | | | It seems like there's nothing stopping from sub-demuxers from keeping packets in the cache, even if it's completely pointless. The top-most demuxer (demux_timeline) already takes care of caching, so sub-demuxers only waste space and time with this. Add a function that can disable the packet cache even at runtime and after packets are read. (It's not clear whether it really can happen that packets are read before demux_timeline gets the sub-demuxers, but there's no reason to make it too fragile.) Call it on all sub-demuxers. For this to work, it seems we have to move the code for setting the seekable_cache flag to before demux_timeline is potentially initialized, because otherwise the cache would be reenabled if the demuxer triggering timeline support is a timeline segment itself (e.g. ordered chapters).
*