summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: document probe-start-time option and enable it by defaultwm42020-02-271-1/+2
| | | | | | | | | | | | This is useful with live streams, and it's not much worse than the h264 first packet hack, which reads some data anyway. For some reason, the option wasn't even documented, so do that. In addition, print the start time even if it's negative. That should not be possible, but for some reason, the field is an int64_t copied from an uint64_t so... whatever. Keeping the logging slightly more straight forward is better anyway.
* demux: simplify some internals, stop trying to read packets after EOFwm42020-02-271-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove some redundant fields that controlled or indicated whether the demuxer was/could/should prefetch. Redefine how the eof/reading fields work. The in->eof field is now always valid, instead of weirdly being reset to false in random situations. The in->reading field now corresponds to whether the demuxer thread is working at all, and is reset if it stops doing anything. Also, I always found it stupid that dequeue_packet() forced the demuxer thread to retry reading if it was EOF. This makes little sense, but was probably added for files that are being appended to (running downloads). It makes no sense, because if the cache really tried to read until file EOF, it would encounter partial packets and throw errors, so all is lost anyway. Plus stream_file now handles this better. So stop this behavior, but add a temporary option that enables the old behavior. I think checking for ds->eager when enabling prefetching never really made sense (could be debated, but no, not really). On the other hand, the change above exposed a missing wakeup in the backward demuxing code. Some chances of regressions that could make it stuck in certain states or so, or incorrect demuxer cache state reporting to the player frontend.
* sub, demux: improve behavior with negative subtitle delay/muxed subswm42020-02-272-4/+41
| | | | | | | | | | | | | | | | | | | | | | | | A negative subtitle delay means that subtitles from the future should be shown earlier. With muxed subtitles, subtitle packets are demuxed along with audio and video packets. But since they are demuxed "lazily", nothing guarantees that subtitle packets from the future are available in time. Typically, the user-observed effect is that subtitles do not appear at all (or too late) with large negative --sub-delay values, but that using --cache might fix this. Make this behave better. Automatically extend read-ahead to as much as needed by the subtitles. It seems it's the easiest to pass the subtitle render timestamp to the demuxer in order to guarantee that everything is read. This timestamp based approach might be fragile, so disable it if no negative sub-delay is used. As far as the player frontend part is concerned, this makes use of the code path for external subtitles, which are not lazily demuxed, and may already trigger waiting. Fixes: #7484
* demux: avoid some queue management corner cases with subtitleswm42020-02-271-2/+3
| | | | | | | | | | | | | | | | | | | Subtitle tracks are usually "lazy" (ds->eager=false), There are a number of weird special cases associated with it. One of them is that they have some sort of "temporary" EOF (to signal that there isn't a packet right now, and the decoder should not block playback by waiting for more packets). In a the next commit, I want to call mark_stream_eof() in case of (some) of these temporary EOFs. The problem is that mark_stream_eof() also calls the functions touched by this commit. Basically they shouldn't do any complex work due to these temporary EOFs (because they might happen very often). It turns out that lazy tracks barely matter here: they do not extend the seek range of a packet/EOF happens on them, they do not trigger seek range joining, and they do not support backward demuxing. This change should enable the following commit, while not causing any behavior changes (i.e. bugs) with the current state.
* ytdl_hook, edl: add fps, samplerate codec parameterswm42020-02-211-0/+2
| | | | Well, didn't help much in the case I was interested it.
* edl: make it possible to set the track "default" flagwm42020-02-211-0/+11
| | | | | Also, the forced flag (and in the future, potentially a number of other flags not implemented yet). See next commit for purpose.
* demux_edl: correct warning on duplicate parameterswm42020-02-211-2/+4
| | | | | | | | A parameter that is actually used is removed from the param_names[] array, so we can report unused parameters. This also happened on duplicate parameters, so adjust the warning to make it less confusing. (In any case, you're not supposed to provide duplicate parameters.)
* edl: make it possible to delay-load files with multiple trackswm42020-02-213-17/+49
| | | | | | | | | | | | | | Until now, delay-loading was for files with single tracks only (basically what DASH and HLS like to expose, so adaptive streaming and codec selection becomes easier - for sites, not for us). But they also provide some interleaved versions, probably for compatibility. Until now, we were forced to eagerly load it (making startup slightly slower). But there is not much missing. We just need a way to provide multiple metadata entries, and use them to represent each track. A side effect is now that the "track_meta" header can be used for normal EDL files too.
* demux_lavf: signal no seeking for RTSP streams without durationwm42020-02-201-0/+5
| | | | | | | | | | | | RTSP supports seeking, but at least the libavformat implementation makes this dependent on runtime behavior. So you have to perform a seek, and check if it fails. But even if you do this, the stream is interrupted and restarted, and there seem to be other issues. Assume that RTSP with unknown duration means it's a live stream, and disable seeking in this case, as suggested by the issue reporter. Fixes: #7472
* demux_timeline: don't open every delayed-open track on seekingwm42020-02-201-1/+1
| | | | | | | Now this was stupid. To seek a source, it obviously has to be opened... so just don't try to seek any unused source. If the track is actually selected during playback, a seek to the correct position is performed anyway.
* demux: fix seek range caching with delay_open hackwm42020-02-201-1/+2
| | | | | | These have ->segmented set (so the codec can be initialized properly), but have no segment start or end times. This code was (probably) the only thing which didn't handle this case.
* demux_timeline: warn if streams are invisiblewm42020-02-201-0/+6
| | | | | | | | ytdl_hook.lua can do this with all_formats and when delay_open is used, and if the source stream actually contains both audio and video. In this case, it might accidentally hide a media type completely, or waste bandwidth (if the stream has true interleaved audio/video). So it's important to warn.
* player: print manifest per-stream bitrate information to terminalwm42020-02-191-2/+0
| | | | | Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the track title use this.
* demux: cosmetic changewm42020-02-171-2/+1
| | | | This was sort of asymmetric and annoying.
* demux: update file-size property even when pausedwm42020-02-161-0/+3
| | | | | | | | | | | While paused, the decoders typically stop reading data from the demuxer. But for some reason, the file size is returned as a public field in struct demuxer (wat...), and updated only when the packet reading function is called. This caused the file size property to always return the same value when paused, even though the demuxer thread was reading new data, and the internal file size was updated. Fix with a simple hack.
* demux: only query stream size at most once per secondwm42020-02-161-5/+9
| | | | | | | | | | Instead of every packet. Doing it every packet led to the performance regression mentioned in the fstat() commit. This should now be over, but out of being careful, don't query the file size that often. This is only used for user interface things, so this should not cause any problems. For the sake of leaving the code compact, abuse another thing that is updated only every second (speed statistics).
* demux: invert update_cache() lockingwm42020-02-161-9/+7
| | | | Equivalent, just slightly more convenient for the following change.
* Remove remains of Libav compatibilitywm42020-02-163-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
* edl: add mechanism for delay loading streamswm42020-02-154-33/+147
| | | | | | | | | | | | | Add something that will access an URL embedded in EDL only when the track it corresponds to is actually selected. This is meant to help with ytdl_hook.lua and to improve loading speeds. In theory, all this stuff is available to any mpv user, but discourage using it, as it's so specialized towards ytdl_hook.lua, that there's danger we'll just break this once ytdl_hook.lua stops using it, or similar. Mostly untested.
* demux_edl: warn if no_clip is used with multiple partswm42020-02-151-0/+3
| | | | Well whatever.
* demux_edl: allow a redundant new_stream at the beginningwm42020-02-151-1/+4
| | | | | | | Normally, the first sub-stream is implicitly created. This change lets the user use more orthogonal syntax, and use a new_stream header for every sub-stream, instead of having to skip the header for the first one.
* demux_edl: accept protocol entries in EDL entries againwm42020-02-151-1/+4
| | | | | | Accidentally broken by commit 99700bc52c1317. mp_path_join() does not check for this, because it's supposed to work on filesystem strings (and e.g. "http://fubar" is a valid relative path in UNIX).
* demux_edl: improve parsing slightlywm42020-02-151-45/+99
| | | | | | | | | | | Add a mp_log context to the parse_edl() function, and report some errors. Previously, this just told you that something was wrong. Add some error reporting to make it slightly less evil. Put all parameters in a list before processing them. This makes adding parameters for special headers easier, and we can report parameters that were not understood. (For "compatibility", which probably doesn't matter at all, still don't count them as errors; as before.)
* demux_timeline: fix another cursed memory management issuewm42020-02-151-3/+7
| | | | | | | | | | | | | The timeline stuff has messed up memory management because there are no clear ownership rules between a some demuxer instances (master or demux_timeline) and the timeline object itself. This is another subtle problem that happened: apparently, demux_timeline.open is supposed to take over ownership of timeline, but only on success. If it fails, it's not supposed to free it. It didn't follow this, which lead to a double-free if demux_timeline.open failed. The failure path in demux.c calls both timeline_destroy() and demux_timeline.close on failure.
* demux_timeline: fix a commentwm42020-02-151-2/+2
|
* demux_timeline: reorder some functionswm42020-02-151-157/+153
| | | | | | Move them around in the source code to get rid of the forward declarations. Other than rearranging the lines and removing the 2 forward declarations, there are no other changes at all.
* demux: add option to disable "sharing" between back and forward bufferswm42020-02-071-1/+4
| | | | | | | As requested. I guess option name and manpage text could be better and clearer. Closes: #7442
* cue: tolerate NBSP as whitespacewm42020-02-031-5/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently such .cue files exist. They fail both probing and parsing. To make it worse, the sample at hand was encoded as Latin1. One part of this is replacing bstr_lstrip() with a version that supports NBSP. One could argue that bstr_lstrip() should always do this, but I don't want to overdo it. There are many more unicode abomination which it could be said it's supposed to handle, so it will stay ASCII instead of going down this rabbit hole. I'm just assuming this cue sheet was generated by some stupid software that inexplicably liked NBSPs (which is how we justify a one-off fix). The new lstrip_whitespace() doesn't look particularly efficient, but it doesn't have to be. The second part is dealing with the fact that the charset is not necessarily UTF-8. We don't want to do conversion before probing thinks it knows it's a cue sheet (would probably make it more fragile all around), so just make it work with Latin1 by assuming invalid code points are Latin1. This fallback is part of why lstrip_whitespace() is sort of roundabout. (You could still rewrite it as much more efficient state machine, instead of using a slow and validating UTF-8 parser that is called per codepoint. Starting to overthink this.) Multimedia is terrible. Legacy charsets are terrible. Everything is terrible. Fixes: #7429
* libarchive: some shitty hack to make opening slightly fasterwm42020-01-041-0/+20
| | | | | | | | See manpage additions. The libarchive behavior mentioned in the last paragraph there is technically unrelated, but makes this new option mostly pointless. See: #7182
* demux: add per-demuxer sub-optionswm42020-01-042-0/+14
| | | | | | Until now, they were all just added to options.c (e.g. demux_mkv_conf). This adds a mechanism which can be used to add future options in a (very) slightly more elegant way.
* stream_libarchive: some more hacks to improve multi-volume archiveswm42020-01-041-2/+2
| | | | | | | | | | Instead of opening every volume on start just to see if it's there, all all volumes that could possibly exist, and "handle" it on opening. This requires working around some of libarchive's amazing stupidity and using some empirically determined behavior. Will possibly break if libarchive changes some of this behavior. See: #7182
* demux_edl: restore relative path resolutionwm42020-01-021-0/+12
| | | | | | | Playing e.g. "dir/f.edl" should make all non-absolute paths in f.edl relative to "dir". Commit 0e98b2ad8ec accidentally broke this.
* demux: make track switching instant with certain mpegts fileswm42019-12-311-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching tracks, the data for the new track is missing by the amount of data prefetched. This is because all demuxers return interleaved data, and you can't just seek the switched track alone. Normally, this would mean that the new track simply gets no data for a while (e.g. silence if it's an audio track). To avoid this, mpv performs a special "refresh seek" in the demuxer, which tries to resume demuxing from an earlier position, in a way that does not disrupt decoding for the non-changed tracks. (Could write a lot about the reasons for doing something so relatively complex, and the alternatives and their weaknesses, but let's not.) This requires that the demuxer can tell whether a packet after a seek was before or after a previously demuxed packet, sort of like an unique ID. The code can use the byte position (pos) and the DTS for this. The DTS is normally strictly monotonically increasing, the position in most sane file formats too (notably not mp4, in theory). The file at hand had DTS==NOPTS packets (which is fine, usually this happens when PTS can be used instead, but the demux.c code structure doesn't make it easy to use this), and pos==-1 at the same time. The latter is what libavformat likes to return when the packet was produced by a "parser" (or in other words, packets were split or reassembled), and the packet has no real file position. That means the refresh seek mechanism has no packet position and can't work. Fix this by making up a pseudo-position if it's missing. This needs to set the same value every time, which is why it does not work for keyframe packets (which, by definition, could be a seek target). Fixes: #7306 (sort of)
* demux: fix --stream-record runtime change handlingwm42019-12-291-1/+1
| | | | Well, if that wasn't particularly dumb.
* playlist: change from linked list to an arraywm42019-12-283-6/+6
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* demux: stop setting dummy stream on demux_close_stream()wm42019-12-232-7/+9
| | | | | | | | | | | | | | Demuxers can call demux_close_stream() to close the underlying stream if it's not needed anymore. (Useful to release "heavy" resources like FDs and sockets. Plus merely keeping a file open can have visible side effects such as inability to unmount a filesystem or, on Windows, to do anything with the file.) Until now, this set demuxer->stream to a dummy stream, because most code used to assume that the stream field is non-NULL. But this requirement disappeared (in some cases, the stream field is already NULL), so stop doing that. demux_lavf.c, one of the demuxers which calls this function, still had some of this, though.
* demux_mf: use stream API to open list fileswm42019-12-231-15/+28
| | | | | | | | | | mf:// has an obscure feature that lets you pass a list of filenames separated by newlines. Who knows whether anyone is using that. It opened these listfiles with fopen(), so the recent stream origin bullshit doesn't operate on it. Fix this by using the mpv internal stream API instead. Unfortunately there is no fgets(), so write an ad-hoc one. (An implementation of line reading via "stream" is still in demux_playlist, but it's better to keep it quarantined there.)
* demux: remove debug abort()wm42019-12-221-1/+1
| | | | | | WHAT THE FUCK Fixes: #7279
* demux: add an option to control tag charsetwm42019-12-202-1/+83
| | | | | | Fucking gross that you need this in almost-2020. Fixes: #7255
* edl: accept arbitrary pathswm42019-12-201-17/+0
| | | | | | | | | | Until now, .edl files accepted only "simple" filenames, i.e. no relative or absolute paths, no URLs. Now that the origin bullshit is a bit cleaned up and enforced in the EDL code, there's absolutely no reason to keep this. The new code behaves somewhat similar to playlists. (Although playlists are special because they're not truly recursively opened.)
* stream, demux: redo origin policy thingwm42019-12-2012-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* libarchive: prefix entry names in archive URLs with '/'wm42019-12-201-1/+1
| | | | | | | This has the advantage that playlists within the archive will work as expected, because demux_playlist will correctly join the archive base URL and entry name. Before this change, it could skip before the "|", resulting in a broken URL.
* demux_edl: fix reusing segment source fileswm42019-12-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | EDL files can have multiple segments taken from the same source file. In this case, the source file is supposed to be opened only once. This stopped working, and it created a new demuxer instance for every single segment entry. This made it slow and made it use much more memory than needed. This was because it tried to iterate over the array of source files, but the array count (num_parts) was only set to a non-0 value later. Fix this by maintaining the count correctly. In addition, the actual code for checking whether a source can be reused (in open_source()) regressed and stopped working correctly. d->stream could be NULL. Use demuxer.filename instead; I'm not entirely sure whether this is always correct, but fortunately we have a distributed almost-AI driven test suite (called "users") which will probably find and report such cases. Probably broke with commit a09396ee60 or something close, but didn't check closer. Fixes: #7267
* demux_lavf: export demuxer_id for more formats which have itwm42019-12-031-5/+8
| | | | | | | | | | | | | | | | | | See previous commit. libavformat exports this information as AVStream.id field. The big problem is that the libavformat field is simply 0 if it's unknown (i.e. the demuxer never sets it). So it needs to remain a whitelist. Just add more formats which are known to have a meaningful ID. I considered exporting IDs for all formats, and then either leaving the values as they are, or filtering duplicate values (and choosing arbitrary but unique different IDs). But then again, I think it's sort of mpv's job to filter FFmpeg's absurd bullshit API, and it should make an effort to hide it rather than to reflect it. See: #7211
* demux: do not make up demuxer_idwm42019-12-033-9/+3
| | | | | | | | | | | | | | | | | | The demuxer_id (exported in as "src-id" property) is supposed to be the native stream ID, as it exists in the file, or -1 if that does not exist (actually any negative value), or if it is unknown. Until now, an ID was made up if it was missing. That seems like strange non-sense, and I can't find the reason why it was done. But it was probably for convenience by the EDL stuff or so. Stop doing this. Fortunately, the src-id property was documented as being unavailable if the ID is not known. Even the code for this was present, it was just inactive until now. Extend input.rst with some explanations. Also fixing 3 other places where negative demuxer_id was ignored or avoided.
* options: get rid of GLOBAL_CONFIG hackwm42019-1