summaryrefslogtreecommitdiffstats
path: root/demux/demux_lavf.c
Commit message (Collapse)AuthorAgeFilesLines
* demux_lavf: v4l streams are not seekablewm42018-08-241-0/+2
| | | | | | | FFmpeg is retarded enough not to give us any indication whether it is (unless we query fields not in the ABI/API). I bet FFmpeg developers love it when library users have to litter their code with duplicated information.
* demux_lavf: drop obscure genpts optionwm42018-05-241-5/+0
| | | | | This code shouldn't even exist in libavformat. If you still need it, you can enable it via --demuxer-lavf-o.
* demux: add a "cancel" fieldwm42018-05-241-2/+1
| | | | | 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_lavf: remove ffm blacklist entrywm42018-05-241-2/+0
| | | | ffm (ffserver) was removed from ffmpeg.
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-241-0/+5
| | | | | | | | | | | | | | | 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_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-181-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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, player: mark dependent tracksAman Gupta2018-04-171-0/+2
| | | | | | | 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_lavf: skip demuxer hack iteration if hacks are disabledsergey.dobrodey2018-04-121-3/+1
|
* 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_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.
* 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_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.
* 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.
* demux_lavf: add required format hacks for DASHsfan52018-01-151-0/+1
|
* demux_lavf: always give libavformat the filename when probingwm42017-11-121-1/+1
| | | | | | | | | | | This gives the filename or URL to the libavformat probing logic, which might use the file extension as a "help" to decide which format the file is. This helps with mp3 files that have large id3v2 tags and prevents the idiotic ffmpeg probing logic to think that a mp3 file is amr. (What we really want is knowing whether we _really_ need to feed more data to libavformat to detect the format. And without having to pre-read excessive amounts of data for relatively normal streams.)
* Bump libav* API usewm42017-10-301-13/+1
| | | | (Not tested on Windows and OSX.)
* demux_lavf: return AVERROR_EOF on file endDaniel Kucera2017-10-301-1/+1
| | | | | | | Signed-off-by: Daniel Kucera <daniel.kucera@gmail.com> Signed-off-by: wm4 <wm4@nowhere> Uses different style and different logic from original PR.
* demux: drop redundant SEEK_BACKWARD flagwm42017-10-231-2/+2
| | | | | | | | | | | | | Seems like most code dealing with this was for setting it in redundant cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one out. Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache(). In demux_mkv_seek(), make the arbitrary decision that a video stream is not required for the subtitle prefetch logic to be active. We might want subtitles with long duration even with audio only playback, or if the file is used as external subtitle.
* build: add preliminary LGPL modewm42017-09-211-9/+7
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* video: add metadata handling for spherical videowm42017-08-211-0/+17
| | | | | | | | | | | | | | This adds handling of spherical video metadata: retrieving it from demux_lavf and demux_mkv, passing it through filters, and adjusting it with vf_format. This does not include support for rendering this type of video. We don't expect we need/want to support the other projection types like cube maps, so we don't include that for now. They can be added later as needed. Also raise the maximum sizes of stringified image params, since they can get really long.
* demux_lavf: use partial read for AVIOContext.read_packetwm42017-08-171-1/+1
| | | | More betterer.
* demux_lavf: don't free AVFormatContext.key fieldwm42017-07-211-2/+0
| | | | We don't even set it anymore. This really should be up to libavformat.
* demux_lavf: remove --demuxer-lavf-cryptokey optionwm42017-07-061-5/+0
| | | | | | | | Was at least somewhat broken, and is misleading. I don't really have an idea why FFmpeg has two AVOptions here anyway. We don't need to care, and I'm only aware of 1 user trying this option ever. See #4579.
* demux_lavf: potentially fix --demuxer-lavf-cryptokeywm42017-07-061-21/+3
| | | | | | | | | | | | The first time I saw a user try to use this option, and apparently it didn't work. I'm not exactly sure why, but the code seems to be broken anyway. Apart from not doing any error checking (neither mallocs nor warning the user against invalid input), it forgets to add a 0 terminator. Use the corresponding AVOption instead, which probably works. See #4579.
* demux: get rid of DEMUXER_CTRL_GET_TIME_LENGTHwm42017-06-201-24/+20
| | | | | | | | | | | | Similar purpose as f34e1a0deea45e. Somehow this is much more natural too, and needs less code. This breaks runtime updates to duration. This could easily be fixed, but no important demuxer does this anyway. Only demux_raw and demux_disc might (the latter for BD/DVD). For the latter it might actually have some importance when changing titles at runtime (I guess?), but guess what, I don't care.
* demux: replace custom return codes with CONTROL_ oneswm42017-06-191-11/+11
| | | | | | | | This is more uniform, and potentially gets rid of some past copyrights. It might be that this subtly changes caching behavior (it seems before this, it synced to the demuxer if the length was unknown, which is not what we want.)
* demux_lavf: change license to LGPL (almost)wm42017-06-161-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Since this demuxer is based on code by michael, this file can become LGPL only once the mpv core becomes LGPL, and this is preparation for it. There were quite a lot of changes for rearranging preferred libavformat vs. internal MPlayer demuxers, codec mappings, and filename extensions, but all this got removed, so some of the relevant authors weren't asked. cehoyos, who disagreed with LGPL, made a few changes in the past (mostly codec mapping and deinterlacing related things), but all of them were removed, mostly due to libavformat API cleanups. adland, who could not be reached, did commit 057916ee65, but it's easy to essentially revert the change (this is what the source changes in this commit do), so we don't need to think about it. Chris Welton, who could not be reached, made a simple change in commit 958c41d9b69. Fortunately, the API changed again, and his changes were removed, so we don't need to think about this either. There is an anonymous contribution in commit 085f35f4b48 - since this did not introduce any original code, and the probe code was heavily rewritten multiple times, I don't consider it relevant.
* demux_lavf: by default probe info for HLS againwm42017-06-121-1/+1
| | | | | | | | | | | | | This switches back the --demuxer-lavf-probe-info default for HLS from "no" to "yes". Apparently the old default caused problems with the FFmpeg MediaCodec wrapper. I'm not sure whether it's due to the extradata (which would not make any sense as MediaCodec takes in Annex B formatted h264 data), or something else. Reportedly, enabling probing fixes it though, so enable it again. Add disparaging comment about Google software/APIs here.
* demux_lavf: disable various other special behavior if hacks disabledwm42017-06-071-1/+2
| | | | | | This affects in particular the heuristic that enables byte seeks in some cases with .ts input. --demuxer-lavf-hacks=no should disable this behavior now.
* demux_lavf: disable half-working mp4 edit list support in libavcodecwm42017-04-071-1/+5
| | | | | Instead, enable the "old" code, which uses this for gapless info (audio padding/trailing) only.
* demux_lavf: get total duration from per-track durations as fallbackwm42017-03-011-2/+19
| | | | | | | | | Apparently fixes youtube mp4 streams if avformat_find_stream_info() is not called. Keeping audio/video track and other track durations separate is for the sake of embedded subtitle streams, where we want to include the duration of overlong subtitle streams (I think).
* demux_lavf: skip avformat_find_stream_info() for some formatswm42017-02-231-5/+17
| | | | | | | | Includes hls, mp4, mkv by default. This also avoids stupid things like decoding at least 1 video frame per stream in the demuxer. This also add --demuxer-lavf-probe-info to give finer control over what happens.
* Use AV_INPUT_BUFFER_PADDING_SIZE instead of deprecated onewang-bin2017-02-081-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ytdl_hook, edl: implement pseudo-DASH supportwm42017-02-041-9/+36
| | | | | | | | | We use the metadata provided by youtube-dl to sort-of implement fragmented DASH streaming. This is all a bit hacky, but hopefully a makeshift solution until libavformat has proper mechanisms. (Although in danger of being one of those temporary hacks that become permanent.)
* stream: get rid of streamtype enumwm42017-02-021-5/+2
| | | | | | | | | Because it's kind of dumb. (But not sure if it was worth the trouble.) For stream_file.c, we add new explicit fields. The rest are rather special uses and can be killed by comparing the stream impl. name. The changes to DVD/BD/CD/TV are entirely untested.
* Remove compatibility thingswm42016-12-071-26/+2
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* demux, stream: add option to prevent opening referenced fileswm42016-12-041-0/+15
| | | | Quite irresponsibly hacked together. Sue me.
* demux_lavf: blacklist ffm (ffserver)wm42016-12-041-0/+2
|
* demux_lavf: set title on hearing and visual impaired tracksAman Gupta2016-10-201-0/+4
|
* demux_lavf: don't accidentally enable edit list crap on Libavwm42016-10-181-1/+2
| | | | You really don't get a break from all the multiple bullshit.
* demux_lavf: "support" mov edit lists and log errors if usedwm42016-10-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | FFmpeg recently got "support" for mov edit lists. This is a terrible hack that will fail completely at least with some decoders (in particular wrappers for hardware decoding might be affected). As such it makes no point to pretend they are supported, even if we assume that the "intended" functionality works, that there are no implementation bugs (good luck with all that messy code added to the already huge mov demuxer), and that it covers enough of the mov edit list feature to be of value. So log an error if the FFmpeg code for mov edit lists appears to be active - AV_PKT_FLAG_DISCARD is used only for "clipping" edit list segments on non-key frame boundaries. In the first place, FFmpeg committed this only because Google wanted it in, and patch review did not even pick up obvious issues. (Just look how there was no lavc version bump when AV_PKT_FLAG_DISCARD was added.) We still pass the new packet flag to the decoders (av_common.c change), which means we "support" FFmpeg's edit list code now. (Until it breaks due to FFmpeg not caring about all the details.)
* demux: do not access global optionswm42016-09-061-21/+42
| | | | | | | | | | | | | | | | | Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
* demux: close underlying stream if it's fully read anywaywm42016-08-261-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is for text subtitles. libavformat currently always reads text subtitles completely on init. This means the underlying stream is useless and will consume resources for various reasons (network connection, file handles, cache memory). Take care of this by closing the underlying stream if we think the demuxer has read everything. Since libavformat doesn't export whether it did (or whether it may access the stream again in the future), we rely on a whitelist. Also, instead of setting the stream to NULL or so, set it to an empty dummy stream. This way we don't have to litter the code with NULL checks. demux_lavf.c needs extra changes, because it tries to do clever things for the sake of subtitle charset conversion. The main reason we keep the demuxer etc. open is because we fell for libavformat being so generic, and we tried to remove corresponding special-cases in the higher-level player code. Some of this is forced due to ass/srt mkv/mp4 demuxing being very similar to external text files. In the future it might be better to do this in a more straight-forward way, such as reading text subtitles into libass and then discarding the demuxer entirely, but for aforementioned reasons this could be more of a mess than the solution introduced by this commit. Probably fixes #3456.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-191-0/+2
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* demux_lavf: don't report start time for oggwm42016-08-181-2/+6
| | | | | Better with ogg shoutcast streams. These have PTS resets on each playlist item, so the PTS would usually reset to some negative value.
* demux: add per-track metadatawm42016-08-121-22/+15
| | | | | | | | | | | | | | | | | ...and ignore it. The main purpose is for retrieving per-track replaygain tags. Other than that per-