summaryrefslogtreecommitdiffstats
path: root/core/mplayer.c
Commit message (Collapse)AuthorAgeFilesLines
* OSX: run native event loop in a separate threadStefano Pigozzi2013-05-121-34/+17
| | | | | | | | | | | | | | This commit is a followup on the previous one and uses a solution I like more since it totally decouples the Cocoa code from mpv's core and tries to emulate a generic Cocoa application's lifecycle as much as possible without fighting the framework. mpv's main is executed in a pthread while the main thread runs the native cocoa event loop. All of the thread safety is mainly accomplished with additional logic in cocoa_common as to not increase complexity on the crossplatform parts of the code.
* OSX: use native Cocoa's event loopStefano Pigozzi2013-05-121-2/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Schedule mpv's playloop as a high frequency timer inside the main Cocoa event loop. This has the benefit to allow accessing menus as well as resizing the window without the playback being blocked and allows to remove countless hacks from the code that involved manually pumping the event loop as well simulating manually some of the Cocoa default behaviours. A huge improvement consists in removing NSApplicationLoad. This is a C function defined in the Cocoa header and implements a minimal OSX application under ther hood so that you can use the Cocoa GUI toolkit from C/C++ without having to respect the Cocoa standards in terms of application initialization. This was bad because the behaviour implemented by NSApplicationLoad was hard to customize and had several gotchas especially in the menu department. mpv was changed to be just a nib-less application. All the Cocoa part is still generated in code but the event handling is now not dissimilar to what is present in a stock Mac application. As a part of reviewing the initialization process, I also removed all of `osdep/macosx_finder_args`. The useful parts of the code were moved to `osdep/macosx_appication` which has the broaded responsibility of managing the full lifecycle of the Cocoa application. By consequence the `--enable-macosx-finder` configure switch was killed as well, as this feature is always enabled. Another change the users will notice is that when using a bundle the `--quiet` option will be inserted much earlier in the initializaion process. This results in mpv not spamming mpv.log anymore with all the initialization outputs.
* core: refactor seek_chapter() functionwm42013-05-091-32/+42
| | | | | | | | | | Makes it easier to understand... maybe. It's still pretty strange how this function may either queue the seek or seek immediately. The way it actually works doesn't change, queuing the seek is just moved into the function. Also add a execute_queued_seek() function, which resets the queue state correctly.
* demux: remove retrieval of chapter end timewm42013-05-061-1/+1
| | | | | | | The frontend doesn't use this. Also use double for returning the chapter times. Everything uses double for times, and there's no reason to use float here.
* core: add playback resume feature (manual/opt-in)wm42013-05-051-1/+124
| | | | | | | | | | | | | | | | | | | | | | | | | A "watch later" command is now mapped to Shift+Q. This quits the player and stores the playback state in a config file in ~/.mpv/watch_later/. When calling the player with the same file again, playback is resumed at that time position. It's also possible to make mpv save playback state always on quit with the --save-position-on-quit option. Likewise, resuming can be disabled with the --no-resume-playback option. This also attempts to save some playback parameters, like fullscreen state or track selection. This will unconditionally override config settings and command line options (which is probably not what you would expect, but in general nobody will really care about this). Some things are not backed up, because that would cause various problems. Additional subtitle files, video filters, etc. are not stored because that would be too hard and fragile. Volume/mute state are not stored because it would mess up if the system mixer is used, or if the system mixer was readjusted in the meantime. Basically, the tradeoff between perfect state restoration and complexity/fragility makes it not worth to attempt to implement it perfectly, even if the result is a little bit inconsistent.
* mplayer: factor config dir creationwm42013-05-051-18/+23
| | | | Move it into its own function.
* core: ignore backstep command if demuxer is not capablewm42013-05-051-4/+7
| | | | | | Also, mark demuxer as not capable if DVD playback is done. The problem with DVD is that playback time (stream_pts) is not reported frame-exact, and the time is a "guess" at best.
* core: move demuxer time reporting to demuxerwm42013-05-051-8/+4
|
* mplayer: put space before encoding part of status linewm42013-04-271-1/+1
| | | | Also, the trailing space isn't needed.
* core: simplify handling of --pausewm42013-04-251-18/+13
| | | | | | | | | | | | | Rename the struct MPOpts "start_pause" field to "pause". Store the user- pause state in that field, so that both runtime pause toggling and the --pause switch change the same variable. Simplify the initialization of pause so that using --pause and changing the file while paused is exactly the same case (changing the file while paused doesn't unpause, this has been always this way). Also make it a bit more consistent. Before, starting with --pause would reset the pause state for every file, instead of following the usual semantics for option switches (compare with behavior of --fs).
* core: don't let cache pause handling and user pausing conflictwm42013-04-251-7/+22
| | | | | | | | | | | | The core pauses and unpauses automatically to wait for the network cache (also known as buffering). This conflicted with user pause control, and was perceived as if the player was unresponsive and/or the cache just overturned the user's decisions. Change it so that the actual pause state and the pause state as intended by the user never conflict. If the user toggles pause, the pause state will be in the expected state as soon as the cache is loaded.
* core: fix bogus condition that broke backstepping with last commitwm42013-04-251-1/+1
| | | | | This broke all cases where indexing was required, and the current frame wasn't the first frame in a segment.
* core: fix backstepping with ordered chapterswm42013-04-251-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | There were two problems. First, frames past the end of the current segment were added to the index, which messed up backstepping. Check for the endpts before added a frame to the index. Second, it wasn't possible to step over segments which change the file. Changing a file causes decoder reinitialization, which (rightfully) is treated as discontinuity (and vo_pts_history_seek_ts was changed). Add some extra code to pretend that a segment-switching seek/reinit does not introduce discontinuities. There's still a weird corner case: sometimes, you can frame step forward on the last frame of a segment without reaching the next segment immediately. This is because the playloop switches into audio-only mode. The segment is switched when both audio and video have ended, so the frame stepping will play random sized chunks of audio until the segment will be switched. This gives the impression that backstepping doesn't work perfectly, even though it's the other way around and frame stepping behaves weird. This is a consequence of wanting to make frame stepping work with audio, and is not really a bug.
* core: add backstep supportwm42013-04-241-6/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allows stepping back one frame via the frame_back_step inout command, bound to "," by default. This uses the precise seeking facility, and a perfect frame index built on the fly. The index is built during playback and precise seeking, and contains (as of this commit) the last 100 displayed or skipped frames. This index is used to find the PTS of the previous frame, which is then used as target for a precise seek. If no PTS is found, the core attempts to do a seek before the current frame, and skip decoded frames until the current frame is reached; this will create a sufficient index and the normal backstep algorithm can be applied. This can be rather slow. The worst case for backstepping is about the same as the worst case for precise seeking if the previous frame can be deduced from the index. If not, the worst case will be twice as slow. There's also some minor danger that the index is incorrect in case framedropping is involved. For framedropping due to --framedrop, this problem is ignored (use of --framedrop is discouraged anyway). For framedropping during precise seeking (done to make it faster), we try to not add frames to the index that are produced when this can happen. I'm not sure how well that works (or if the logic is sane), and it's sure to break with some video filters. In the worst case, backstepping might silently skip frames if you backstep after a user-initiated precise seek. (Precise seeks to do indexing are not affected.) Likewise, video filters that somehow change timing of frames and do not do this in a deterministic way (i.e. if you seek to a position, frames with different timings are produced than when the position is reached during normal playback) will make backstepping silently jump to the wrong frame. Enabling/disabling filters during playback (like for example deinterlacing) will have similar bad effects.
* mplayer: apply hrseek framedrop only when doing hrseekwm42013-04-241-2/+2
| | | | | | | | | | It's not sure if there's anything that could trigger this accidentally. Normally this can't happen, because hrseek ends always if the PTS is large enough, the same condition which disables framedrop. Seeking resets hrseek framedrop anyway. On the other hand, this change makes the code easier to understand, and might be more robust against weird corner cases.
* mplayer: prefer -sub/-subfile subs over auto-loaded subswm42013-04-201-2/+8
| | | | | | | | | Before this commit, it was more or less random which subtitle was preferred if there was both an auto-loaded external subtitle, and a subtitle loaded via -sub or -subfile. -sub subtitles happened to be preferred over auto-loaded subs, while -subfile didn't. Fix the -subfile case, and make the behavior consistent by making the selection behavior explicit.
* core: display subtitle codec in track listingwm42013-04-201-2/+9
| | | | | Also switch the subrip and subviewer names, which obviously have been confused.
* demux: remove some unused sh_video_t fieldswm42013-04-201-5/+0
| | | | Completely mysterious, and its values were never actually used.
* sub, demux: identify subtitle types with the codec namewm42013-04-201-8/+6
| | | | | | | | | Get rid of the 1-char subtitle type field. Use sh_stream->codec instead just like audio and video do. Use codec names as defined by libavcodec for simplicity, even if they're somewhat verbose and annoying. Note that ffmpeg might switch to "ass" as codec name for ASS, so we don't bother with the current silly "ssa" name.
* mplayer: take tracks from first segment if main file is emptywm42013-04-201-3/+9
| | | | | | | | | | | With Matroska ordered chapters, the main file (i.e. the file you're playing) can be empty, while all video/audio data is in linked files. Some files don't even contain the track list, only chapter information. mpv refused to play these, because normally, the main file dictates the track layout. Fix this by using the first segment for track data if no part of the timeline is sourced from the main file.
* core: remove dead --vsync leftoverswm42013-04-121-2/+1
|
* mplayer: remove unnecessary variablewm42013-04-101-6/+4
|
* core: add --reset-on-next-file optionwm42013-04-101-0/+11
| | | | | | | This option can be used to selectively reset settings when playing the next file in the playlist (i.e. restore mplayer and mplayer2 behavior). Might remove this option again should it turn out that nobody uses it.
* mplayer: keep volume persistent, even when using --volumewm42013-04-101-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider: mpv --volume 10 file1.mkv file2.mkv Before this commit, the volume was reset to 10 when playing file2.mkv. This was inconsistent to most other options. E.g. --brightness is a rather similar case. In general, settings should never be reset when playing the next file, unless the option was explicitly marked file-local. This commit corrects the behavior of the --volume and --mute options. File local --volume still works as expected: mpv --{ --volume 10 file1.mkv file2.mkv --} This sets the volume always to 10 on playback start. Move the m_config_leave_file_local() call down so that the mixer code in uninit_player() can set the option volume and mute variables without overwriting the global option values. Another subtle issue is that we don't want to set volume if there's no need to, which is why the user_set_volume/mute fields are introduced. This is important because setting the volume might change the system volume depending on other options.
* mplayer: move DVB channel skip codewm42013-04-101-23/+21
| | | | Try not to cause unnecessary special cases.
* mplayer: don't disable term-osd with -vwm42013-04-101-4/+0
| | | | I don't see any reason for doing this.
* mplayer: don't print bogus status when cachingwm42013-04-101-1/+1
| | | | | When streaming from http, this could print a status line indicating paused playback instead of "buffering" sometimes.
* core: remove volstep global variablewm42013-04-091-4/+1
|
* demux_mkv: try to show current subtitle when seekingwm42013-04-041-0/+2
| | | | | | | | | | | | | | | | | Makes sure that seeking to a given time position shows the subtitle at that position. This can fail if the subtitle packet is not close enough to the seek target. Always enabled for hr-seeks, and can be manually enabled for normal seeks with --mkv-subtitle-preroll. This helps displaying subtitles correctly with ordered chapters. When switching ordered chapter segments, a seek is performed. If the subtitle is timed slightly before the start of the segment, it normally won't be demuxed. This is a problem with all seeks, but in this case normal playback is affected. Since switching segments always uses hr-seeks, the code added by this commit is always active in this situation. If no subtitles are selected or the subtitles come from an external file, the demuxer should behave exactly as before this commit.
* core: add --heartbeat-interval optionwm42013-04-041-3/+4
| | | | | | This closely follows MPlayer commit 36099, with some changes. Move a mutable static variable into MPContext.
* mplayer: switch back to video PTS for reporting playback timewm42013-04-041-10/+6
| | | | | | | | | | | | | | | The main problem with video PTS was that it wasn't very useful when playing audio files with cover art. Using the audio time instead was an obvious solution. Unfortunately, this leads to "inexact" reporting of the playback time in paused mode, and audio is always ahead by small, essentially random amounts of time ahead. This is possibly because the times reported by AOs are not entirely accurate when paused (see commit 9b3bf76). Switch back to video PTS, and use a simpler way to deal with the cover art case: if the video has ended, use the audio PTS. Also see commit f9a259e (and the commits referenced from there).
* mplayer: fix framestepping on ordered chapter segment boundarieswm42013-04-041-28/+34
| | | | | | | | | | | | | | | | | | | Trying to step over a segment boundary didn't work, and the video was stuck at the end of the current chapter. At this point, both video and audio of the segment has ended, and the segment switching code is going to call seek() to go to the next segment (the part of the code in run_playloop that uses end_is_chapter). However, this seek() is not called if playback is paused, and the framestepping code always paused before this code is run. Move the framestepping code below the chapter switching code. The added restart_playback condition makes sure the code is called only after at least one video frame has been shown. Also don't reset the framestep counter after seek. It's not needed, and removing it prevents full unpausing when stepping over a segment boundary. This also terminates playback when frame stepping at the end of the file. The --keep-open option can be used to get the old behavior.
* mplayer: fix --step EOF handlingwm42013-04-041-1/+3
|
* osd: draw the OSD bar with ASS vector drawingswm42013-03-301-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Drawing the bar with vector drawings (instead with characters from the OSD font) offers more flexibility and looks better. This also adds chapter marks to the OSD bar, which are visible as small triangles on the top and bottom inner border of the bar. Change the default position of the OSD bar below the center of the screen. This is less annoying than putting the bar directly into the center of the view, where it obscures the video. The new position is not quite on the bottom of the screen to avoid collisions with subtitles. The old centered position can be forced with ``--osd-bar-align-y=0``. Also make it possible to change the OSD bar width/height with the new --osd-bar-w and --osd-bar-h options. It's possible that the new OSD bar renders much slower than the old one. There are two reasons for this: 1. the character based bar allowed libass to cache each character, while the vector drawing forces it to redraw every time the bar position changes. 2., the bar position is updated at a much higher granularity (the bar position is passed along as float instead of as integer in the range 0-100, so the bar will be updated on every single video frame).
* vo: rename vo_draw_image to vo_queue_imagewm42013-03-281-2/+2
|
* core: always pass data via packet fields to video decoderswm42013-03-281-10/+9
| | | | | | | Makes the code a bit simpler to follow, at least in the "modern" decoding path (update_video_nocorrect_pts() is used with old demuxers, which don't return proper packets and need further parsing, so this code looks less simple now).
* core: output --playing-msg message only after at least one frame is shownwm42013-03-261-6/+8
| | | | | | | | | | | | | | | | This way it's possible to retrieve correct information about video, like actual width/height, which in general are available only after at least one frame has been sent to the video output, such as dwidth/dheight. mpv_identify.sh becomes a bit slower, because we let it decode enough audio and video to fill the audio buffers and to send one frame to the video output. Also, --playing-msg isn't shown anymore with --frames=0 (could be fixed by special-casing it, should this break any use cases). Note that in some corner cases, like when the demuxer for some reason returns lots of audio packets but no video packets at the start, but video actually starts later, the --playing-msg will still be output before video starts.
* mplayer: make --frames=1 work for audiowm42013-03-261-10/+15
| | | | | | | This has the same (useless) definition as frame stepping in audio-only mode: one frame means one playloop iteration. (It's relatively useless, because one playloop iteration has a random duration. But it makes --frames=1 work, which is useful again.)
* mplayer: cosmetics: make some code more readablewm42013-03-261-13/+13
|
* core: remove a number of global variableswm42013-03-081-81/+56
| | | | | | | | | | | Move them into per-instance structs. This should get rid of all global variables in mplayer.c (not counting those referenced by cfg-mplayer.h). In core/input/ar.c, just remove checking the slave_mode variable. I'm not sure what this code was supposed to achieve, but slave mode is broken, slave mode is actually infeasible on OSX (ar.c is completely OSX specific), and the correct way of doing this would be to disable this input device per command line switch.
* vo: Separate vo options from MPOptsAlexander Preisinger2013-03-041-5/+5
| | | | | | | Separate the video output options from the big MPOpts structure and also only pass the new mp_vo_opts structure to the vo backend. Move video_driver_list into mp_vo_opts
* Remove vo_fps global variablewm42013-03-041-3/+12
| | | | | This is needed by the encode stuff for some reason, so we have to explicitly pass it. Functionality shouldn't change.
* vo: remove and cleanup globalsAlexander Preisinger2013-03-041-3/+2
| | | | | | | | Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
* x11_common: fix --cursor-autohide when pausedwm42013-03-031-2/+8
| | | | | | | | When paused, --cursor-autohide worked with a precision of 500ms, which is the main loop's default sleep time when paused. Cursor hiding is polled in x11_common, and the main loop never called the X11 code at the right time. Fix this by allowing the VO to set a time when it should be called next.
* core: fix SEEK_FACTORwm42013-03-011-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Emulate percentage-seeks (SEEK_FACTOR) as normal time-seeks if possible. This fixes some issues with (let's call it) low quality implementations of SEEK_FACTOR (e.g. demux_mkv basically interprets this as byte-seek, and also seeking to 99.9% makes it seek back to the start). For weird MPEG formats the demuxer level SEEK_FACTOR is still used. These formats, which can have timestamp resets, are identified by setting demuxer->ts_resets_possible to true. Also, have get_current_pos_ratio() follow the same rules, and calculate the percentage position with the file position if timestamp resets are possible. This actually fixes percentage-seeks in .ts files with demux_lavf.c. This kind of seek is not really used now, but it will be more important when we add a progress bar. Note: seeking in chained ogg files is still completely broken. The main issue is that ffmpeg doesn't provide a sane API for dealing with timestamp resets, and trying to do byte seeks with ogg confuses demuxer and decoder (or something like this) and just does random things. (Tested with two concatenated flac-in-ogg files).
* core: move X11 specific code to x11_common.cwm42013-03-011-5/+0
| | | | | Nothing changes, because vo_check_events() is called at the same place anyway.
* core: simplify OSD capability handling, remove VFCAP_OSDwm42013-03-011-3/+2
| | | | | | | | | | | | | | | | | | | VFCAP_OSD was used to determine at runtime whether the VO supports OSD rendering. This was mostly unused. vo_direct3d had an option to disable OSD (was supposed to allow to force auto-insertion of vf_ass, but we removed that anyway). vo_opengl_old could disable OSD rendering when a very old OpenGL version was detected, and had an option to explicitly disable it as well. Remove VFCAP_OSD from everything (and some associated logic). Now the vo_driver.draw_osd callback can be set to NULL to indicate missing OSD support (important so that vo_null etc. don't single-step on OSD redraw), and if OSD support depends on runtime support, the VO's draw_osd should just do nothing if OSD is not available. Also, do not access vo->want_redraw directly. Change the want_redraw reset logic for this purpose, too. (Probably unneeded, vo_flip_page resets it already.)
* core: use floats for OSD bar percentage displaywm42013-02-261-15/+16
| | | | | | | Use floats instead of integers in the range 0-100. Currently, the OSD is currently made up of 46 elements so no change should be visible, but rendering of the bar will be changed later to use vector drawings (using pixel coordinates) instead of glyphs. This commit is for preparation.
* core: use playback time to determine playback percent positionwm42013-02-261-6/+16
| | |