summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* player: make quit exit immediatelywm42014-08-031-3/+3
| | | | | Stopping playback canceled waiting, but executed the remainder of the playloop, including things like executing pointless seeks.
* player: allow redrawing screen during seekswm42014-08-031-6/+12
| | | | | | | | If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
* manpage: be more explicit where input.conf is locatedwm42014-08-022-1/+6
|
* Improve setting AVOptionswm42014-08-0213-149/+66
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* manpage: explain how to replace --slave-brokenwm42014-08-021-0/+10
|
* player: don't show the path part for external subtitle fileswm42014-08-021-1/+1
| | | | Show the filename only. Feature request on IRC.
* client API: minor optimizations for property notificationwm42014-08-024-38/+91
| | | | | | | | | | | | | | | | | | | | | Internally, there are two mechanisms which can trigger property notification as used with "observed" properties in the client API. The first mechanism associates events with a group of properties that are potentially changed by a certain event. mp_event_property_change[] declares these associations, and maps each event to a set of strings. When an event happens, the set of strings is matched against the list of observed properties of each client. Make this more efficient by comparing bitsets of events instead. This way, only a bit-wise "and" is needed for each observed property. Even better, we can completely skip clients which have no observed properties that match. The second mechanism just updates individual properties explicitly by name. Optimize this by using the property index instead. It would be nice if we could reuse the first mechanism for the second one, but there are too many properties to fit into a 64 bit mask. (Though the limit on 64 events might get us into trouble later...)
* TOOLS: add test script for property change notificationswm42014-08-021-0/+16
|
* command: add a property that returns a list of all propertieswm42014-08-024-21/+27
| | | | Also remove the undocumented Lua mp.property_list() function.
* manpage: remove duplicated misplaced description of a commandwm42014-08-021-2/+0
|
* win32: fix assertion failurewm42014-08-011-12/+10
| | | | | | | | If OpenGL 3.x doesn't work, the fallback to legacy GL will call the function to create the DC again, and it will assert. Just make it not to, and also simplify the code a bit. Fixes #974.
* Remove the last remains of slave modewm42014-08-019-76/+15
| | | | | | | | | | | Almost nothing was left of it. The only thing this commit actually removes is support for reading input commands from stdin. But you can emulate this via: --input-file=/dev/stdin --input-terminal=no However, this won't work on Windows. Just use a named pipe.
* vda: only support the new hwaccel 1.2 API (remove old code)Stefano Pigozzi2014-08-013-167/+19
| | | | | | | | | Since the new hwaccel API is now merged in ffmpeg's stable release, we can finally remove support for the old API. I pretty much kept lu_zero's new code unchanged and just added some error printing (that we had with the old glue code) to make the life of our users less miserable.
* travis: use homebrew to build ffmpeg on OS XStefano Pigozzi2014-08-011-18/+58
| | | | | This allows us to use a newer version of ffmpeg and to test the build of our VDA code.
* player: don't ignore first chapterwm42014-07-311-1/+1
| | | | | It's a mystery why this was done this way. If the first chapter starts later than the current position, we do have to return -1.
* video: fix attached picture modewm42014-07-311-1/+3
| | | | | | | | | Playing audio files with embedded cover art broke due to some of the recent changes. Treat video EOF properly, and don't burn the CPU. Disable hrseek for video in attached picture mode, since the decoder will always produce a new image, which makes hrseek never terminate. Fixes #970.
* audio: simplify conditionwm42014-07-311-1/+1
| | | | | The expression added with the previous commit (0cce8fe6) looked slightly more complicated than it has to be. The code is equivalent.
* audio: fix A/V sync in encoding modewm42014-07-311-0/+5
| | | | | | | | | | | | | | | | | | | | | In encoding mode, the AO pretends to be infinitely fast (it will take whatever we write, without ever rejecting input). Commit 261506e3 broke this somehow. It turns out an old hack dealing with this was accidentally dropped. This is the hunk of code whose semantics were (partially) dropped: if (mpctx->d_audio && (mpctx->restart_playback ? !video_left : ao_untimed(mpctx->ao) && (mpctx->delay <= 0 || !video_left))) { int status = fill_audio_out_buffers(mpctx, endpts); // Not at audio stream EOF yet audio_left = status > -2; } This if condition is pretty wild, and it looked like it was pretty much for audio-only mode, rather than subtle handling for encoding mode.
* client API: don't send internal events to the clientswm42014-07-311-1/+2
| | | | | | | "Internal" events were added in the previous commits to leverage the client API property mechanism, without making weird properties public. But they were sent to clients too (and returned by mpv_wait_event()).
* command: add cache-idle propertywm42014-07-312-3/+20
|
* client API: make "cache" property and similar observablewm42014-07-315-0/+18
| | | | | | Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
* client API: fix deadlock when calling mpv_terminate_destroy before initwm42014-07-311-1/+1
| | | | | | | | | | This is perfectly allowed, but was ignored, because it's a corner case. It doesn't actually wait for other clients to be destroyed, but on the other hand I think there's no way to have other clients before initialization. CC: @mpv-player/stable
* player: rename a variablewm42014-07-301-3/+3
| | | | | Make it clear that this condition happens when switching to a new timeline segment. It doesn't even need to coincide with a chapter.
* player: move video display code out of the playloopwm42014-07-304-332/+336
| | | | | | | | | | Basically move the code from playloop.c to video.c. The new function write_video() now contains the code that was part of run_playloop(). There are no functional changes, except handling "new_frame_shown" slightly differently. This is done so that we don't need new a new MPContext field or a return value for write_video() to signal this condition. Instead, it's handled indirectly.
* player: split seek_reset()wm42014-07-306-56/+59
| | | | | | | | This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
* video: actually flush filter chainwm42014-07-301-1/+4
| | | | | | | Frames buffered in filters weren't flushed, so on EOF, the last frames were dropped, depending on how much filters buffered. Oops. Test case: "mpv something.jpg --vf=buffer"
* video/filter: add vf_bufferwm42014-07-305-0/+103
| | | | Mostly useful for debugging.
* audio: better sync behavior on bogus EOFwm42014-07-301-1/+3
| | | | | | | In situations when the demuxer reports EOF, but immediately "recovers" after that and returns new data, it could happen that audio sync was skipped. Deal with this by actually entering the EOF state, instead of assuming this will happen later.
* ao_alsa: disable use of non-interleaved formats by defaultwm42014-07-302-0/+10
| | | | | | | | Some ALSA plugins take non-interleaved audio, but treat it as interleaved, which results in various funny bugs. Users keep hitting this issue, and it just doesn't seem worth the trouble. CC: @mpv-player/stable
* cocoa: fix key equivalent dispatchingStefano Pigozzi2014-07-302-22/+7
| | | | | | | | | | Prior to this commit we had a list of key modifiers and checked against that. Actually, the Cocoa framework has a built in way to do it and it involves calling performKeyEquivalent: on the menu instance. Fixes #946 cc @mpv-player/stable: this should apply with no conflicts
* client API: fix typos in documentationwm42014-07-301-2/+2
|
* demux_lavf: don't consider EAGAIN as EOF conditionwm42014-07-301-2/+3
| | | | | | | | | | This happens apparently randomly with rtmp:// and after seeks. This eventually leads to audio decoding returning an EOF status, which basically disables audio sync. This will lead to audio desync, even if audio decoding later "recovers" when the demuxer actually returns audio packets. Hack-fix this by special-casing EAGAIN.
* stream: hack-fix rtmp-level seekingwm42014-07-304-11/+22
| | | | | | | | | | | | | This didn't work, because the timebase was wrong. According to the ffmpeg doxygen, if the stream index is -1 (which is what we used), the timebase is AV_TIME_BASE. But this didn't work, and it really expected the stream's timebase. Quite "surprising", since this feature (avio_seek_time) is used by rtmp only. Fixing this properly is too hard, so hack-fix our way around it. STREAM_CTRL_SEEK_TO_TIME is also used by DVD/BD, so a new STREAM_CTRL_AVSEEK is added. We simply pass-through the request verbatim.
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-306-0/+38
| | | | | This commit also creates a private option struct for stream_lavf.c, but since I'm lazy, I'm not moving any existing options to it.
* audio: better initial sync for files where audio starts laterwm42014-07-301-5/+15
| | | | | | | Some files have the first audio much later into the video (for whatever reasons). Instead of appending large amounts of silence to the audio buffer (and refusing to sync if the audio to append is "too large"), just wait until enough video has played.
* audio: cosmetics: remove unused return valuewm42014-07-302-11/+9
|
* demux_mf: allow seeking past the endwm42014-07-301-1/+1
| | | | How's this for a corner case.
* player: fix time display wheen seeking past EOF with --keep-openwm42014-07-304-20/+19
| | | | | | | | | | | | | | Regression since commit 261506e3. Internally speaking, playback was often not properly terminated, and the main part of handle_keep_open() was just executed once, instead of any time the user tries to seek. This means playback_pts was not set, and the "current time" was determined by the seek target PTS. So fix this aspect of video EOF handling, and also remove the now unnecessary eof_reached field. The pause check before calling pause_player() is a lazy workaround for a strange event feedback loop that happens on EOF with --keep-open.
* player: let explicitly imprecise seeks cancel precise seekswm42014-07-291-0/+3
| | | | | | | | | | | If an imprecise seek is issues while a precise seek is ongoing, don't wait up to 300ms (herustistic which usually improves user experience), but instead let it cancel the seek. Improves responsiveness of the OSC after the previous commit. Note that we don't do this on "default-precise" seeks, because we don't know if they're going to be precise or not.
* osc: Do precise seeks on simple clicks on seekbarChrisK22014-07-291-11/+19
|
* audio: ignore (some) decoding errors on initializationwm42014-07-292-1/+5
| | | | | | | | | | | | It probably happens relatively often that the first packet (or even the first N packets) of a stream will fail to decode, but decoding will eventually succeed at a later point. Before commit 261506e3, this was handled by an explicit retry loop (although this was also for other purposes), but with then was changed to abort on the first error. This makes it impossible to decode some audio streams. Change this so that errors are ignored for the first 50 packets, which should make it equivalent to the old code.
* player: fix desync when seeking and switching external trackswm42014-07-296-32/+30
| | | | | | | | | | | | If you for example use --audio-file, disable the external track, seek, and enable the external track again, the playback position of the external file was off, and you would get major A/V desync. This was actually supposed to work, but broke at some time ago (probably commit 2b87415f). It didn't work, because it attempted to seek the stream if it was already selected, which was always true due to reselect_demux_streams() being called before that. Fix by putting the initial selection and the seek together.
* player: remove a pointless fieldwm42014-07-292-5/+4
|
* player: disable hr-seek in .ts fileswm42014-07-291-0/+1
| | | | | | | | Seeking in .ts files (and some other formats) is too unreliable, so there's a separate code path for this case. But it breaks hr-seek. Maybe hr-seek could actually be enabled in this case if we're careful enough about timestamp resets, but for now nothing changes.
* player: allow precise seeking with percent seekswm42014-07-291-2/+1
| | | | I'm not sure why this was explicitly disabled. It's from mplayer2 times.
* manpage: lua: document timer timeout and oneshot fieldswm42014-07-291-0/+14
| | | | | Might be useful for scripts, so document them. (Which means scripts are allowed to use them, without risking breakage.)
* vdpau: don't upload video images in advancewm42014-07-293-39/+11
| | | | | | | | | | | | With software decoding, images were uploaded to vdpau surfaces as they were queued to the VO. This makes it slightly more complicated (especially later on), and has no advantages - so stop doing it. The only reason why this was done explicitly was due to attempts to keep the code equivalent (instead of risking performance regressions). The original code did this naturally for certain reasons, but now that we can measure that it has no advantages and just requires extra code, we can just drop it.
* player: update playback position on seekwm42014-07-291-0/+2
| | | | | | | If the actual PTS is not known yet right after a seek, the "time-pos" property will just return the seek target PTS. For this purpose, trigger a change event to make the client API update the "time-pos" and related properties. (MPV_EVENT_TICK triggers this update.)
* player: logically speed up seek logicwm42014-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | Commit 261506e3 made constant seeking feel slower, because a subtle change in the restart logic makes it now waste time showing another video frame. The slowdown is about 20%. (Background: the seek logic explicitly waits until a video frame is displayed, because this makes it easier for the user to search for something in the video. Without this logic, the display would freeze until the user stops giving seek commands.) Fix this by letting the seek logic issue another seek as soon as the first video frame is displayed. This will prevent it from showing a (useless, slow) second frame. Now it seems to be as fast as before the change. One side-effect is that the next seek happens after the first video frame, but _before_ audio is restarted. Seeking is now silent. I guess this is ok, so we don't do anything about it. Actually, I think whether this happens is probably random; the seeking logic simply doesn't make this explicit, so anything can happen.
* vo_x11: fix build with older Libav versionswm42014-07-281-4/+4
| | | | Why does this happen everytime...
* video: add a default color space for files with no videoNiklas Haas2014-07-281-0/+3
| | | | | | | | | | | | | | | | | | Usually mp_image_params_guess_csp takes care of finding *some* default for a video channel, but files with no video (or with extremely broken configurations) end up leaving the colorspace information as MP_CSP_PRIM_AUTO, which has no associated primaries. As a result of this, color managed OSD messages could not display because they were being color managed to match the (non-existing/absurd) video channel. With this change, such non-spaces will have BT.709 primaries as far as color management and the OSD is concerned. This fixes #961. CC: @mpv-player/stable Signed-off-by: wm4 <wm4@nowhere>
* audio: change playback restart and resyncingwm42014-07-2810-281/+328
| | | | | | | | | | | | | | | | | | | | | This commit makes audio decoding non-blocking. If e.g. the network is too slow the playloop will just go to sleep, instead of blocking until enough data is available. For video, this was already done with commit 7083f88c. For audio, it's unfortunately much more complicated, because the audio decoder was used in a blocking manner. Large changes are required to get around this. The whole playback restart mechanism must be turned into a statemachine, especially since it has close interactions with video restart. Lots of video code is thus also changed. (For the record, I don't think switching this code to threads would make this conceptually easier: the code would still have to deal with external input while blocked, so these in-between states do get visible [and thus need to be handled] anyway. On the other hand, it certainly should be possible to modularize this code a bit better.) This will probably cause a bunch of regressions.
* input: be stricter about rejecting mouse input with --no-input-cursorwm42014-07-272-0/+5
| | | | | | | Apparently this switch means all mouse input should be strictly rejected. Some VO backends (such as X11) explicitly disable all mouse events if this option is set, but others don't. So check them in input.c, which increases consistency.
* vo: remove vo_mouse_movement() wrapperwm42014-07-2712-34/+33
| | | | So that VO backends don't have to access the VO just for that.
* vo: different hack for VOs which need to mangle mouse inputwm42014-07-277-40/+47
| | | | | | | | Follow up on commit 760548da. Mouse handling is a bit confusing, because there are at least 3 coordinate systems associated with it, and it should be cleaned up. But that is hard, so just apply a hack which gets the currently-annoying issue (VO backends needing access to the VO) out of the way.
* ao_pulse: allow disabling timing bug workaroundswm42014-07-262-3/+44
| | | | | | | | | | | | | | | | Add an option that enables using native PulseAudio auto-updated timing information, instead of the manual calculations added in mplayer2 times. You can use --ao=pulse:no-latency-hacks to enable the new code. The code is almost the same as the code that was removed with commit de435ed5, but I didn't readd some bits I didn't understand. Likewise, the option will disable the code added with that commit. In my tests this seemed to work well, though the A/V sync display looks funny when seeking. The default is still the old behavior. See issue #959.
* ao_pulse: remove hacks for ancient PulseAudio versionswm42014-07-263-23/+2
| | | | | | | | | | | This was needed by very old (0.9) versions only. Get rid of it. Unfortunately, I can't cross-check with the original bug report, since the bug URL leads to this: Internal Server Error TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION'
* manpage: eliminate the word "movie"wm42014-07-264-29/+29
| | | | | | | It's evil and sounds outdated. Use the words "media" and "video" instead. Closes #935.
* win32: remove minor non-sensewm42014-07-261-1/+0
| | | | This is done in the wrong thread. Was harmless and had no effect at all.
* win32: move window handling to a separate threadwm42014-07-261-60/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The windows message loop now runs in a separate thread. Rendering, such as with Direct3D or OpenGL, still happens in the main thread. In particular, this should prevent the video from freezing if the window is dragged. (The reason was that the message dispatcher won't return while the dragging is active, so mpv couldn't update the video at all.) This is pretty "rough" and just hacked in, and there's no API yet to make this easier for other backends. It will be cleaned up later once we're sure that it works, or when we know how exactly it should work. One oddity is that OpenGL is actually completely managed in the renderer thread, while e.g. Cocoa (which has its own threading code) creates the context in the GUI thread, and then lets the renderer thread access it. One strange issue is that we now have to stop WM_CLOSE from actually closing the window. Instead, we wait until the playloop handles the close command, and requests the VO to shutdown. This is done mainly because closing the window apparently destroys it, and then WM_USER can't be handled anymore - which means the playloop has no way to wakeup the GUI thread. It seems you can't really win here... maybe there's a better way to have a thread receive messages with and without a window, but I didn't find one yet. Dragging the window (by clicking into the middle of it) behaves strangely in wine, but did