summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-243-2/+10
| | | | | | | | | | | | | | | 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_lavf: co-locate disposition checksAman Gupta2018-05-241-2/+2
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux_mkv: adjust log verbosity levelswm42018-04-292-40/+41
| | | | | | | | | With -v -v ("debug" level), which is the default for --log-file, this would log every damn Matroska EBML element and some other uninteresting things, which was very noisy. Adjust the log levels to make them less noisy. Also, change some log calls to MP_ERR for things which are actually errors.
* demux_lavf: discard "und" language tagwm42018-04-291-1/+1
| | | | | | | | | Going by ISO 639.2, "und" means "Undetermined". Whatever it's supposed to mean, in practice it's user for "unset". We prefer if the language tag remains simply unset in this case. This removes an ugliness with mp4 in partricular, because libavformat will export unset languages as such, which affects most mp4 files.
* demux: support for some kinds of timed metadatawm42018-04-185-114/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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, player: mark dependent tracksAman Gupta2018-04-172-0/+3
| | | | | | | ffmpeg marks audio tracks which are not meant to be played standalone as DEPENDENT. these are typically used in DVB broadcasts for audio descriptions, and are meant to be mixed into the main audio track during playback.
* demux_lavf: use new libavformat semantics for stream resyncwm42018-04-161-17/+2
| | | | | | | | | | I changed avio_flush() and introduced avformat_flush() exactly for this reason. Used with DVD/BD only (on seeks and when setting the "angle" property). Seems to work, but wasn't tested too thoroughly (I don't care about optical discs, I only want this ugly stuff gone that might even violate the API/ABI).
* 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_mkv: fix certain cases of recursive SeekHeadswm42018-04-151-4/+1
| | | | | | | | | | | | | | | Some shittily muxed files (by a certain HandBrake+libavformat combo) contain a SeekHead pointing to a SeekHead at the end of the file, which in turn points to track headers (also at the end of the file). This failed because the demuxer didn't bother to actually read the elements listed by the second SeekHead, so no track headers were read, and playback broke. Somehow commit 6fe75c38 broke this for no reason. It adds a "needed" field, which seems completely pointless and replaced the "parsed" flag in an incomplete way. In particular, the "needed" field was not set when a _recursive_ SeekHead was read, so those elements were not read. Just get rid of the field and use "parsed" instead.
* demux_lavf: skip demuxer hack iteration if hacks are disabledsergey.dobrodey2018-04-121-3/+1
|
* demux_mkv: add V_AV1 identifier for AV1Jan Ekström2018-04-081-0/+1
| | | | | | | | | | | Quickly tested by a person who had FFmpeg linked with libaom. Seems as simple as the VP9 mappings, where there is no extradata/ initialization data off-band, and just stuff in the packets themselves. Do note that the AV1 video format itself at this point is still not frozen, so what you might produce one day might not be decodable the following day.
* 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.
* 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