summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* audio: fix random crashes on uninitwm42014-09-231-2/+1
| | | | I added this non-sense earlier this day. Oops.
* player: don't let multiline filenames set options on resumewm42014-09-231-4/+7
| | | | | | | | | | | | | | | | | If --write-filename-in-watch-later-config is used, and the filename contains newline characters (as generally allowed on Unix), then the newline will be written to the resume file literally, and the parts after the newline character are interpreted as options. This is possibly security relevant. Change newline characters (and in fact any other special characters) to '_'. Reported as #1099 (this commit is a reimplementation of the proposed pull request). CC: @mpv-player/stable
* player: fix buildAlessandro Ghedini2014-09-101-1/+1
| | | | This fixes a build failure introduced by c269fa1.
* audio: correctly initialize output bufferwm42014-09-051-0/+6
| | | | | | | Just like the previous commit, this takes care of fallout from commit 7ab228, which fixed a bug, but introduced some new ones. CC: @mpv-player/stable
* player: check for null in resume config searchJames Ross-Gowan2014-09-051-1/+2
| | | | | | Signed-off-by: wm4 <wm4@nowhere> CC: @mpv-player/stable
* audio: fix obscure audio resync failure with timelineswm42014-09-052-3/+6
| | | | | | | | | | | | | | | | | Somehow, there was a larger misunderstanding in the code: ao_buffer does not need to be preserved over audio reinit for proper support of gapless audio. The actual AO internal buffer takes care of this. In fact, preserving ao_buffer just breaks audio resync. In the ordered chapter case, end_pts is used, which means not all audio data in the buffer is played, thus some data is left over when audio decoding resumes on the next segment. This triggers some code that aborts resync if there's "audio decoded" (ao_buffer contains something), but no PTS is known (nothing was actually decoded yet). Simplify, and always bind the output buffer to the decoder. CC: @mpv-player/stable (maybe)
* player: properly resume playlists loaded at runtimewm42014-09-031-0/+3
| | | | | | | If a playlist is loaded from the internal playlist (like "mpv playlist.m3u"), then attempt to resume from it. CC: @mpv-player/stable
* player: fix quit handling when seeking past EOF while pausedwm42014-08-311-6/+5
| | | | | | | | | | | | | The player didn't quit when seeking past EOF in audio-only mode while paused. The only case when we don't want to quit is when the last video frame is displayed while paused. This logic was probably broken a while ago, but I'm not exactly sure. CC: @mpv-player/stable Conflicts: player/playloop.c
* audio: restore old speed change behaviorwm42014-08-282-2/+2
| | | | | | | | | | | | | | | | | | | | Don't attempt to resync after speed changes. Note that most other cases of audio reinit (like switching tracks etc.) still resync, but other code paths take care of setting the audio_status accordingly. This restores the old behavior of not trying to fix audio desync, which was probably changed with commit 261506e3. Note that the code as of now wasn't even entirely correct, since the A/V sync values are slightly shifted. The dsync depends on the audio buffer size, so a larger buffer size will show more extreme desync. Also see mplayer2 commit 213a224e, which should fixed this - it was not merged into mpv, because it disabled audio for too long, resulting in a worse user experience. This is similar to the issue this commit attempts to fix. Fixes: #1042 (probably) CC: @mpv-player-stable
* options: compatibility hack for --slave-brokenwm42014-08-251-0/+6
| | | | | | | Seems some programs were still relying on it. Whatever, it's not hard to support. CC: @mpv-player/stable
* player: don't clobber playback position on video endwm42014-08-251-5/+3
| | | | | | | | If video reaches EOF, and audio is also EOF (or is otherwise not meaningful, like audio disabled), then the playback position was briefly set to 0. Fix this by not trying to use a bogus audio PTS. CC: @mpv-player/stable (maybe)
* player: don't quit with --loop-filewm42014-08-131-0/+1
| | | | | | Fixes #1009. CC: @mpv-player/stable
* video: don't keep multiple pointers to hwdec info structwm42014-08-111-1/+1
| | | | This makes a certain corner case simpler at a later point.
* player: remove cache status from video OSDwm42014-08-111-3/+0
|
* video: fix dangling pointer issuewm42014-08-111-1/+1
| | | | | | | | | | | The function video_decode_and_filter(), called between initializing the local vf variable and using it, can actually destroy and recreate the filter. Thus, the vf variable turns into a dangling pointer if that happens. Could be observed with: --hwdec=vda --deinterlace=yes --vf=yadif (Also happens with vdpau/vaapi.)
* command: for OSD, format cache property as integerwm42014-08-111-0/+5
| | | | For convenience. Use ${=cache} to get the old formatting.
* command: fix dangling pointer issue in script key bindings codewm42014-08-111-1/+1
| | | | | | | | This code was sending a string to a different thread, and then deallocated the string shortly after, which means most of the time the other thread was accessing a dangling pointer. It's possible that this is the cause for #1002.
* player: don't delay OSD redraw when pausedwm42014-08-101-2/+4
| | | | We want this heuristic to trigger during normal playback only.
* video: remove "hard" framedrop modewm42014-08-091-1/+1
| | | | | | | | | Completely useless, and could accidentally be enabled by cycling framedrop modes. Just get rid of it. But still allow triggering the old code with --vd-lavc-framedrop, in case someone asks for it. If nobody does, this new option will be removed eventually.
* command: run OSD display code even if a property is unavailablewm42014-08-091-4/+2
| | | | | | | | | | | | | | Trying to jump chapters in a gile that has no chapters does nothing, not even show a warning. This is confusing. The reason is that the "add chapter" command will just bail out completely if the property is unavailable. This was because it exited when it couldn't get the property type. Instead of exiting, just don't enter the code that needs the type. (I'm not sure when this behavior changed. I consider it a regression. It was probably caused by changes to the chapter code, which perhaps started returning UNAVAILABLE instead of OK if there are no chapters.)
* command: add a "seeking" propertywm42014-08-081-0/+10
| | | | | | The client API exports this state via events already, but maybe it's better to explicitly provide this property in order to facilitate use on OSD and similar cases.
* player: indicate on the status line whether a seek is activewm42014-08-081-1/+3
| | | | | | This is delayed by 300ms - before that, the status doesn't change. I feel like it would too annoying if the status line would "flicker" on normal seek by quickly showing and hiding the indicator.
* audio: fix encoding modewm42014-08-071-1/+2
| | | | | | | | | If this code is not skipped, encoding (or dumping with --ao=pcm) will attempt to adjust video timing to audio. Since another commit (0cce8fe6) already avoids writing audio ahead, this didn't slow down encoding to realtime, but it was still significantly slower. This change should actually remove all extra sleeping.
* player: remove unused declarationwm42014-08-071-1/+0
|
* client API: trigger MPV_EVENT_VIDEO_RECONFIG on vf recreationwm42014-08-061-0/+2
| | | | | Until now, it was done only on VO reconfig, but this easily can miss some events, in case the VO output format doesn't change.
* audio: fix inverted conditionwm42014-08-061-6/+4
| | | | | Recent regression. Could perhaps make gapless audio fail to work correctly.
* cocoa: fix build by using the correct HAVE_* macroStefano Pigozzi2014-08-062-6/+6
| | | | | | | | | | This builds but both the libmpv example and the cplayer block infinitely when building libmpv. That's because we wait inifinitely in `dispatch_sync` as there's no event loop in the main thread that allows for libdispatch to work.. Whiel we are at it, we should probably investigate how to use mp_dispatch instead since it is a little lower level and could give us higher control in building and event loop.
* cocoa: move set_input_context to macosx_eventsFRAU KOUJIRO2014-08-061-0/+1
|
* sub: fix subtitle timing for TSwm42014-08-041-2/+6
| | | | | | | | The subtitle timing logic always used the demuxer's start time as video offset. This made external subtitle files "just work" with file formats like TS, which usually have a non-0 start time. But it was wrong for subtitles muxed with the TS, so adjust the time offset explicitly with external files only.
* sub: don't read packets if video and audio are disabledwm42014-08-041-1/+1
| | | | | | | | | Although disabling both video and audio is surely an obscure corner case, it's allowed, and we don't want the demuxer to skip arbitrary packets. Basically, make the heuristic for checking interleaved files affect external files only.
* player: some further playloop cleanupswm42014-08-032-45/+45
| | | | | | | | | | | | | Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
* 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.)
* 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...)
* command: add a property that returns a list of all propertieswm42014-08-023-21/+25
| | | | Also remove the undocumented Lua mp.property_list() function.
* Remove the last remains of slave modewm42014-08-011-9/+2
| | | | | | | | | | | 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.
* 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-311-1/+14
|
* client API: make "cache" property and similar observablewm42014-07-314-0/+17
| | | | | | 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"
* 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.
* 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
|
* 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-291-1/+4
| | | | | | | | | | | | 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.
* 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
| | | | | | | | | | | | | | | | | | | | |