summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* options: don't sort sub-option help outputwm42014-04-121-1/+2
| | | | | | Commit 2c2c1203 sorted the output of --list-options, but the same code ias also used for listing sub-options, such as --vo=scale:help. For sub- options, the order actually matters.
* terminal: pretty print modules for --msgmoduleEvan Purkhiser2014-04-121-2/+26
|
* manpage: fix --vf=scale optionsJames Ross-Gowan2014-04-111-3/+3
|
* options: sort --list-optionswm42014-04-111-1/+13
| | | | | | | | | | | | Until now, --list-options printed options in random order. There literally wasn't any logic in its order, they just appeared as they were declared. So just sort them. Note that we can't sort them in advance, because for certain things internal to m_config, the order actually matters. Also we're using strcasecmp(), which is bad (locale dependent), but this is output intended for human consumption, so it's not a problem.
* command: remove extended information from --list-propertieswm42014-04-111-19/+4
| | | | | | This used to display the property type, but it was not always correct or even available. The way the property mechanism works, we can know this only at runtime.
* client API: include the reason in MPV_EVENT_END_FILEwm42014-04-113-1/+29
| | | | | | | | | Otherwise, the client API user could not know why playback was stopped. Regarding the fact that 0 is used both for normal EOF and EOF on error: this is because mplayer traditionally did not distinguish these, and in general it's hard to tell the real reason. (There are various weird corner cases which make it hard.)
* manpage: document how the client API retrieves the complicated propertieswm42014-04-111-0/+82
| | | | | "Complicated" as in they use sub-properties, and using MPV_FORMAT_NODE allows an application to retrieve all information at once.
* lua: add helper function for printing a tablewm42014-04-111-0/+49
| | | | | | | | | | Although this is something really basic, Lua's standard library doesn't provide anything like this. Probably because there are too many ways to do it right or wrong. This code tries to be really careful when dealing with mixed arrays/maps, e.g. when a table has integer keys starting from 1, making it look like an array, but then also has other keys.
* client API: remove outdated commentswm42014-04-111-3/+3
|
* encode: write 2-pass stats only per-packetwm42014-04-111-1/+2
| | | | | | The stats were retrieved and written on every encode call, instead of every encode call that actually returned a packet. ffmpeg.c also does it this way, so it must be "more correct". Fixes 2-pass encoding.
* encode: add a missing \n to a log callwm42014-04-101-1/+1
|
* lua: add a minor helper functionwm42014-04-102-0/+17
|
* client API: improve commentswm42014-04-101-25/+31
|
* terminal-unix: reject overlong termcap stringswm42014-04-101-0/+3
| | | | | | | | Our own tables have size for only 8 chars, so these sequences must be rejected. It seems strings of length 8 are still ok, because the code uses memcmp and not strcmp, so still allow these. Based on mplayer-svn commit r37129.
* joystick: Fix incorrect pointer offset code.reimar2014-04-101-1/+1
| | | | | | | I have some doubts that short reads are even allowed/ possible for /dev/js*, does someone know for sure? git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37132 b3059339-0415-0410-9bf9-f77b7e298cf2
* sws_utils: remove custom GBRP conversionwm42014-04-101-48/+0
| | | | | | | We needed this because the OSD rendering path used GBRP for RGB rendering, and not all swscale versions supported this conversion. But recently we've dropped support for very old ffmpeg/libav versions, so this isn't needed anymore.
* stream_dvd, cache: hack seeking with --cache + dvd:// back into workingwm42014-04-093-41/+3
| | | | | | | | | | | | | | | | | | | This was broken at some unknown point (even before the recent cache changes). There are several problems: - stream_dvd returning a random stream position, confusing the cache layer (cached data and stream data lost their 1:1 corrospondence by position) - this also confused the mechanism added with commit a9671524, which basically triggered random seeking (although this was not the only problem) - demux_lavf requesting seeks in the stream layer, which resulted in seeks in the cache or the real stream Fix this by completely removing byte-based seeking from stream_dvd. This already works fine for stream_dvdnav and stream_bluray. Now all these streams do time-based seeks, and pretend to be infinite streams of data, and the rest of the player simply doesn't care about the stream byte positions.
* cache: fix description of the offset fieldwm42014-04-091-1/+3
| | | | This field sure is a bit strange. I hope the description is correct now.
* cache: change a define to an enumwm42014-04-091-3/+3
| | | | More consistent.
* cache: fix checks/output on initializationwm42014-04-091-8/+3
| | | | | | | resize_cache() checks the size itself and clamps the size to the valid range if necessary, so we don't need these checks. In fact, the checks are different. Also, output the cache size after clamping, instead of before.
* TOOLS: add script for using mpv with youtube-dlNikoli2014-04-091-0/+23
| | | | Signed-off-by: wm4 <wm4@nowhere>
* stream_file: Check the handle for network streamsJames Ross-Gowan2014-04-091-9/+34
| | | | | | | | | | | | | | | | | | | Use NtQueryVolumeInformationFile instead of GetDriveType for detecting remote filesystems on Windows. This has the advantage of working directly on the file handle instead of needing a path and it works unmodified in Cygwin where the previous code wouldn't understand Cygwin paths or symlinks. There is some risk in using NtQueryVolumeInformationFile, since it's an internal function and its behaviour could change at any time or it could be removed in a future version of Windows, however it's documented[1] in the WDK and it's used successfully by Cygwin, so it should be fine. If it's removed, the code should fail gracefully by treating all files as local. [1]: http://msdn.microsoft.com/en-us/library/windows/hardware/ff567070.aspx Signed-off-by: wm4 <wm4@nowhere>
* client: change equality rules for MPV_FORMAT_NONEwm42014-04-091-1/+1
|
* client: add a commentwm42014-04-091-0/+2
|
* cache: simplifywm42014-04-091-25/+17
| | | | | | | Merge the cache_read function into cache_fill_buffer, since there's not much reason to keep them separate. Also, simply call read_buffer() to see if there's any readable data, instead of checking for the condition manually.
* cache: allow resizing at runtimewm42014-04-094-21/+119
| | | | | | | | | | | The only tricky part is keeping the cache contents, which is made simple by allocating the new cache while still keeping the old cache around, and then copying the old data. To explain the "Don't use this when playing DVD or Bluray." comment: the cache also associates timestamps to blocks of bytes, but throws away the timestamps on seek. Thus you will experience strange behavior after resizing the cache until the old cached region is exhausted.
* cache: minor simplificationwm42014-04-091-11/+7
| | | | | | | | The only difference is that the MP_DBG message is not printed anymore if the current user read position is outside of the current cache range. (In order to handle seek_limit==0 gracefully in the normal case of linear reading, change the comparison from ">=" to ">".)
* cache: adjust stream position if necessarywm42014-04-091-1/+6
| | | | | | | | | Until now, this could never happen, because new data was simply always appended to the end of the cache. But for making stream cache resizing easier, doing it this way seems advantageous. It also makes it harder to make the internal state inconsistent. (Before this change it could happen that cache and stream position went out of sync if the read position was adjusted "inappropriately".)
* cache: no short reads in read_bufferwm42014-04-091-16/+21
| | | | | | | Until now, cache_read() (which calls read_buffer()) could return short reads. This was a simplification allowed by the stream interface. But for cache resizing, it will be more practical to make read_buffer() do a full read.
* cache: move ringbuffer read into a separate functionwm42014-04-091-17/+32
| | | | No functional changes yet.
* cache: fix typo in commentwm42014-04-091-1/+1
|
* cache: always update cached controls after running a stream controlwm42014-04-091-0/+1
| | | | | | | Seems like a good idea. One possible bad effect would be slowing down uncached controls, but they're already slow. The good thing is that many controls make intrusive changes to the stream (at least controls which do write accesses), so the cached parameters should be updated.
* osc: fix playlist displayChrisK22014-04-091-2/+2
|
* manpage: --ad-spdif-dtshd=yes works nowwm42014-04-081-1/+2
| | | | | It was fixed a while ago. There are still some issues, as pointed out in the manpage addition.
* vd_lavc: by default, do not show corrupt frameswm42014-04-082-2/+2
| | | | This flips the default value. Use --vd-lavc-show-all=yes to revert.
* demux: add "BIKb" FourCCVika Apelsinova2014-04-081-0/+1
| | | | | | More support for the worst codec ever. Signed-off-by: wm4 <wm4@nowhere>
* client API: avoid redundant property change events if possiblewm42014-04-083-10/+63
| | | | | This is done simply by comparing the previous and current values. Do this only if the requested format is not MPV_FORMAT_NONE.
* command: property set commands should send property change notificationswm42014-04-081-1/+21
| | | | | | | | | Some of these property implementations already send notifications on their own, but most don't. This takes care of them. Of course this still doesn't handle all propertry changes - this is impossible without special-casing each property that can change on its own.
* lua: add API for observing property changeswm42014-04-083-4/+60
| | | | | A low level API was added already earlier, but that was merely a binding for the raw C API. Add a "proper" one, and document it.
* vo_vdpau: add an additional check for timestamp robustnesswm42014-04-081-0/+16
| | | | | | | | | | This might be a good idea in order to prevent queuing a frame too far in the future (causing apparent freezing of the video display), or dropping an infinite number of frames (also apparent as freezing). I think at this point this is most of what we can do if the vdpau time source is unreliable (like with Mesa). There are still inherent race conditions which can't be fixed.
* vo_vdpau: document what WRAP_ADD doeswm42014-04-081-0/+2
| | | | This wasn't necessarily clear.
* vo_vdpau: simplify previous vsync timestamp calculationwm42014-04-081-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
* vo_vdpau: simplify time management and make it more robustwm42014-04-071-68/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_vdpau used a somewhat complicated and fragile mechanism to convert the vdpau time to internal mpv time. This was fragile as in it couldn't deal well with Mesa's (apparently) random timestamps, which can change the base offset in multiple situations. It can happen when moving the mpv window to a different screen, and somehow it also happens when pausing the player. It seems this mechanism to synchronize the vdpau time is not actually needed. There are only 2 places where sync_vdptime() is used (i.e. returning the current vdpau time interpolated by system time). The first call is for determining the PTS used to queue a frame. This also uses convert_to_vdptime(). It's easily replaced by querying the time directly, and adding the wait time to it (rel_pts_ns in the patch). The second call is pretty odd: it updates the vdpau time a second time in the same function. From what I can see, this can matter only if update_presentation_queue_status() is very slow. I'm not sure what to make out of this, because the call merely queries the presentation queue. Just assume it isn't slow, and that we don't have to update the time. Another potential issue with this is that we call VdpPresentationQueueGetTime() every frame now, instead of every 5 seconds and interpolating the other calls via system time. More over, this is per video frame (which can be portantially dropped, and not per actually displayed frame. Assume this doesn't matter. This simplifies the code, and should make it more robust on Mesa. But note that what Mesa does is obviously insane - this is one situation where you really need a stable time source. There are still plenty of race condition windows where things can go wrong, although this commit should drastically reduce the possibility of this. In my tests, everything worked well. But I have no access to a Mesa system with vdpau, so it needs testing by others. See github issues #520, #694, #695.
* lua: add basic mpv_observe_property supportwm42014-04-061-0/+58
| | | | Undocumented and only the most basic functionality for now.
* client API: add a way to notify clients of property changeswm42014-04-065-3/+306
| | | | | | | | | | | | | | | | | | | | | | | | This turned out ridiculously complex. I think it will have to be simplified some day. Main reason for the complexity are: - filtering properties by forcing clients to observe individual properties explicitly (to avoid spamming clients with changes they don't want) - optional retrieval of property value with the notification (the basic idea was that this is more user friendly) - allowing to the client to specify a format in which the value should be retrieved (because if a property changes its type, the client API couldn't convert it properly, and compatibility would break) I don't know yet which of these are important, and everything could change. In particular, the interface and semantics should be adjusted to reduce the implementation complexity. While I consider the API complete, there could (and probably will) be bugs left. Also while the implementation is complete, it's inefficient. The complexity of the property matching is O(a*b*c) with a clients, b observed properties, and c properties changing at once. I threw away an earlier implementation using bitmasks, because it was too unwieldy.
* client API: use a manual ringbufferwm42014-04-061-31/+31
| | | | | | | Remove the use of mp_ring and use a simple array and a bunch of variables instead. This is way less awkwad. The change in reserve_reply fixes incorrect tracking of free events.
* gl_lcms: properly expand the cache filename being writtenStefano Pigozzi2014-04-051-1/+3
| | | | | This is needed to preserve the same path used when opening the cache file, and correctly expands ~ when icc-cache is added to the mpv config file.
* build: bump libbluray minimum versionStefano Pigozzi2014-04-051-1/+1
| | | | | The code uses BD_OVERLAY_HIDE which seems to be available from 0.3.0. Update the pkg-config query.
* build: add -Wempty-body to compiler flagswm42014-04-042-4/+4
| | | | Warns against "if(0);" but not "if(0){}" - perfect for our purposes.
* demux: move metadata-based replaygain decoding out of af_volumeAlessandro Ghedini2014-04-042-80/+87
|
* af_volume: use replaygain side dataAlessandro Ghedini2014-04-041-7/+19
|
* af: add replaygain_data field to af_stream and af_instanceAlessandro Ghedini2014-04-045-0/+7
| | | | Closes #664
* demux: add replaygain_data field to demuxer_tAlessandro Ghedini2014-04-042-1/+47
|
* build: check if replaygain side data is availableAlessandro Ghedini2014-04-042-0/+18
| | | | | | Signed-off-by: wm4 <wm4@nowhere> old-configure change by wm4.
* vo_vdpau: more debugging outputwm42014-04-031-4/+20
| | | | Might help to debug certain problems with Mesa.
* remove redundant/outdated line from encodeing.rst:"what works"Kevin Mitchell2014-04-031-1/+0
|
* lua: give more control over timerswm42014-04-022-14/+47
| | | | | | | | | | | Now they can be paused and resumed. Since pausing and disabling the timer is essentially the same underlying operation, we also just provide one method for it. mp.cancel_timer probably still works, but I'm considering this deprecated, and it's removed from the manpage. (We didn't have a release with this function yet, so no formal deprecation.)
* lua: add mp.unregister_event() functionwm42014-04-012-0/+31
| | | | Someone requested this... I think.
* DOCS/encoding: make "What does not work yet" a proper RST sectionwm42014-04-011-0/+1
|
* gl_lcms: fix build when lcms2 is not availableStefano Pigozzi2014-03-311-0/+5
| | | | Was broken in b0ee9334e.
* vo_corevideo: remove unused variableStefano Pigozzi2014-03-311-1/+0
|
* vo_opengl, cocoa: allow to autoselect a color profileStefano Pigozzi2014-03-318-2/+226
| | | | | | | | | | | | | This commit adds support for automatic selection of color profiles based on the display where mpv is initialized, and automatically changes the color profile when display is changed or the profile itself is changed from System Preferences. @UliZappe was responsible with the testing and implementation of a lot of this commit, including the original implementation of `cocoa_get_icc_profile_path` (See #594). Fixes #594
* ass_mp: don't use --subcp for --ass-styleswm42014-03-311-1/+1
| | | | | | | | | | | | | The --ass-styles option is implemented by calling ass_read_styles(). This function can take a codepage (so libass will use iconv to convert it). This was implemented before our --subcp option was changed, and this code was not updated. Now libass fails opening iconv, because --subcp is not always (and not by default) a valid iconv codepage. Just always pass NULL, which means the file passed to --ass-styles must be in UTF-8. The --ass-styles option is a fringe option anyway (and will destroy your subtitles), so having codepage support for it isn't important at all.
* encode_lavc: copy metadata to output fileAlessandro Ghedini2014-03-304-1/+24
| | | | | | | | Closes #684 Signed-off-by: wm4 <wm4@nowhere> Includes some minor cosmetic changes additional to the original PR.
* command: allow changing filters before video chain initializationwm42014-03-303-6/+22
| | | | | | | Apparently this is more intuitive. Somewhat tricky, because of the odd state after loading a file but before initializing the VO.
* command: change what the metadata property returnswm42014-03-302-11/+29
| | | | | | | Change the type of the property from a string list (alternating key/value entries) to a map. Using the client API, this will return MPV_FORMAT_NODE_MAP, while Lua mp.get_property_native returns a dictionary-like table.
* command: minor simplificationwm42014-03-301-6/+3
|
* command: fix access to "metadata/list" propertywm42014-03-301-0/+14
| | | | | |