summaryrefslogtreecommitdiffstats
path: root/player/loadfile.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: remove relative seekingwm42016-02-281-1/+1
| | | | | | | | | | | | | | | | | | | Ever since a change in mplayer2 or so, relative seeks were translated to absolute seeks before sending them to the demuxer in most cases. The only exception in current mpv is DVD seeking. Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR is kept, because it's sometimes slightly useful for seeking in things like transport streams. (And maybe mkv files without duration set?) DVD seeking is terrible because DVD and libdvdnav are terrible, but mostly because libdvdnav is terrible. libdvdnav does not expose seeking with seek tables. (Although I know xbmc/kodi use an undocumented API that is not declared in the headers by dladdr()ing it - I think the function is dvdnav_jump_to_sector_by_time().) With the current mpv policy if not giving a shit about DVD, just revert our half-working seek hacks and always use dvdnav_time_search(). Relative seeking might get stuck sometimes; in this case --hr-seek=always is recommended.
* player: slightly simplify how demuxer streams are enabled/disabledwm42016-02-251-38/+29
| | | | | Instead of having reselect_demux_streams() look at all streams, make it look at the current stream that is being enabled/disabled.
* player: remove pointless callwm42016-02-231-1/+0
| | | | | This is the unfortunate video timer; it's already reset when it actually matters (after video was prepared and before video is actually started).
* player: simplify enabling demuxer threadswm42016-02-231-17/+6
| | | | | No need for this crazy loop anymore, and we can simply enable it for each demuxer when it's opened.
* player: remove unused MPContext.stream fieldwm42016-02-231-8/+0
| | | | | | | It was just dead code. Also fixes the stream-open-filename property, which is supposed to be read-only if a file was already opened.
* player: remove MPContext.sources fieldswm42016-02-231-15/+4
| | | | | | Some oddity that is not needed anymore. The only thing which still referenced them was avoiding loading external files more than once, which is now prevented by checking the list of tracks instead.
* player: remove initial seek on playback startwm42016-02-181-2/+0
| | | | | | Accidental leftover from commit ae55896f. (This seek ised to be done with ordered chapters, and was accidentally changed to always being done.)
* player: remove old timeline/ordered chapters supportwm42016-02-151-187/+17
|
* player: add on_preloaded hookwm42016-02-151-0/+16
| | | | (Limited usefulness.)
* player: restore old/correct --force-window behaviorwm42016-02-151-0/+3
| | | | | | | | | When playback of a video ends, and the next file has no video at all (no cover art or anything), then the window must be cleared. This also resizes the window forcibly, which is by design. Fixes #2825.
* player: abort loading if there is a problem with complex filterswm42016-02-101-5/+11
|
* player: add --external-file optionwm42016-02-081-14/+12
| | | | Mostly intended for use with --lavfi-complex.
* player: add complex filter graph supportwm42016-02-051-2/+134
| | | | | | | | | | | | | | | | See --lavfi-complex option. This is still quite rough. There's no support for dynamic configuration of any kind. There are probably corner cases where playback might freeze or burn 100% CPU (due to dataflow problems when interaction with libavfilter). Future possible plans might include: - freely switch tracks by providing some sort of default track graph label - automatically enabling audio visualization - automatically mix audio or stack video when multiple tracks are selected at once (similar to how multiple sub tracks can be selected)
* player: refactor: reduce some dependencies on current_trackwm42016-02-011-15/+11
| | | | Don't mind me.
* demux: disable stream cache if no tracks are selectedwm42016-01-181-1/+4
| | | | | | | | | Slightly helps with timeline stuff, like EDL. There is no need to keep network (or even just disk I/O) busy for all segments at the same time, because 1. the data won't be needed any time soon, and 2. will probably be discarded anyway if the stream is seeked when segment is resumed. Partially fixes #2692.
* demux: remove unused flagwm42016-01-181-3/+1
|
* player: refactor: eliminate MPContext.d_videowm42016-01-171-3/+0
| | | | | | | | | | | | | | Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
* player: refactor: eliminate MPContext.d_subwm42016-01-171-20/+12
| | | | The same is going to happen to d_video and d_audio later.
* player: simplify backsteppingwm42016-01-121-1/+0
| | | | | | | | | | | | | | Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
* demux: merge sh_video/sh_audio/sh_subwm42016-01-121-1/+1
| | | | | | | | | | This is mainly a refactor. I'm hoping it will make some things easier in the future due to cleanly separating codec metadata and stream metadata. Also, declare that the "codec" field can not be NULL anymore. demux.c will set it to "" if it's NULL when added. This gets rid of a corner case everything had to handle, but which rarely happened.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* player: eliminate demux_get_next_pts()wm42016-01-111-3/+4
| | | | | | | | | | | | | | | | This slightly changes behavior when seeking with external audio/subtitle tracks if transport streams and mpeg files are played, as well as behavior when seeking with such external tracks. get_main_demux_pts() is evil because it always blocks on the demuxer (if there isn't already a packet queued). Thus it could lock up the player, which is a shame because all other possible causes have been removed. The reduced "precision" when seeking in the ts/mpeg cases (where SEEK_FACTOR is used, resulting in byte seeks instead of timestamp seeks) might lead to issues. We should probably drop this heuristic. (It was introduced because there is no other way to seek in files with PTS resets with libavformat, but its value is still questionable.)
* player: reset playback abort when reloading a filewm42016-01-071-0/+1
| | | | | | | | | | | | PT_RELOAD_FILE is a somewhat obscure case when using DVB or when switching Matroska editions. Both cases were broken, because the asynchronous playback abort mechanism was still triggered. This mechanism is used to force the demuxer and stream layers to exit immediately (instead of blocking on I/O possibly forever), and is normally disabled on playback start. The reopen path is a bit strange, and needs to reset it manually. Pointed out in #2568.
* player: make watch later/resume work when "playing" directorieswm42016-01-061-0/+2
| | | | | | | | | | | | | | If you do "mpv /bla/", and then branch out into sub-directories using playlist navigation, and then used quit and watch later, then playing the same directory did not resume from the previous point. This was because resuming is based on the path hash, so a path prefix can't be detected when resuming the parent directory. Solve this by writing each path prefix when playing directories is involved. (This includes all parent paths, so interestingly, "mpv /" would also resume in the above example.) Something like this was requested multiple times, and I want it too.
* player: make sure streams are selected with ordered chapterswm42016-01-031-3/+3
| | | | | | | | When using --start with timeline/ordered chapters, then the timeline_switch_to_time() function will look at playback_initialized whether to rselect the currently selected streams on the demuxer level. So we need to set this field to true at an earlier stage during initialization, and in particular before the code for --start is called.
* sub: always recreate ASS_Renderer on subtitle decoder reinitwm42015-12-261-1/+0
| | | | | | | This includes the case of switching ordered chapter boundaries. It will now be recreated on each timeline part switch. This shouldn't be much of a problem with modern libass. (Older libass versions use fontconfig for memory fonts, and will be very slow to reinitialize memory fonts.)
* sub: cache subtitle state per track instead of per demuxer streamwm42015-12-261-10/+14
| | | | | | | | | | | | Since commit 6d9cb893, subtitle state doesn't survive timeline switches (ordered chapters etc.). So there is no point in caching the state per sh_stream anymore (which would be required to deal with multiple segments). Move the cache to struct track. (Whether it's worth caching the subtitle state just for the situation when subtitle tracks get reselected is questionable. But for now, it's nice to have the subtitles immediately show up when reselecting a subtitle.)
* sub: clear subtitle list when crossing timeline boundarywm42015-12-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When crossing timeline boundaries (such as switching to a new segment or chapter with ordered chapters), clear the internal text subtitle list. This breaks the sub-seek command, but is otherwise not too harmful. Fixes Sub-OC-test-final7.mkv. (The internal text subtitle list is basically a cache to make subtitles show up at the right time when seeking back.) I suspect this was caused by 76fcef61. The sample file times subtitles slightly before the video frame when it should show up. This is to avoid problems with subtitles showing up a frame later than intended. It also means that a subtitle which is supposed to show up on the start of a timeline part boundary actually might first be shown in a different part. Since we now manipulate the packet timestamps, instead of manipulating timestamps after the subtitle decoder, this means this subtitle event would have 2 timestamps, which our code of course does not handle. If the two parts come one after another, this would actually work (since the subtitle would have the same timestamps in the old and new part), but it breaks if the new part (which follows the old part in the physical file) is has a completely different start time in the timeline. Essentially, the trick used to time subtitles correctly is incompatible with the way we cache subtitles (to make them survive seeks). The simple solution is just clearing the cached subtitles when crossing chapter boundaries.
* demux: remove weird tripple-buffering for the sh_stream listwm42015-12-231-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step.
* player: minor simplificationwm42015-12-231-4/+2
| | | | This tmp thing had not much of a purpose anymore.
* player: init playback speed correctlywm42015-12-101-0/+2
| | | | | Usually not a problem, but could not be initialized early enough in some corner cases.
* player: make timeline switching slightly nicerwm42015-11-181-20/+21
| | | | But not much.
* player: use demuxer ts offset to simplify timeline ts handlingwm42015-11-161-19/+7
| | | | | | | | | Use the demux_set_ts_offset() added in the previous commit to base each timeline segment to use timestamps according to its relative position within the overall timeline. As a consequence we don't need to care about these timestamps anymore, and everything becomes simpler. (Another minor but delicious nugget of sanity.)
* player: handle rebasing start time differentlywm42015-11-161-1/+11
| | | | | | | | | | | | | | | | Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
* player: remove unused fieldwm42015-11-141-1/+0
|
* player: refactor display-sync frame duration calculationswm42015-11-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of get_past_frame_durations(), which was a bit too messy. Add a past_frames array, which contains the same information in a more reasonable way. This also means that we can get the exact current and past frame durations without going through awful stuff. (The main problem is that vo_pts_history contains future frames as well, which is needed for frame backstepping etc., but gets in the way here.) Also disable the automatic disabling of display-sync if the frame duration changes, and extend the frame durations allowed for display sync. To allow arbitrarily high durations, vo.c needs to be changed to pause and potentially redraw OSD while showing a single frame, so they're still limited. In an attempt to deal with VFR, calculate the overall speed using the average FPS. The frame scheduling itself does not use the average FPS, but the duration of the current frame. This does not work too well, but provides a good base for further improvements. Where this commit actually helps a lot is dealing with rounded timestamps, e.g. if the container framerate is wrong or unknown, or if the muxer wrote incorrectly rounded timestamps. While the rounding errors apparently can't be get rid of completely in the general case, this is still much better than e.g. disabling display-sync completely just because some frame durations go out of bounds.
* player: make stop command actually stopwm42015-10-061-1/+1
| | | | | | | | | | | | | The stop command didn't always stop. In this case, opening a HLS URL and then sending "stop" during loading would actually make it fallback to parsing it as a playlist, and then continued to play the playlist items. (This corner case makes several unfortunate factors come together to produce this really odd behavior.) Another issue is that the "stop" was not always explicitly set. This could be a problem when sending several commands at once. Only the "quit" command should have priority over the "stop" command, so this is still checked.
* player: print tags under different log prefixwm42015-10-011-2/+4
| | | | A minor, but apparently common feature request. Fixes #2360.
* 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 coul