summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* demux_lavf: don't let metadata update mess up ogm playbackwm42014-07-141-1/+4
| | | | | | For OGG audio files, we usually merge the per-stream metadata back to the file-global metadata. Don't do that for OGM, because with OGM most metadata is actually per-stream.
* cocoa: fix compilation on OS X 10.8Stefano Pigozzi2014-07-143-4/+35
|
* command: don't show VO information in colorspace propertieswm42014-07-131-3/+1
| | | | | | | | | | Until now, changing the properties showed the VO colorspace parameters on OSD. This didn't work quite well, because it showed the VO parameters _before_ the change. This is because at least one video frame with the new parameters has to be shown, and this doesn't happen right after changing the property, but a bit later. Also fix a random typo in unrelated code.
* Remove some mp_msg calls with no trailing \nwm42014-07-134-47/+53
| | | | | | | The final goal is all mp_msg calls produce complete lines. We want this because otherwise, race conditions could corrupt the terminal output, and it's inconvenient for the client API too. This commit works towards this goal. There's still code that has this not fixed yet, though.
* config: adjust config parser messageswm42014-07-131-5/+4
| | | | Some cleanup. Also, try not to call mp_msg multiple times for 1 line.
* player: remove some inactive codewm42014-07-131-8/+1
| | | | | | | demux_seek() actually doesn't return seek success. Instead, it fails if the demuxer is flagged as unseekable (but this is checked explicitly at the beginning of this function), or if the seek target PTS is MP_NOPTS_VALUE (which can never happen).
* audio: drop buffered audio when switching tracks or filterswm42014-07-132-0/+2
| | | | | | | | No reason to wait until the audio has been played. This isn't a problem with gapless audio disabled, and since gapless is now default, this behavior might be perceived as regression. CC: @mpv-player/stable
* audio: don't wait for draining if pausedwm42014-07-134-15/+16
| | | | | | | | | | | | | Logic for this was missing from pull.c. For push.c it was missing if the driver didn't support it. But even if the driver supported it (such as with ao_alsa), strange behavior was observed by users. See issue #933. Always check explicitly whether the AO is in paused mode, and if so, don't drain. Possibly fixes #933. CC: @mpv-player/stable
* dvdnav: fix time display when starting in the middle of the DVDwm42014-07-131-0/+5
| | | | | | | | | | | | | | | | | | | libdvdnav can actually jump into the middle of the DVD (e.g. scene selection menus do that). Then time display is incorrect: we start from 0, even though playback time is somewhere else. This really matters when seeking. If the display time mismatches, a small relative seek will apparently jump to the beginning of the movie. Fix this by initializing the PTS stuff on opening. We have to do this after some small amount of data has been read from the stream (because libdvdnav is crap and doesn't always update the time between seeks and the first read; also see STREAM_CTRL_GET_CURRENT_TIME remarks in cache.c; although this was not observed when testing with scene selection menus). On the other hand, we want to do it before opening the demuxer, because that will read large amounts of data and likely will change the stream position. Also see commit 49813670.
* stream_dvdnav: suspend read on vts change even if the requested title is not ↵Alessandro Ghedini2014-07-131-1/+0
| | | | found
* DOCS/release-policy: mention the release version in the RELEASE_NOTES templateAlessandro Ghedini2014-07-131-1/+13
| | | | Also suggest adding changes in point releases to RELEASE_NOTES as well.
* input: skip BOM in input.confwm42014-07-121-0/+1
|
* config: skip BOMwm42014-07-121-0/+4
|
* dvd: potentially fix video aspect ratiowm42014-07-121-1/+1
| | | | | This overwrote the source stream header, instead of the stream header exported to the decoder.
* stream: don't sleep for reconnecting network if playback is stoppedwm42014-07-121-0/+2
| | | | | | Also silences the bogus message if that happens. CC: @mpv-player/stable
* cache_file: fix operation if stream size is unknownwm42014-07-121-2/+3
| | | | | | | | | | | | | Happens when playing from a pipe. Note that seeking forward doesn't work. It would be possible to create a workaround for that by reading and skipping data until the target position is reached (and writing the skipped data into the cache file), but I'm not sure about that. Fixes #928. CC: @mpv-player/stable
* osc: improve previous commitChrisK22014-07-101-6/+3
|
* osc: round displayed cache valueChrisK22014-07-101-3/+3
| | | | Fixes #919
* Revert "build: avoid defining _GNU_SOURCE"wm42014-07-102-5/+1
| | | | | | This reverts commit 2e6a8f260ca169e2e1a5646eecfc322de6f77307. Too many problems for now, such as with OSX and asprintf().
* build: include <strings.h> for strcasecmp()wm42014-07-1017-2/+18
| | | | | | | It happens to work without strings.h on glibc or with _GNU_SOURCE, but the POSIX standard requires including <strings.h>. Hopefully fixes OSX build.
* video/out: use strcmp() instead of strcasecmp() for equalizerswm42014-07-103-16/+16
| | | | This makes it more consistent with the more important VOs.
* build: deal with endian messwm42014-07-106-7/+37
| | | | | | | | | | | | | | | | | | | | There is no standard mechanism for detecting endianess. Doing it at compile time in a portable way is probably hard. Doing it properly with a configure check is probably hard too. Using the endian definitions in <sys/types.h> (usually includes <endian.h>, which is not available everywhere) works under circumstances, but the previous commit broke it on OSX. Ideally all code should be endian dependent, but that is not possible due to the dependencies (such as FFmpeg, some video output APIs, some audio output APIs). Create a header osdep/endian.h, which contains various fallbacks. Note that the last fallback uses libavutil; however, it's not clear whether AV_HAVE_BIGENDIAN is a public symbol, or whether including <libavutil/bswap.h> really makes it visible. And in fact we don't want to pollute the namespace with libavutil definitions either. Thus it's only the last fallback.
* build: avoid defining _GNU_SOURCEwm42014-07-092-1/+5
| | | | | | | | | _GNU_SOURCE defines the kitchen sink, and also prefers glibc definitions where glibc and POSIX conflict. Even though POSIX is worth less than toilet paper, we still prefer the POSIX definitions. rar.c needs asprintf(), which is _GNU_SOURCE-only. So we define _GNU_SOURCE too specifically for this file.
* DOCS/tech-overview: minor updateswm42014-07-091-12/+12
|
* demux: remove accurate_seek fieldwm42014-07-083-9/+3
| | | | It's unused now. (Only the dvd code used it until recently.)
* cocoa: simplify logic that returns used bits per colorStefano Pigozzi2014-07-081-9/+1
|
* cocoa: move CGL context creation to gl_cocoaStefano Pigozzi2014-07-083-124/+118
| | | | | | This approach is similar to what other vo_opengl backends do. It can also be used in the future to create another cocoa backend that renders offscreen with IOSurfaces or FBOs.
* demux_disc: flush slave demuxer packet queue on resyncwm42014-07-071-0/+3
| | | | | | Technically needed, but not strictly. It seems it works without in practice, because demux_lavf.c reads exactly one packet for fill_buffer call, so there are never packets queued.
* cache, dvd, bluray: simplify stream time handlingwm42014-07-072-46/+16
| | | | | | | | | | | | | | | | | | We used a complicated and approximate method to cache the stream timestamp, which is basically per-byte. (To reduce overhead, it was only cached per 8KB-block, so it was approximate.) Simplify this, and read/keep the timestamp only on discontinuities. This is when demux_disc.c actually needs the timestamp. Note that caching is currently disabled for dvdnav, but we still read the timestamp only after some data is read. libdvdread behaves well, but I don't know about libbluray, and the previous code also read the timestamp only after reading data, so try to keep it safe. Also drop the start_time offset. It wouldn't be correct anymore if used with the cache, and the idea behind it wasn't very sane either (making the player to offset the initial playback time to 0).
* input: restore ability to combine mouse buttonswm42014-07-071-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Key bindings are decided on the "down" event, so if the prefix is not unique, the first/shortest will be used (e.g. when both "a" and "a-b" are mapped, "a" will always be chosen). This also breaks combining multiple mouse buttons. But it seems users expect it to work, and it's indeed a bit strange that it shouldn't work, as mouse bindings are emitted on the key "up" event, not "down" (if the shorter binding didn't emit a command yet, why shouldn't it be combinable). Deal with this by clearing the key history when a command is actually emitted, instead of when a command is decided. This means if both MOUSE_BTN0 and MOUSE_BTN0-MOUSE_BTN1 are mapped, the sequence of holding down BTN0 and then BTN1 will redecide the current command. On the other hand, if BTN0 is released before BTN1 is pressed, the command is emitted, and the key history is deleted. So the BTN1 press will not trigger BTN0-BTN1. For normal keys, nothing should change, because commands are emitted on the "down" event already, so the key history is always cleared. Might fix #902. CC: @mpv-player/stable (if this fix is successful)
* ao_null: disable latency emulationwm42014-07-071-1/+0
| | | | | | | | | Doesn't work quite right, and will pause for the latency duration after seeking. Some users use --ao=null to disable audio (even though they should probably use --no-audio), and this use-case is broken by this issue too. CC: @mpv-player/stable
* demux: print initial metadatawm42014-07-071-0/+1
| | | | | This was accidentally broken in 7e209185, and metadata was printed only when it changed.
* osc: fix failure when using DVD menuswm42014-07-071-1/+1
| | | | [osc] Lua error: mp.assdraw:31: attempt to concatenate local 's' (a nil value)
* lua: redo error handling, print backtraceswm42014-07-071-82/+90
| | | | | | | | | | | | | | | | | | | | The original goal was just adding backtraces, however making the code safe (especially wrt. to out of memory Lua errors) was hard. So this commit also restructures error handling to make it conceptually simpler. Now all Lua code is run inside a Lua error handling, except the calls for creating and destroying the Lua context, and calling the wrapper C function in a safe way. The new error handling is actually conceptually simpler and more correct, because you can just call any Lua function at initialization, without having to worry whwther it throws errors or not. Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it. There isn't any way to emulate it in a way that works the same on 5.1 and 5.2 with the same semantics in error cases, so ifdeffery is needed. The debug.traceback() function also behaves weirdly differently between the Lua versions, so its output is not as nice as it could be (empty extra line).
* old-configure: fix Lua testswm42014-07-071-1/+2
| | | | This added every Lua that was found on the system.
* Remove stream_pts stuffwm42014-07-069-32/+2
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* DOCS/client-api-changes: try to fix rst formatting againwm42014-07-061-3/+4
|
* dvd, bd: enable precise seekingwm42014-07-061-4/+1
| | | | | | | | | | | | | | | | | | | This should work now, at least kind of. Note that actual success depends on the behavior of the underlying lib{dvd{nav,read},bluray} implementation, which could go very wrong. In the worst case, it could happen that the underlying implementation seeks a long time before the seek target time. In this case, the player will just decode video until the target time is reached, even if that requires e.g. decoding 30 mintues of video before refreshing. In the not-so-bad but still bad case, it would just miss the seek target, and seek past it. In my tests, it works mostly ok, though. Seeking backwards usually fails, unless something like --hr-seek-demuxer-offset=1 is used (this makes it seek to 1 second before the target, which may or may not be enough to compensate for the DVD/BD imprecision).
* dvd, bluray: handle playback display time handling differentlywm42014-07-061-12/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a pretty big change. Instead of doing a half-hearted passthrough of the playback timestamp, we attempt to rewrite the raw MPEG timestamps such that they match with the playback time. We add the offset between raw start timestamp and playback time to the packet timestamps. This is the easy part; but the problem is with timestamp resets. We simply detect timestamp discontinuities by checking whether they are more than 500ms apart (large enough for all video faster than 2 FPS and audio with reasonable framesizes/samplerates), and adjust the timestamp offset accordingly. This should work pretty well. There may be some problems with subtitles. If the first packet after a timestamp reset is a subtitle instead of video, it will fail. Also, selecting multiple audio or video streams won't work (but mpv doesn't allow selecting several anyway). Trying to demux subtitles with no video stream enabled will probably fail. Untested with Bluray, because I have no Bluray sample. Background: libdvdnav/libdvdread/libbluray make this relatively hard. They return a raw MPEG (PS/TS) byte stream, and additionally to that provide a function to retrieve the current "playback" time. The playback time is what should be displayed to the user, while the MPEG timestamps can be completely different. Even worse, the MPEG timestamps can reset. Since we use the libavformat demuxer (instead of parsing the MPEG packets in the DVD/BD code), it's hard to associate between these timestamps. As a result, the time display is special cased in the playloop, and of low quality (updates only all 1 or 2 seconds, sometimes is incorrect). The fact that the stream cache can be between demuxer and the stream source makes things worse. All the libs seem to provide an event that tells whether timestamps are resetting. But since this signalling is byte based, it's hard to connect it to the demuxed MPEG packets. It might be possible to create some sort of table mapping file positions to discontinuities and new timestamps. (For simplicity, this table could be 2 entries large, sufficient to catch all discontinuities if the distance between them is larger than the total buffering.)
* stream_dvdnav: more debugging outputwm42014-07-061-2/+5
|
* demux: fix a corner case related to demux_discwm42014-07-061-5/+8
| | | | | | It can happen that demux_fill_buffer() adds more than 1 packet, and then the packets would add up. Affects demux_disc.c only (nothing else uses this function).
* dvd: fix first subtitle with delayed subtitle streamswm42014-07-063-1/+5
| | | | | | This was accidentally broken with moving the DVD code to demux_disc.c. Also remove an abort() call meant for debugging.
* stream: remove now unused STREAM_CTRL_GET_START_TIMEwm42014-07-064-19/+0
| | | | demux_disc.c takes care of this now.
* demux: minor simplificationwm42014-07-067-12/+9
| | | | Oops, should have been part of commit 37085788.
* ao_pulse: set icon nameatomnuker2014-07-051-0/+2
| | | | Will replace the generic XDG video icon inherited from media role.
* vf_vapoursynth: reset error state on seekingwm42014-07-051-0/+1
| | | | | | | | | | | | When seeking, we violently destroy the filter, because vapoursynth has no proper API for terminating a video with unknown frame count. This looks like an error to vapoursynth, and the error is returned via the frame callbacks. The bug is that we remember this error state across reinitialization, so on the first filter call after reinitialization, we thought filtering the current frame failed. This caused a shift by 1 frame on each seek. CC: @mpv-player/stable
* build: allow compilation without any atomicswm42014-07-053-6/+24
| | | | | | | | | | | | | | | | | | | Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
* options: remove bogus replacement message for --fstypewm42014-07-051-1/+0
| | | | CC: @mpv-player/stable
* options: add --autosub-match to option replacement listwm42014-07-051-0/+1
| | | | CC: @mpv-player/stable
* player: don't use stream position as fallback for percent-poswm42014-07-051-3/+2
| | | | | | | | This should be unneeded, and the packet position is already sufficient for this case. Accessing the stream position directly is going to be a problem when the stream is accessed from another thread later.
* tv: move demuxer parts to separate filewm42014-07-056-252/+267
| | | | | Now all demuxer implementations (at least demuxer API-wise) are in the demux directory.
* demux: minor simplification to internal APIwm42014-07-059-34/+24
| | | | Also some other unrelated minor changes.
* dvd: move angle switching codewm42014-07-053-60/+28
| | | | | No need to provide a "nice" API for it; just do this stuff directly in the command code.
* dvd: flush buffers properly on seekwm42014-07-051-3/+4
| | | | | | | | | | | Suggested by tholin on github issue #882. This is not entirely clean, but the fields we're accessing might be considered internal to libavformat. On the other hand, existence of the fields is guaranteed by the ABI, and nothing in the libavformat doxygen suggestes they're not allowed to be accessed. CC: @mpv-player/stable
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-0519-230/+304
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* discnav: fix a commentwm42014-07-051-1/+1
|
* demux: set filepos field when dequeuing a packetwm42014-07-051-3/+2
| | | | Otherwise the position can be too far ahead.
* demux: cosmetics: minimize codewm42014-07-051-16/+3
|
* demux: make start time a simple fieldwm42014-07-055-20/+11
| | | | Simpler, especially for later changes.
* demux, stream: change metadata notificationwm42014-07-057-63/+57
| | | | | | | | | | | | (Again.) This time, we simply make it event-based, as it should be. This is done for both demuxer metadata and stream metadata. For some ogg-over-icy streams, 2 updates are reported on stream start. This is because libavformat reports an update right on start, while including the same info in the "static" metadata. I don't know if that's a bug or a feature.
* demux: make replaygain per-trackwm42014-07-055-9/+11
| | | | | | It's unlikely that files with multiple audio tracks and with replaygain actually happen, but this change might help avoid minor corner cases with later changes.
* demux: move packet functions to a separate source filewm42014-07-056-108/+135
|
* demux: move packet list functionswm42014-07-053-73/+49
| | | | Move them to the only place where they are used, demux_subreader.c.