summaryrefslogtreecommitdiffstats
path: root/player/loadfile.c
Commit message (Collapse)AuthorAgeFilesLines
* player: rename and move find_subfiles.cwm42015-09-201-1/+1
| | | | | | This was in sub/, because the code used to be specific to subtitles. It was extended to automatically load external audio files too, and moving the file and renaming it was long overdue.
* player: make force-window in auto-profiles actually workwm42015-09-201-2/+1
| | | | | | | | | | | The previous commit was incomplete (and I didn't notice due to a broken test procedure). The annoying part is that actually creating the VO was separate; redo this and merge the code for this into handle_force_window() as well. This will also make implementing proper reaction to runtime option changes easier. (Only the part for actually listening to option changes is missing.)
* player: make force-window=immediate work in auto-profileswm42015-09-201-0/+3
| | | | | | This is a bad hack; the correct way to handle this would be implementing profiles differently, and then listen to option changes and act on them dynamically.
* player: log error code on playback exitwm42015-09-031-0/+2
| | | | So far, this required using the client API to know it.
* player: slightly better error reporting when opening file failswm42015-08-281-2/+7
| | | | Return MPV_ERROR_LOADING_FAILED instead of MPV_ERROR_NOTHING_TO_PLAY.
* player: add --playlist-pos optionwm42015-08-221-1/+8
| | | | Oddly often requested.
* player: actually close files on playback endwm42015-08-151-1/+1
| | | | Regression since commit 75b1d504.
* player: add display sync modewm42015-08-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | If this mode is enabled, the player tries to strictly synchronize video to display refresh. It will adjust playback speed to match the display, so if you play 23.976 fps video on a 24 Hz screen, playback speed is increased by approximately 1/1000. Audio wll be resampled to keep up with playback. This is different from the default sync mode, which will sync video to audio, with the consequence that video might skip or repeat a frame once in a while to make video keep up with audio. This is still unpolished. There are some major problems as well; in particular, mkv VFR files won't work well. The reason is that Matroska is terrible and rounds timestamps to milliseconds. This makes it rather hard to guess the framerate of a section of video that is playing. We could probably fix this by just accepting jittery timestamps (instead of explicitly disabling the sync code in this case), but I'm not ready to accept such a solution yet. Another issue is that we are extremely reliant on OS video and audio APIs working in an expected manner, which of course is not too often the case. Consequently, the new sync mode is a bit fragile.
* player: separate controls for user and video controlled speedwm42015-08-101-0/+2
| | | | | | | | | | For video sync, we want separate playback speed controls for user- requested speed and the "correction" speed for video timing. Further, we use this separation to make sure only a resampler is inserted if playback speed is only changed for video sync correction. As of this commit, this is basically inactive code. It's just preparation for the video sync code (the following commit).
* player: redo estimated-vf-fps calculationwm42015-08-101-0/+1
| | | | | | | | | | | | | | Additionally to taking the average, this tries to use the demuxer FPS to eliminate jitter, and applies some other heuristics to check if the result is sane. This code will also be used for the display sync code (it will actually make use of the require_exact parameter). (The value of doing this over keeping the simpler demux_mkv hack is somewhat questionable. But at least it allows us to deal with other container formats that use jittery timestamps, such as mp4 remuxed from mkv.)
* player: use demux_open_url() to open main fileswm42015-08-041-61/+24
| | | | | | | | | | | | | | | | Instead of opening a stream and then a demuxer, do both at once with demux_open_url(). This requires some awkward additions to demuxer_params, because there are some weird features associated with opening the main file. E.g. the relatively useless --stream-capture features requires enabling capturing on the stream before the demuxer is opened, but on the other hand shouldn't be done on secondary files like external subtitles. Also relatively bad: since demux_open_url() returns just a demuxer pointer or NULL, additional error reporting is done via demuxer_params. Still, at least conceptually, it's ok, and simpler than before.
* player: remove higher-level remains of DVD/BD menu supportwm42015-08-031-7/+0
| | | | | | | | | | | | | | | Nobody wanted to restore this, so it gets the boot. If anyone still wants to volunteer to restore menu support, this would be welcome. (I might even try it myself if I feel masochistic and like wasting a lot of time for nothing.) But if it does get restored, it should be done differently. There were many stupid things about how it was done. For example, it somehow tried to pull mp_nav_events through all the layers (including needing to "buffer" them in the demuxer), which was needlessly complicated. It could be done simpler. This code was already inactive, so this commit actually changes nothing. Also keep in mind that normal DVD/BD playback still works.
* player: extend --hls-bitrate optionwm42015-07-131-4/+10
| | | | Fixes #2116.
* player: never overwrite stop_play fieldwm42015-07-081-2/+4
| | | | | | | This is a real pain: if a quit command is received, it's set to PT_QUIT. And then other code could overwrite it, making it not quit. The annoying bit is that stop_play is written and read in many places. Just not overwriting it unconditionally seems to be the best course of action.
* player: simplify reload logicwm42015-07-021-14/+9
| | | | Instead of only reloading the demuxer, reopen the stream as well.
* player: remove automatic DVB channel advancement on no datawm42015-07-021-6/+0
| | | | | | | | For the sake of removing the separate stream/demuxer loading code. This could probably be reimplemented in some other way, but I have no DVB hardware for testing. The most preferred way would be making DVB to not quit, and just rerun the stream selection.
* player: unentangle --stream-dumpwm42015-07-021-6/+6
| | | | | | | | The final goal is making opening the demuxer and opening the stream the same operation. Stream dumping is a rather uninteresting feature, but has a small number of vocal users, and it's easy to keep.
* demux: export forced flagwm42015-06-271-2/+9
| | | | | | At least Matroska files have a "forced" flag (in addition to the "default" flag). Export this flag. Treat it almost like the default flag, but with slightly higher priority.
* player, demux: replace some demux_open() uses with demux_open_url()wm42015-06-241-12/+6
|
* client API: add MPV_END_FILE_REASON_REDIRECTwm42015-06-111-2/+4
| | | | | Requested. Minor incompatible behavior change, as it was signalling MPV_END_FILE_REASON_EOF previously.
* client API: leave mpv_event_end_file.error to 0 on no errorwm42015-06-111-2/+2
| | | | | Making sure this is true makes it closer to the libmpv docs, and possibly less confusing in corner cases.
* player: print a message along with track listwm42015-06-031-2/+4
| | | | Slightly less strange.
* player: fix crashes when adding external tracks before loading main filewm42015-05-261-15/+13
| | | | | | | | | | | | | | | | Adding an external audio track before loading the main file didn't work right. For one, mp_switch_track() assumes it is called after the main file is loaded. (The difference is that decoders are only initialized once the main file is loaded, and we avoid doing this before that for whatever reason.) To avoid further messiness, just allow mp_switch_track() to be called at any time. Also make it do what mp_mark_user_track_selection() did, since the latter requires current_track to be set. (One could probably simply allow current_track to be set at this point, but it'd interfere with default track selection anyway and thus would be pointless.) Fixes #1984.
* player: use an array for stream ID options and suchwm42015-05-221-31/+21
| | | | This makes the code slightly more generic.
* player: make resuming playlists less noisy in verbose modewm42015-05-091-2/+1
| | | | | | | | | | | | | | | | | | | mp_find_config_file() will print the filename lookup and its result in verbose mode. This is wanted, but gets inconvenient when it is done for every playlist entry (for resuming). Lookup the watch_later subdir only once and cache the result instead. This drops the logic for loading the resume file from other locations, which should generally be unnecessary, though might lead to confusion if the user has mixed old and new config paths (which the user shouldn't). Also add a mp_find_user_config_file() function for a more straightforward and reliable way to get actual local configpaths, instead of possibly global and unwritable locations. Also, for symmetry, check the resume option in mp_load_playback_resume() just like mp_check_playlist_resume() does.
* player: log track list when adding or removing external fileswm42015-04-281-5/+10
| | | | | | | | | Should help with debugging, and might be slightly more userfriendly. Note that this is called manually in multiple entry-points, instead of the functions doing the actual work (like mp_remove_track()). This is done so that exiting the player or calling the sub_reload command won't print redundant in-between states.
* player: fix removing external tracks at runtimewm42015-04-271-1/+9
| | | | | | | | | | This could make the player crash on exit if the "sub_reload" command was used successfully. the reason was that the mpctx->sources array could have dangling pointers to the unloaded demuxers. Also fix a memory leak by actually always freeing the per-stream subtitle decoders (which are a hack to make ordered chapters behave better).
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* player: relax assertion on mp_set_playlist_entryNiklas Haas2015-03-261-1/+1
| | | | | This assertion crashed when e was NULL, which can happen when using force.
* player: refine rar:// playlist-safety handlingwm42015-03-021-3/+6
| | | | | | | | | | | | It was possible to make the player play local files by putting rar:// links into remote playlists, and some other potentially unsafe things. Redo the handling of it. Now the rar-redirector (the thing in demux_playlist.c) sets disable_safety, which makes the player open any playlist entries returned. This is fine, because it redirects to the same file anyway (just with different selection/interpretation of the contents). On the other hand, rar:// itself is now considered fully unsafe, which means that it is ignored if found in normal playlists.
* player: fix demuxer lifetime managementwm42015-02-221-50/+41
| | | | | | | | | | | Commit f54220d9 attempted to improve this, but it got worse. Now there was a crash when ytdl_hook.lua added external tracks. This happened because close_unused_demuxers() assumed that sources[0] was the main demuxer (so that it didn't close it). This assumption failed, because the ytdl script can add external tracks before the main file is loaded. The easy fix would have been to check for master_demuxer, and not i==0. But instead give up on the old idea, make some stricter assumptions how demuxers and external tracks map, and simplify the code.
* demux: add a demux_open_url() functionwm42015-02-201-9/+3
| | | | | Often stream and a demuxer are opened at the same time. Provide a function for this and replace most of its uses.
* demux: change demux_open() signaturewm42015-02-201-10/+10
| | | | Fold the relatively obscure force_format parameter into demuxer_params.
* demux: add free_demuxer_and_stream() functionwm42015-02-201-9/+4
| | | | | Although their lifetimes are conceptually different, it happens often that a demuxer is destroyed together with its stream.
* player: move timeline scanning (ordered chapters etc.) to a threadwm42015-02-201-7/+15
| | | | | | | | | | | | Do timeline building (scanning & opening reference files for ordered chapters, and more) in a thread. As a result, this process can actually be stopped without having to kill the player. This is pretty simple: just reuse the demuxer opening thread. We have to give up on the idea that open_demux_reentrant() is reusable, though. (Althoughthe timeline readers still need some fixes before they react to the quit request.)
* player: cosmetics: async/non-blocking -> reentrantwm42015-02-201-9/+9
| | | | | | These functions do blocking work on a separate thread, but wait until they return. So they are not async or non-blocking. But they do react to user-input and client API accesses, which makes them reentrant.
* player: enable cache and demuxer thread for subtitles toowm42015-02-181-3/+5
| | | | | | | | | Includes some logic for not starting the demuxer thread for fully read subtitles. (Well, the cache will still waste _lots_ of resources, and the cache always has to be created, because we don't know whether it'll be needed _before_ opening the file.) See #1597.
* demux_edl: make independent from MPContextwm42015-02-171-3/+0
|
* demux_cue: make independent from MPContextwm42015-02-171-3/+0
| | | | Also see previous commit(s).
* matroska: make timeline code independent of MPContextwm42015-02-171-3/+0
|
* player: use a separate context for timeline loader stuffwm42015-02-171-16/+44
| | | | | | | | | | | | | | | | | | | | | | | | Instead of accessing MPContext in player/timeline/*, create a separate context struct, which the timeline loaders fill out. It turns out that there's not much in the way too big MPContext that these need to access. One major PITA is managing (and closing) the set of open demuxers. The problem is that we need a list of all demuxers to make sure no unneeded streams are enabled. This adds a callback to the demuxer_desc struct, with the intention of leaving to to the demuxer to call the right loader, instead of explicitly checking the demuxer type and dispatching manually in common code. I also considered making the timeline part of the demuxer state, but decided against: it's too much of a mess wrt. memory management and threading, and also doesn't make it clear who owns the child demuxers. With the struct timeline decoupled from the demuxer state, it's at least somewhat clear that the child demuxers are independent from the "main" demuxer. The actual changes to player/timeline/* are separated in the following commits, because they're quite verbose. Some artifacts will be removed later as soon as there's only 1 timeline loading mechanism.
* player: use a macro to remove an element from an arraywm42015-02-171-6/+1
| | | | Should be equivalent.
* player: actually close files when using sub_removewm42015-02-171-13/+38
| | | | | | | | | Also effects some other cases. The real reason for this is for keeping track of which demuxers can be closed (see following commit). Since I don't want to use reference counting for this, some sort of simplistic mark-and-sweep is done to determine whether a demuxer is still needed.
* command: add rescan_external_fileswm42015-02-161-4/+3
| | | | | | | | | Requested. Hopefully will be useful for things that download and add external subtitles on demand. Or something. Closes #1586.
* demux: hack for instant stream switchingwm42015-02-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the delay when switching audio tracks in mkv or mp4 files. Other formats are not enabled, because it's not clear whether the demuxers fulfill the requirements listed in demux.h. (Many formats definitely do not with libavformat.) Background: The demuxer packet cache buffers a certain amount of packets. This includes only packets from selected streams. We discard packets from other streams for various reasons. This introduces a problem: switching to a different audio track introduces a delay. The delay is as big as the demuxer packet cache buffer, because while the file was read ahead to fill the packet buffer, the process of reading packets also discarded all packets from the previously not selected audio stream. Once the remaining packet buffer has been played, new audio packets are available and you hear audio again. We could probably just not discard packets from unselected streams. But this would require additional memory and CPU resources, and also it's hard to tell when packets from unused streams should be discarded (we don't want to keep them forever; it'd be a memory leak). We could also issue a player hr-seek to the current playback position, which would solve the problem in 1 line of code or so. But this can be rather slow. So what we do in this commit instead is: we just seek back to the position where our current packet buffer starts, and start demuxing from this position again. This way we can get the "past" packets for the newly selected stream. For streams which were already selected the packets are simply discarded until the previous position is reached again. That latter part is the hard part. We really want to skip packets exactly until the position where we left off previously, or we will skip packets or feed packets to the decoder twice. If we assume that the demuxer is deterministic (returns exactly the same packets after a seek to a previous position), then we can try to check whether it's the same packet as the one at the end of the packet buffer. If it is, we know that the packet after it is where we left off last time. Unfortunately, this is not very robust, and maybe it can't be made robust. Currently we use the demux_packet.pos field as unique packet ID - which works fine in some scenarios, but will break in arbitrary ways if the basic requirement to the demuxer (as listed in the demux.h additions) are broken. Thus, this is enabled only for the internal mkv demuxer and the libavformat mp4 demuxer. (libavformat mkv does not work, because the packet positions are not unique. Probably could be fixed upstream, but it's not clear whether it's a bug or a feature.)
* player: add a --loop=force modewm42015-02-121-7/+5
| | | | | | | Requested. See manpage additions. This also makes the magical loop_times constants slightly saner, but shouldn't change the semantics of any existing --loop option values.
* player: do not autoload audio with audio files, enable autoloadingwm42015-02-051-0/+12
| | | | | | | | | | | | | | Autoload external audio files only if there's at least a video track (which is not coverart pseudo-video). Enable external audio file autoloading by default. Now that we actively avoid doing stupid things like loading an external audio file for an audio-only file, this should be fine. Additionally, don't autoload subtitles if a subtitle is played. Although you currently can't play subtitles without audio or video, it's disturbing and stupid that the player might load subtitle files with different extension and then fail.
* player: move timeline specific handling to timeline loaderswm42015-02-041-14/+2
| | | | In particular, gets rid of the Matroska specifics from the common code.
* command: add on_unload hookwm42015-02-041-0/+10
| | | | Fixes #1552.
* player: remove --fixed-vowm42015-02-031-5/+1
| | | | | | | In ancient times, this was needed because it was not default, and many VOs had problems with it. But it was always default in mpv, and all VOs are required to deal with it. Also, running --fixed-vo=no is not useful and just creates weird corner cases. Get rid of it.
* command: new commands audio_add/audio_remove/audio_reloadxylosper2015-02-031-10/+5
| | | | | | | | These commands are counterparts of sub_add/sub_remove/sub_reload which work for external audio file. Signed-off-by: wm4 <wm4@nowhere> (minor simplification)
* player: add external audio file auto-loadingwm42015-02-021-44/+58
| | | | | | Apparently some people want this. Not enabled by default. Fixes #967.
* command: send additional property change events in-between loadingwm42015-02-011-0/+1
| | | | | | | | Opening the stream and opening the demuxer are both done asynchronously, meaning the player reacts to client API requests. They also can potentially take a while. Thus it's better to process outstanding property changes, so that change events are sent for properties that were changed during opening.
* player: remove redundant variablewm42015-01-291-2/+0
| | | | | | mpctx->audio_delay always has the same value as opts->audio_delay. (This was not the case a long time ago, when the audio-delay property didn't actually write to opts->audio_delay. I think.)
* player: don't enable demuxer readahead before selecting trackswm42015-01-161-4/+6
| | | | | | | | | | This is for the ordered chapters case only. In theory this could have resulted in initial audio, video or subs missing, although it didn't happen in practice (because no streams were selected, thus the demuxer thread didn't actually try to read anything). It's still better to make this explicit. Also, timeline_set_part() can be private to loadfile.c.
* player: check sufficient track selection before destroying VOwm42015-01-121-9/+9
| | | | | | | | | | | | | | | | mpv needs at least an audio or video track to play something. If the track selection is basically insufficient, the player will immediately skip to the next file (or quit). One slightly annoying thing might be that trying to play a subtitle file will close the VO window, and then go to the next file immediately (so "mpv 1.mkv 2.srt 3.mkv" would flash the video window when 2.srt is skipped). Move the check to before the video window is possibly closed. This is a minor cosmetic issue; one can us