summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.1.7v0.1.7release/0.1wm42013-09-201-1/+1
|
* manpage: af_volnorm was renamedwm42013-09-202-1/+2
|
* vf: fix filter initialization error checkwm42013-09-201-1/+1
| | | | | vf_open returns 0 on error, 1 on success. Oops. Accidentally broken with 6629a95.
* ao_pulse: bug fix: goto the correct error handlerJohan Kiviniemi2013-09-201-2/+2
| | | | | Conflicts: audio/out/ao_pulse.c
* ao_pulse: set the property media.role=videoJohan Kiviniemi2013-09-201-2/+17
| | | | | | Adjusted for the stable branch. Signed-off-by: wm4 <wm4@nowhere>
* x11_common: fix behavior if XCreateIC() failsMartin Herkt2013-09-201-5/+11
| | | | | | | | | | | | | | | | | | | | | | | This consists of 3 commits squashed and cherry-picked from master (there were some minor conflicts): vo/x11_common: Fail init with no valid XIM XOpenIM can fail to find a valid input method, in which case it returns NULL. Passing a NULL pointer to XCreateIC would cause a crash, so fail VO init before that happens. vo/x11_common: remove superfluous msg prefixes Conflicts: video/out/x11_common.c vo/x11_common: don't require a working input method Normally, we need this for Xutf8LookupString(). But we can just fall back to XLookupString(). In fact, the code for this was already there, the code was just never tested and was actually crashing when active (see commit 2115c4a).
* wayland/common: exit properly on fd errorsAlexander Preisinger2013-09-201-2/+6
| | | | | | | Before this commit there was just an error message, but the file descriptor was still open. Now we close the file descriptor and prevent it from calling endlessly. Also a CLOSE_WIN event is sent which closes the window eventually if the action of CLOSE_WIN is set to quit or quit_watch_later.
* af_export: fix compilation warningwm42013-09-201-2/+1
| | | | Blargh.
* Config path functions can return NULLwm42013-09-202-3/+11
| | | | | | | It's quite unlikely, but functions like mp_find_user_config_file() can return NULL, e.g. if $HOME is unset. Fix all the code that didn't check for this correctly yet.
* path: fix undefined behaviorwm42013-09-201-2/+2
| | | | | | | The homepath variable was static, and its value was set to a stack buffer. This means a second invocation of the function would trigger undefined behavior. Moreover the stack buffer always went out of scope before homepath was used.
* mplayer: read subtitle packets as soon as possiblewm42013-09-201-8/+5
| | | | | | | | | | | | | Call update_subtitles() on every iteration of the playloop, so that subtitle packets are read as soon as possible, instead of every time a video frame is displayed. This helps in case the packet queue is swamped with subtitle packets, which can happen with certain insane mkv files. The change will simply cause the subtitle queue to be emptied on each playloop iteration. The timestamps update_subtitles() uses for display are the same before and after this commit. (Important for files which have subtitle packets with timestamps or duration not set.)
* demux_mkv: don't add too many subtitle packets during seekingwm42013-09-201-14/+19
| | | | | | | | | | | | | | | | | | | | | In insane files with a very huge number of subtitle events, and if the --demuxer-mkv-subtitle-preroll option is given, seeking can still overflow the packet queue. Normally, the subtitle_preroll variable specifies the maximum number of packets that can be added. But once this number is reached, the normal seeking behavior is enabled, which will add all subtitle packets with the right timestamps to the packet queue. At this point the next video keyframe can still be quite far away, with enough subtitle packets on the way to overflow the packet queue. Fix this by always setting an upper limit of subtitle packets read during seeking. This should provide additional robustness even if the preroll option is not used. This means that even with normal seeking, at most 500 subtitle packets are demuxed. Packets after that are discarded. One slightly questionable aspect of this commit is that subtitle_preroll is never reset in audio-only mode, but that is probably ok.
* manpage: remove bogus space in example usagewm42013-09-201-1/+1
|
* manpage: remove version and date fieldswm42013-09-201-2/+0
| | | | | | | | These would have to be updated manually all the time. Replacing them automatically would be possible, but additional work, and would force regeneration of the manpage way too often. We decided that we don't need these fields.
* stream_dvd: prevent segmentation fault with some broken filesStefano Pigozzi2013-09-201-2/+2
| | | | | | | I have a sample where some final chapters are missing. This was causing a segmentation fault when trying to fetch chapter times for them. This makes the code ignore those chapters.
* macosx: add webm the filetypes handled by the bundleBilal Syed Hussain2013-09-201-0/+2
|
* README: add clarification about --enableStefano Pigozzi2013-09-201-3/+7
|
* README: update Contact info with Mailing ListsStefano Pigozzi2013-09-201-3/+15
|
* mplayer: print a message when writing watch_later config for resumewm42013-09-201-0/+2
| | | | | Putting this into stable, because it might help debugging certain issues, and also making the user aware what's happening.
* Release 0.1.6wm42013-09-131-1/+1
|
* vd_lavc: reset last_sample_aspect_ratio in uninit_avctx()xylosper2013-09-131-0/+1
| | | | | | | | In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set, sh->aspect is overwritten. With software decoding fallback behaviour, this makes the aspect ratio from container ignored since last_sample_aspect_ratio is already set in first try with hardware decoding.
* macosx_application: fix file opening on 10.9 (for real this time)Stefano Pigozzi2013-09-131-1/+1
| | | | | | | | I did commit 86c05655d by thinking `mpv` already removed the `mpv` from argc/argv. It actually is still there, so the argc must be 1 to check for no arguments. Thanks to @Nyx0uf for pointing out the bug and for testing on 10.9!
* macosx: always active bundle path lookup if cocoa is activeStefano Pigozzi2013-09-133-21/+3
| | | | | This is not really something you want to disable anyway. If there is no bundle the code already does it's falbacks anyway.
* macosx_application: fix file opening on OS X 10.9 (hopefully)Stefano Pigozzi2013-09-131-1/+10
| | | | | | | | File opening through Finder, apparently drops `--psn` arguments on Mavericks and just uses no args. Modify the code to account for that case. This wasn't tested on 10.9 itself (I don't have a paid dev account), but it *should* work if I understood the problem correctly.
* mpvcore/path: Fix non-MinGW buildsMartin Herkt2013-09-131-2/+5
| | | | Well that was dumb.
* mpvcore/path: Fix config path handling on WindowsMartin Herkt2013-09-131-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | Previously, mpv incorrectly used the %HOME% environment variable on MinGW to determine the current user’s home directory. This is wrong; the correct variable to use would be %HOMEPATH%, which would however still be wrong since application data goes into the application data directory, not the user’s home. This patch makes it use the local AppData path instead of reading an environment variable. This however exposed another problem (which also affected users who actually had the %HOME% variable set): b2c2fe7a3782 (discussed in issue #95) introduced some changes that make mpv load user config files from the executable path on Windows. The problem with this change is that config_dir was still declared static, so once a config file had been found in the executable path, it would set config_dir to an empty string, so mpv would dump e.g. watch_later data straight into the user’s home. This commit also fixes that. One side effect of this is that mpv no longer considers the “mpv” subdirectory in the executable path (that behavior resulted from the homedir variable always being empty), unless it is somehow unable to determine the local AppData path.
* Makefile: update DIRS to fix cleaningStefano Pigozzi2013-09-131-1/+2
| | | | Commits 40624100 and 72f2942df didn't update the variable accordingly.
* wayland/common: improved error messagesAlexander Preisinger2013-09-101-3/+5
| | | | | | | | The previous error message were not very usefull. Also include a hint where to look for solutions. Conflicts: video/out/wayland_common.c
* stream: force demuxer of cached stream, fixes cdda:// + cachewm42013-09-101-0/+1
|
* manpage: various improvementswm42013-09-106-98/+77
| | | | | | Took a superficial look at the manpage, and fixed whatever I spotted. Cherry picked from master, but required adjustments.
* Manpage: Fix formatting (mostly for PDF output)Martin Herkt2013-09-104-13/+19
|
* demux_mkv: don't overflow packet queue when doing sub-prerollwm42013-09-081-4/+13
| | | | | | | | | | | | | | Consider the cluster used for prerolling contains an insane amount of subtitle packets. Then the demuxer packet queue would be full of subtitle packets, and demux.c would refuse to read any further packets - including video and audio packets, resulting in EOF. Since everything involving Matroska and subtitles is 100% insane, this can actually happen. Fix this by putting a limit on the number of subtitle packets read by preroll, and throw away any further packets if the limit is exceeded. If this happens, the preroll mechanism will stop working, but the player's operation is unaffected otherwise.
* Release 0.1.5v0.1.5wm42013-09-071-1/+1
|
* options: fix --volume option range, add some explanations to manpagewm42013-09-072-1/+7
| | | | | | | | The --volume option accepted values up to 10000, but internally, the value is always clipped to 0-100 range. What makes this even worse is that --softvol-max suggests that it extends the range of --volume, which is not the case. (And passing a volume larger than 100 to --volume didn't even print a warning.)
* demux_lavf: workaround for broken libavformat subtitle seekingwm42013-09-071-4/+23
| | | | | | | | | | | | | | The really funny thing about this commit is that this code is added on top of another work around. Basically, subtitle seeking in libavformat is completely broken. To make it useful, we have to add yet another workaround. The basic problem is that libavformat's subtitle seeking code always uses the stream time base, instead of AV_TIME_BASE if stream index -1 is passed to the avformat_seek_file() function. Fixes github issue #216. Hopefully this will be fixed in ffmpeg too at some point.
* mplayer: try to resume playback only if a resume file actually existswm42013-09-071-1/+1
| | | | | Well, this was dumb. The resume message was printed for every file, whether a resume config file existed or not.
* audio: fix playback of Musepack SV8 fileswm42013-09-041-2/+4
| | | | | | | | | | | | | | This is basically a libavcodec API oddity: it can happen that avcodec_decode_audio4() returns 0 (meaning 0 bytes were consumed). It requires you to feed the complete packet again to decode the full packet, and to successfully decode the following packets. We ignored this case with the argument that there's the danger of an endless decode loop (because nothing of that packet is apparently decoded, so it would retry forever), but change it in order to decode mpc8 files correctly. Also add some comments to explain the mess.
* tv: attempt to support mjpeg streamswm42013-09-041-2/+6
| | | | | | | | | | MPlayer handles this correctly, because MPlayer still has the FourCC codec dispatch (codecs.conf). We need to handle this case specially, because the libavformat rawvideo decoder will of course not eat mjpeg. mjpeg is the only supported format, though. (Even MPlayer needs to convert between V4L2 formats and MPlayer FourCCs, and mjpeg is the only non-raw format.)
* mplayer: handle --reset-on-next-file=""wm42013-09-041-4/+6
| | | | | | | The option list contains an empty string member with this option value, so ignore that. I'm not sure whether the option list should maybe be empty in this case, but it could be the wrong thing in case of other options.
* mplayer: don't let playback resume force options that are file localwm42013-09-041-11/+11
| | | | | | | | This happens by default with pausing: if a file was paused when doing quit_watch_later, then resume and unpause, then the file played after that would start in paused mode. This is because the pause option is backed up at thr wrong place, so it backs up the state from resuming, instead of whatever it was set to before that.
* configure: fix some descriptions in the help outputwm42013-09-041-4/+4
|
* Release 0.1.4v0.1.4wm42013-08-291-1/+1
|
* input: fix --no-input-default-bindingswm42013-08-291-0/+2
| | | | The option did nothing. This was probably broken with 5b38a52.
* gl_video: don't crash if no FBOs are availablewm42013-08-291-4/+6
| | | | | | | | This probably has been broken since bbc865a: a test was added that uses a FBO, but it's always run, even if FBOs were not detected. On the other hand, fbotex_init() just runs into an assert. Fix the test that triggered this condition, and make fbotex_init() "nicer" by just failing if FBOs are not available.
* cocoa_common: autohide dock when autohiding menubarStefano Pigozzi2013-08-291-1/+5
| | | | A cocoa bug doesn't allow to do otherwise. Will open a radar later.
* gl_video: fix odd video sizes with PBOswm42013-08-291-0/+4
| | | | | | | | | Odd video sizes if pixel formats with chroma subsampling and PBOs were used, garbage was rendered. This was because the PBO path created buffers with an unpadded size, and then tried to upload a padded image to it. Fix it by explicitly setting the padded size. (As with the non-PBO path, we rely that image allocations are somehow padded, which is normally the case.)
* configure: fix help for macosx-bundle from autodetected to disabledStefano Pigozzi2013-08-291-5/+4
| | | | | The help and configure result wrongly showed this feature was autodetected, while it is infact disabled by default.
* Release 0.1.3v0.1.3wm42013-08-231-1/+1
|
* cocoa_common: avoid locking calls when not neededStefano Pigozzi2013-08-231-2/+2
| | | | | | | | | | cocoa_common contains some locking calls to support video outputs that support live resizing (at this moment only vo=opengl). These should not be used unless the VO declares it is multithreaded by registering the resize_redraw callback used for live resizing. Fixes #200
* demux: check whether stream is selected in demux_get_next_pts()wm42013-08-221-1/+1
| | | | | | | | Otherwise, this would just try to demux a good chunk of the file, even though the operation can't succeed anyway. This caused some pretty strange issues, where perfectly valid use cases would print a "Too many packets in the demuxer packet queue..." message.
* demux_raw: read multiple frames per packetwm42013-08-221-1/+4
| | | | | | | | | | The rawaudio demuxer read one frame per packet, basically a few bytes, which caused insane overhead. (I found this when I couldn't play raw audio without dropouts when using -v, which printed a line per packet read.) Fix this and read 1 second of audio per packet. This is a regression since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
* cocoa_common: fix window positioning with `--geometry`Stefano Pigozzi2013-08-221-10/+5
| | | | | | | | | | | Regression since ff3b98d11c. The window positioning code relied on the visibleFrame's height without taking into account the dock's presence. Also moved the constraining code to the proper method that overrides the original NSWindow behaviour. This avoids having to check for border since the constraining is performed by Cocoa only for titled windows. Fixes #190
* manpage: fix (again) incorrect ao_alsa exampleCheng Sun2013-08-221-1/+1
| | | | One example in ao.rst used the old syntax with misspelling of "no-block".
* vf_eq: fix behavior when changing parameterswm42013-08-221-4/+14
| | | | | | | | | | | | | | | Using -vf eq and changing brightness, contrast, etc. using key bindings with e.g. "add brightness 1" didn't work well: with step width 1, the property gets easily "stuck". This is a rounding problem: e.g. setting gamma to 3 would actually make it report that gamma is set to 2, so the "add" command will obviously never reach 3 with a step width of 1. Fix this by storing the parameters as integers. This was broken in cac7702. This commit effectively changed these properties to use the value as reported by vf_eq, instead of the previously set value for the "add" command. This was more robust, but not very correct either, so we keep the new behavior and make vf_eq report its parameters more accurately.
* m_option: make "add speed 0.1" command workwm42013-08-191-0/+1
| | | | Was broken since the speed property was switched from float to double.
* Release 0.1.2v0.1.2wm42013-08-191-1/+1
|
* vdpau: don't try to match codec profileswm42013-08-191-23/+8
| | | | | | | | | | | | | | | | | | | Instead, do what MPlayer did all these years. It worked for them, so there's probably no reason to change this. Apparently fixes playback with some files, where the VDPAU decoder does not formally support a profile, but decoding works with a more powerful profile anyway. Though note that MPlayer did this because it couldn't do it in a better way (no decoder reported profiles available when creating the VDPAU decoder), so it's not entirely clear whether this is a good idea. An alterbative implementation might try to map the profiles exactly, and do some fall backs if the exact profile is not available. But this hack-solution works too. Conflicts: video/decode/vdpau.c
* changes: add some things for completenesswm42013-08-191-3/+30
|
* vo_vdpau: fix screenshots if panscan is usedwm42013-08-181-4/+5
| | | | | | | When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
* mplayer: don't make restored options from quit_watch_later per-file localwm42013-08-181-6/+8
| | | | | | | | | | | | | | | Consider: mpv file1.mkv file2.mkv and file1.mkv is restored from an earlier session when quit_watch_later was used. Then all restored options were reset when file2.mkv is played, even if the user changed them during playback. This affects for example the fullscreen setting. Make it so that after finishing a resumed file, the previously restored settings are not reset again. (Which means only resuming will forcefully overwrite the settings.)
* manpage: fix incorrect ao_alsa example, extend changes.rstwm42013-08-152-2/+7
| | | | | | | One example in ao.rst used the old syntax with mangled device names. Fix it. Mention some shell related caveats. Explicitly mention the change of device name syntax in changes.rst, because it seems to be a common issue.
* vdpau: fix compilation on Libavwm42013-08-151-0/+1
| | | | | | Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without forward-declaring them and without including the headers declaring them. FFmpeg's header for this is fine.
* sub: fix accidental subtitle overlapswm42013-08-151-1/+6
| | | | | | | | | | | | | | | | | | The fix_overlaps_and_gaps() function in dec_sub.c fixes small gaps or overlaps between subtitle events. However, sometimes it could happen that the corrected subtitle events could overlap by 1ms due to bad rounding, making libass shift subtitles to reduce collisions. (The second subtitle will be shown above the previous one, even if both subtitles are visible only for 1ms.) sd_ass.c rounds the timestamps when converting to integers for unknown reasons. I think it would work fine without that rounding, but since I have no clue why it rounds, and since it could be needed to ensure correct timestamps with ASS subtitles demuxed from Matroska, I'd rather not touch it. So the solution is to use already rounded timestamps to calculate the new subtitle duration in fix_overlaps_and_gaps(). See github issue #182.
* x11: fix --ontopwm42013-08-151-3/+3
| | | | Apply it after mapping.
* changes.rst: document some