summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* stream_pvr: Fix fd check, -1 indicates invalid, not 0.reimar2014-01-231-1/+1
| | | | git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36677 b3059339-0415-0410-9bf9-f77b7e298cf2
* audio: fix balance controlwm42014-01-231-2/+2
| | | | | | | | Balance controls as used by mixer.c was broken, because af_pan.c stopped accepting its arguments. We have to allow 0 channels explicitly. Also, fix null pointer access if the matrix parameter is not used. Regression from commit 82983970.
* demux_mkv: nicer edition outputwm42014-01-233-13/+65
| | | | | | | | | | | If there's more than one edition, print the list of editions, including the edition name, whether the edition is selected, whether the edition is default, and the command line option to select the edition. (Similar to stream list.) Move reading the tags to a separate function process_tags(), which is called when all other state is parsed. Otherwise, that tags will be lost if chapters are read after the tags.
* demux_mkv: don't attempt to seek back when indexingwm42014-01-221-8/+0
| | | | | | | | | | | | Pretty worthless. This is called from the seek code, which will reinitialize these anyway. Even if seeking somehow decides to fail, the new values are still valid. One could say a failed seek (if that happens) should jump back to the original position, and thus it would be better to make sure the state is restored. But then demux_mkv_seek needs to do this correctly, including not setting up skipping to the target timestamp. But not bothering with this.
* demux_mkv: fix EOF with concatenated segmentswm42014-01-221-7/+14
| | | | | | | | | Extremely obscure corner case with concatenated segments, in which EOF wasn't recognized correctly, and it tried to demux clusters from the next segment. See [MKV]_Editions,_Linked_Segments,_&_Tracksets.mkv from the CCCP test file collection.
* demux_mkv: remove old track printing codewm42014-01-221-12/+0
| | | | | | This basically used to be part of the user interface, before mpv moved printing the track list to the frontend, and this code was raised to verbose output level.
* demux_mkv: always fail on header reading errorwm42014-01-221-6/+2
| | | | | | | | | | | For some reason, if an error happened when reading headers, it merely stopped reading the headers, and then continued normally. (It looks like the case to exit hard (-2) was mainly used for skipping unwanted ordered chapter segments.) I can't comprehend this. Always exit on error when reading headers. (Maybe some more error tolerance would be good, but I have no test case, and there's some danger of entering endless loops.)
* demux_mkv: avoid seeking when reading headerswm42014-01-221-128/+116
| | | | | | | | | This makes everything more robust, and also somewhat simpler (even if the diffstat isn't very impressive). Instead of recursively following SeekHeads while reading headers, just read the headers until the first cluster, and then possibly use SeekHeads to read the remaining missing headers.
* aspect: remove a small ffmpeg dependencywm42014-01-221-4/+2
| | | | | Not strictly needed, but probably saves us pain the next time ffmpeg mess up their headers.
* vo: merge get rid of vo.aspdat fieldwm42014-01-225-109/+91
| | | | | | | | | | | | Rename vo_get_src_dst_rects() to mp_get_src_dst_rects() and make it independent from the VO (it takes a comical amount of parameters now to pass all required state). Add a convenience wrapper with the name vo_get_src_dst_rects() to vo.c. Replace all aspdat and vo usages with immediate parameters. Functionally, nothing should change, except that the window size is clamped to a minimum of size 1 much earlier, and some log messages change the prefix (don't bother with vo.vo_log stuff).
* vo: move vo_get_src_dst_rects to aspect.cwm42014-01-222-128/+130
| | | | | | | The plan is to make all the code in aspect.c independent from vo.c, which should make the code easier to understand, will allow removal of vo->aspdat, and reduces the amount of code that accesses weird mutable struct vo fields.
* video/out: don't access aspdat in VOswm42014-01-2210-47/+38
| | | | | | | | | | | vo->aspdat is basically an outdated version of vo->params, plus some weirdness. Get rid of it, which will allow further cleanups and which will make multithreading easier (less state to care about). Also, simplify some VO code by using mp_image_set_attributes() instead of caring about display size, colorspace, etc. manually. Add the function osd_res_from_image_params(), which is often needed in the case OSD renders into an image.
* vo_opengl: don't assume there'a always 1 fbconfig on successwm42014-01-211-1/+1
| | | | Seems to be a reasonable assumption, but it's probably not guaranteed.
* cocoa: remove dead codeStefano Pigozzi2014-01-212-8/+0
| | | | This became dead code in commit 3f594c2e.
* waf: try to fix unicode/byte string messupwm42014-01-211-1/+1
| | | | | | | Some mpv builds identify with e.g. "mpv b'0.3.3' ". The version looks like str() was called on a Python byte string. I couldn't reproduce it on my machine (I tried with both Python 2 and 3), so I'm not exactly sure what's going on here, but I'm hoping this commit does fix it.
* lua: allow ~ path convention for --luawm42014-01-211-1/+3
| | | | | Paths passed to the --lua option now follow the convention for paths starting with ~ documented in mpv.rst.
* w32_common: Fix extended keysJames Ross-Gowan2014-01-211-1/+1
| | | | The KF_* flags work on the HIWORD of lParam. Whoops
* lua: add playback-start eventwm42014-01-203-0/+4
|
* playlist_parser: restore ASX parsing etc.wm42014-01-201-8/+8
| | | | | | This was broken yesterday: the playlist demuxer will always fall back to plaintext playlist files, which will cause the ASX playlist parser and some others never to be called.
* player: fix initial osd progbar statewm42014-01-201-0/+1
| | | | This made seeking show an empty progbar if --osd-level=0 was used.
* cocoa: sort files opened from Finder the same way Finder doesBilal Syed Hussain2014-01-201-1/+2
| | | | Fixes #497
* manpage: fix af_equalizer syntaxwm42014-01-191-1/+1
| | | | This doesn't need quoting, for some reason.
* demux_playlist: move parser for plaintext playlistswm42014-01-192-22/+23
| | | | | This was implemented in playlist_parser.c. To make it use the improved implementation of stream_read_line(), move it to demux_playlist.c.
* stream: print stream_read_line warnings by defaultwm42014-01-191-1/+1
| | | | | | | | This is probably ok. Probing could hit this case very often, since it'll mean running this function on potentially binary data, but on the other hand, probing usually uses a memory stream (to limit the amount of data read), and memory streams have s->log silenced (details see open_memory_stream()).
* stream: treat embedded 0 bytes as error in stream_read_linewm42014-01-191-1/+1
| | | | Text files should never contain these.
* stream: redo stream_read_line()wm42014-01-191-114/+54
| | | | | | | | | This simplifies the implementation and should make it more robust. For example, we return an error if a line is longer than the provided buffer (instead of splitting the line). The code is much shorter, because now finding the new line and reading characters is done in one go.
* demux_playlist: handle stream_read_line() errorswm42014-01-191-2/+6
| | | | | | | | | As of this commit, stream_read_line() can't actually error (except in the case the passed in buffer is 0, which never happens here). This commit is preparation for the following commit, which checks harder whether the read data is actually text. Before this commit, an error was treated as end-of-file, but the data read so far was considered valid.
* af: fixed out-of-bounds accesses caused by NUM_FMT and co.11rcombs2014-01-191-18/+18
| | | | | | | | | Signed-off-by: wm4 <wm4@nowhere> This merges pull request #496. The problem was that at least the initialization of the distance[] array accessed af_fmtstr_table[] entries that were out of bounds. Small cosmetic changes applied to the original pull request.
* w32: use the w32_common keymap in terminal-win tooJames Ross-Gowan2014-01-196-99/+139
|
* cookies.c: cols must (and does) have 7 elements.reimar2014-01-191-1/+1
| | | | | | | Doesn't affect the generated code, but avoids confusion in both humans and newer Coverity versions. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36623 b3059339-0415-0410-9bf9-f77b7e298cf2
* vcd_read: Fix sizeof argument.reimar2014-01-191-1/+1
| | | | | | | | | The struct we need to copy is actually a cdrom_msf0, not cdrom_msf. Even though the kernel for no good reason reads it in as a cdrom_msf struct, but only uses the part shared with cdrom_msf0 - this is probably a kernel bug. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36622 b3059339-0415-0410-9bf9-f77b7e298cf2
* mpv.desktop: add some more mimetypeswm42014-01-181-1/+1
| | | | | | Again from github issue #484. Also, sorry for the typo in the earlier commit message.
* player: prevent null pointer deref on uninit after -Vwm42014-01-181-0/+2
| | | | Caused by the OSD changes. Fixes #490.
* mkv.desktop: add two more mime typeswm42014-01-181-1/+1
| | | | Stolen from github issue #484. No idea whether they're needed.
* osd: fix dvdnav highlightswm42014-01-181-1/+2
| | | | Broken by previous commit.
* sub: uglify OSD code path with lockingwm42014-01-1825-244/+416
| | | | | | | | | | | | | | | Do two things: 1. add locking to struct osd_state 2. make struct osd_state opaque While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses lots of osd_state (and osd_object) members. To make sure everything is accessed synchronously, I prefer making osd_state opaque, even if it means adding pretty dumb accessors. All of this is meant to allow running VO in their own threads. Eventually, VOs will request OSD on their own, which means osd_state will be accessed from foreign threads.
* sub: uglify sub decoder with lockingwm42014-01-174-7/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | The plan is to make the whole OSD thread-safe, and we start with this. We just put locks on all entry points (fortunately, dec_sub.c and all sd_*.c decoders are very closed off, and only the entry points in dec_sub.h let you access it). I think this is pretty ugly, but at least it's very simple. There's a special case with sub_get_bitmaps(): this function returns pointers to decoder data (specifically, libass images). There's no way to synchronize this internally, so expose sub_lock/sub_unlock functions. To make things simpler, and especially because the lock is sort-of exposed to the outside world, make the locks recursive. Although the only case where this is actually needed (although trivial) is sub_set_extradata(). One corner case are ASS subtitles: for some reason, we keep a single ASS_Renderer instance for subtitles around (probably to avoid rescanning fonts with ordered chapters), and this ASS_Renderer instance is not synchronized. Also, demux_libass.c loads ASS_Track objects, which are directly passed to sd_ass.c. These things are not synchronized (and would be hard to synchronize), and basically we're out of luck. But I think for now, accesses happen reasonably serialized, so there is no actual problem yet, even if we start to access OSD from other threads.
* player: remove OSD message IDswm42014-01-174-66/+39
| | | | | | These were needed before the last commit, but now they don't do anything anymore. (They were used to decide whether to replace or stack the previous OSD message when a new one was displayed.)
* player: remove OSD stackwm42014-01-173-58/+15
| | | | | | | | | | | If certain OSD messages were displayed at the same time, the hidden messages were put on the stack, and displayed again once the higher priority messages disappeared. The idea was probably that lower priority messages could not hide higher priority ones, and also that the lower messages did not get lost. But in practice, this gives confusing results with OSD messages randomly reappearing for a brief time. Remove it.
* player: don't use OSD message stack for term OSD subswm42014-01-172-13/+17
| | | | | | | | Showing subtitles on terminal used the OSD message stack (which uses a stack to "pile up" messages that were displayed at the same time). This had a bunch of weird and annoying consequences. This accessed a certain osd_state field, which is a minor annoyance since I want to make that struct opaque. Implement this differently.
* cache: remove debug codewm42014-01-171-1/+0
| | | | | | This was accidentally committed. <rcombs> `mp_sleep_us(100000);` <-- are you drunk?
* lua: add a --lua-opts option, which can be queried by scriptswm42014-01-164-0/+23
| | | | | | | The values set by this new option can be queried by Lua scripts using the mp.getopt() function. The function takes a string parameter, and returns the value of the first key that matches. If no key matches, nil is returned.
* options: add key/value pair list option typewm42014-01-162-0/+69
|
* cache: reduce message spamwm42014-01-161-7/+16
| | | | Output only 1 message every 5 seconds at most.
* mpv.desktop: use %U in desktop file as we can open urlsTomáš Chvátal2014-01-161-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* lua: use core log level nameswm42014-01-162-12/+3
| | | | | | When the Lua code was written, the core didn't have names for log levels yet (just numbers). The only user visible change is that "verbose" becomes "v", since this level had different names.
* lua: allow scripts to snoop messageswm42014-01-161-10/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds the following Lua function to enable message events: mp.enable_messages(size, level) size is the maximum number of messages the ringbuffer consists of. level is the minimum log level for a message to be added to the ringbuffer, and uses the same values as the mp.log() function. (Actually not yet, but this will be fixed in the following commit.) The messages will be delivered via the mp_event() in the user script, using "message" as event name. The event argument is a table with the following fields: level: log level of the message (string as in mp.log()) prefix: string identifying the module of origin text: contents of the message As of currently, the message text will contain newline characters. A message can consist of several lines. It is also possible that a message doesn't end with a newline, and a caller can use multiple messages to "build" a line. Most messages will contain exactly 1 line ending with a single newline character, though. If the message buffer overflows (messages are not read quickly enough), new messages are lost until the queued up messages are read. At the point of the overflow, a special overflow message is inserted. It will have prefix set to "overflow", and the message text is set to "". Care should be taken not to print any messages from the message event handler. This would lead to an infinite loop (the event handler would be called again after returning, because a new message is available). This includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua print() function is mapped to mp.msg.info().
* msg: expose log level nameswm42014-01-163-3/+7
|
* msg: add a mechanism to output messages to a ringbufferwm42014-01-162-18/+152
| | | | | | | | | | | | | | | | | | | | | | | | | Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
* msg: fix typo in commentwm42014-01-161-1/+1
|
* msg: move special declarations to msg_control.hwm42014-01-169-13/+27
| | | | | While almost everything uses msg.h, the moved definitions are rarely needed by anything.
* msg: print module prefixes even if message contains newlineswm42014-01-161-12/+23
| | | | | | | | | | | | | | This makes mp_msg(x, y, "a\nb\n") behave the same as mp_msg(x, y, "a\n") mp_msg(x, y, "b\n") which is probably what one would expect. Before this commit, the "b" line didn't have a prefix when using ths single mp_msg call.
* io/win32: move mp_attach_console to terminal-win.cMartin Herkt2014-01-164-24/+17
| | | | Why didn't I put it there from the start?
* player: handle the corner cases in --term-osd-bar correctlyJohannes Nixdorf2014-01-151-3/+3
| | | | With the old code and pos == width - 2 one character too many is drawn.
* player: use more than 1/100 resolution for --term-osd-barJohannes Nixdorf2014-01-151-1/+2
| | | | | If the terminal width is large enough the position marker jumps over several characters because currently pos only increases in 1/100th steps.
* osc: check for availabillity of percent-pos instead of lengthChrisK22014-01-151-2/+2
| | | | ... to decide wether the seekbar should be enabled or not.
* command: if playback position is unknown, make percent-pos unavailablewm42014-01-151-3/+8
| | | | | | | Before that, it just returned -1. The print case is inconsistent with that, but I'll leave it for now, because it's consistent with status line / show_progress behavior.
* w32_common: add extended keysJames Ross-Gowan2014-01-151-23/+54
| | | | Also VK_APPS/MP_KEY_MENU was missing.
* player: add --term-osd-bar, which shows a status bar on the terminalwm42014-01-154-0/+47
| | | | | Feature request from github issue #451. Disabled by default, will probably stay this way.
* bstr: add function for splitting UTF-8wm42014-01-152-1/+18
|
* msg: update commentwm42014-01-151-1/+1
|
* msg: terminal OSD uses stderr, not stdoutwm42014-01-151-1/+1
| | | | | | This is more correct. E.g. if you do "mpv file.mkv > /dev/null", stdout will not be a terminal, but stderr (used by terminal OSD and status line) is.
* w32_common: prevent decoding certain keys twiceJames Ross-Gowan2014-01-151-12/+34
| | | | | | | | This is a bit of a hack, but in order to prevent TranslateMessage from seeing WM_KEYDOWN messages that we already know how to decode, move the decoding logic to the event loop. This should fix #476, since it stops the generation of extraneous WM_CHAR messages that were triggering more than one action on keydown.
* Detect Lua on FreeBSDGrzegorz Blach2014-01-152-1/+3
|
* player: don't print status in --idle modewm42014-01-141-1/+1
| | | | Apparently this annoys certain users. Restores old behavior.
* player: avoid stalling when starting a network streamwm42014-01-143-2/+9
| | | | | | | | | | | | Starting a network stream could stall by executing uncacheable stream control requests (STREAM_CTRL_GET_LANG and STREAM_CTRL_GET_DVD_INFO). Being uncacheable means the player has to wait until the cache is done reading the current block of data. These requests can't be cached because they're too complicated, so the only way to avoid them is special casing the DVD and Bluray streams (which are the only things which need these requests), and not doing them in other cases. (This is