summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* audio: replace af_fmt2str_short -> af_fmt_to_strwm42013-11-0714-37/+24
| | | | Also, remove all af_fmt2str usages.
* audio/format: reformatwm42013-11-072-58/+56
|
* encoding-example-profiles: support setsar in FFmpeg-gitRudolf Polzer2013-11-071-13/+19
|
* sd_lavc, sd_spu: make dvdsub stretching conditional on --stretch-dvd-subs.Rudolf Polzer2013-11-077-8/+55
| | | | | | | | | | | | We found that the stretching - although it usually improves the looks of the fonts - is incorrect. On DVD, subtitles can cover the full area of the picture, and they have the same pixel aspect as the movie itself. Too bad many commercially released DVDs use bitmap fonts made with the wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make these more pretty then.
* sd_ass, sd_lavc: use the input video's pixel aspect for scaling subtitles.Rudolf Polzer2013-11-072-4/+25
| | | | | | | The previous code used the output video's pixel aspect for stretching purposes, breaking rendering with e.g. -vf scale in the chain. Now subtitles are stretched using the input video's pixel aspect only, matching the intentions of the original subtitle author.
* ao_oss: fix previous ao_oss commitwm42013-11-061-1/+0
| | | | | Basically I introduced an inverted condition, and the line removed was inactive before commit ce72aaa.
* travis: use clang for ffmpeg/libav compilationStefano Pigozzi2013-11-061-1/+1
| | | | | | | | I overlooked the fact that the ffmpeg/libav build system only supports `--cc` and completly ignores $CC. Hopefully this makes the build times a little faster. Fixes #332
* ao_oss: hide warningwm42013-11-061-2/+2
|
* ao_oss: don't enable -softvol by default on OSSv4bugmen0t2013-11-061-0/+4
|
* ao_oss: make no_persistent_volume volume work when seekingbugmen0t2013-11-061-0/+4
|
* osdep: handle SIGTERMwm42013-11-061-0/+2
| | | | | | There's no reason why we should e.g. handle SIGQUIT, but not SIGTERM. Note that sending SIGTERM twice still kills the player.
* input.conf: clarify the magic how default key bindings are addedwm42013-11-061-3/+7
| | | | This is a confusing mechanism, so the explanation should bit more clear.
* memcpy_pic: reformatwm42013-11-061-27/+17
| | | | | Besides cosmetic changes, also change memcpy_pic return type and remove config.h include.
* vd_lavc: remove explicit crystalhd supportwm42013-11-063-16/+0
| | | | | | | | | | | | | | | | This removes "--hwdec=crystalhd". I doubt anyone even tried to use this. But even if someone wants to use it, the decoders can still be explicitly invoked with e.g.: --vd=lavc:h264_crystalhd The only advantage our special code provided was fallback to software decoding. (But I'm not sure how the ffmpeg crystalhd pseudo-decoder actually behaves.) Removing this will allow some simplifications as soon as we don't need vdpau_old.c anymore.
* input: remove unused key_down_event commandwm42013-11-063-6/+0
| | | | | There's no real use-case for this, and is wasn't documented (didn't even appear on the "undocumented commands" list).
* input: disallow autorepeat by default for most commandswm42013-11-062-13/+25
| | | | | | | | | | This drops autorepeated key events for a number of commands. This should help with slow situations accidentally triggering too many repeats. (I'm not sure if this actually happened to users - maybe.) It's not clear whether MP_CMD_COMMAND_LIST (multiple commands on one binding separated by ';') should be repeated, or whether it should try to do something clever. For now, disallow autorepeat with it.
* gl_header_fixes: fix inverted conditionwm42013-11-051-1/+1
| | | | | Could possibly leading to failing compilation on systems with headers that miss the vdpau extension.
* vo_opengl: support for vdpau hardware decodingwm42013-11-058-1/+308
| | | | | | | | | | | | This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
* vdpau: move device and video surface management from vo_vdpau.c to vdpau.cwm42013-11-053-220/+271
| | | | | The goal is being able to use vdpau decoding independently from vo_vdpau.c.
* vo_opengl: redo aspects of initialization, change hwdec APIwm42013-11-053-38/+38
| | | | | | | | | | | Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
* vo_opengl/vaapi: use IMGFMT_RGB0wm42013-11-051-1/+1
| | | | | More correct, might make things slightly faster (probably insignificant).
* video: make IMGFMT_RGB0 etc. exist even if libavutil doesn't support itwm42013-11-053-27/+36
| | | | | | | | These formats are helpful for distinguishing surfaces with and without alpha. Unfortunately, Libav and older version of FFmpeg don't support them, so code will break. Fix this by treating these formats specially on the mpv side, mapping them to RGBA on Libav, and unseting the alpha bit in the mp_imgfmt_desc struct.
* manpage: fix incorrect default for --oscwm42013-11-051-1/+1
|
* vo_xv: fix compilation of SHM not availablewm42013-11-051-1/+1
|
* travis: update ffmpeg stable to 1.2.4 tarballStefano Pigozzi2013-11-051-1/+1
| | | | This is the last release in the 1.2.4 line.
* travis: Update libav stable tarballTimothy Gu2013-11-051-1/+1
| | | | Signed-off-by: Timothy Gu <timothygu99@gmail.com>
* playlist: rewrite PLS parserwm42013-11-042-140/+22
| | | | | | | | | | | | Somehow the new parser ends up much smaller. Much of it is because we don't parse some additional information. We just skip it, instead of parsing it and then throwing it away. More importantly, we use the physical order of entries, instead of trying to sort them by entry number. Each "File" entry is followed by a number that is supposed to be the entry number, and "File1" is first. (Should it turn out that this is really needed, an additional field should be added to playlist_entry, and then qsort().)
* demux_mkv: fix compiler warningswm42013-11-042-3/+3
| | | | | | | | | | | | | | | | Make TOOLS/matroska.pl output structs with fields sorted by name in ebml_types.h to make the order of fields deterministic. Fix warnings in demux_mkv.c caused by the first struct fields switching between scalar and struct types due to non-deterministic ebml_types.h field order. Since it's deterministic now, this shouldn't change anymore. The warnings produced by the compilers are bogus, but we want to silence them anyway, since this could make developers overlook legitimate warnings. What commits 7b52ba8, 6dd97cc, 4aae1ff were supposed to fix. An earlier attempt sorted fields in the generated C source file, not the header file. Hopefully this is the last commit concerning this issue...
* Adjust wayland definesPaweł Forysiuk2013-11-042-3/+3
|
* vdpau: drop required/deprecated access to a libavcodec struct fieldwm42013-11-041-3/+0
| | | | | | | | | | | Before the bitstream_buffers field was deprecated, you had to free it, otherwise you would leak memory. (Although vdpau.c uses a new API, they managed to introduce a new deprecation this quickly. This is a complaint.) This introduces a memory leak of 12 bytes per file on every file on some _older_ libavcodec versions. This is minor enough that I don't care.
* stream_lavf: don't duplicate list of rtmp protocolswm42013-11-041-6/+4
| | | | Assume a rtmp prefix means rtmp instead.
* stream_lavf: support more libavformat protocolswm42013-11-041-1/+3
|
* vo_opengl: cosmetics/fix typoswm42013-11-042-2/+2
|
* vo_opengl: reserve 4 texture units for video instead of 3wm42013-11-041-5/+5
| | | | | | | | | | Video has up to 4 textures, if you include obscure formats with alpha. This means alpha formats could always overwrite the first scaler texture, leading to corrupted video display. This problem was recently brought to light, when commit 571e697 started to explicitly unbind all 4 video textures, which broke rendering for non-alpha formats as well. Fix this by reserving the correct number of texture units.
* osx: fix -Wshadow warnings on platform specific codeStefano Pigozzi2013-11-042-7/+7
|
* Merge remote-tracking branch 'origin/have_configure'Stefano Pigozzi2013-11-0452-503/+534
|\
| * fix HAVE_PTHREADS being undefined on windowswm42013-11-041-0/+1
| |
| * fix HAVE_JACK being undefinedwm42013-11-041-0/+1
| | | | | | | | Holy inconsistency, let's just kill it with waf.
| * define HAVE_COREAUDIO on platforms other than OSXwm42013-11-041-0/+1
| |
| * fix weird DPMS->EXT replacementwm42013-11-041-3/+3
| |
| * Merge branch 'master' into have_configurewm42013-11-0428-94/+478
| |\ | | | | | | | | | | | | Conflicts: configure
| * | configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-0352-500/+528
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* | | vo_opengl: fix use of uninitialized memorywm42013-11-041-1/+1
| |/ |/| | | | | | | Pretty bad, although it should actually not cause any misbehavior. Comes from the hardware decoding interop commit.
* | Fix -Wshadow warning about seek function in playloop.cPaweł Forysiuk2013-11-041-11/+11
| | | | | | | | | | | | | | | | | | | | | | mpvcore/player/playloop.c: In function 'seek': mpvcore/player/playloop.c:209:54: warning: declaration of 'seek' shadows a global declaration [-Wshadow] mpvcore/player/playloop.c:209:12: warning: shadowed declaration is here [-Wshadow] mpvcore/player/playloop.c: In function 'queue_seek': mpvcore/player/playloop.c:360:25: warning: declaration of 'seek' shadows a global declaration [-Wshadow] mpvcore/player/playloop.c:209:12: warning: shadowed declaration is here [-Wshadow] Signed-off-by: wm4 <wm4@nowhere>
* | vo_opengl: add support for VA-API OpenGL interopwm42013-11-047-2/+160
| | | | | | | | | | | | | | | | VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower.
* | vo_opengl: add infrastructure for hardware decoding OpenGL interopwm42013-11-049-32/+229
| | | | | | | | | | | | | | | | | | | | | | | | Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
* | mp_image: add helper for copying image attributeswm42013-11-032-0/+25
| | | | | | | | | | This enw function is similar to mp_image_set_params(), but doesn't force setting "hard" parameters like image size and format.
* | tools: add --no-cache --no-config to mpv_identify.shChrisK22013-11-031-1/+1
| |
* | player: fix quvi 0.9 playlist loadingwm42013-11-031-2/+3
| | | | | | | | The code made no sense at all.
* | demux: make determining seek capability genericwm42013-11-037-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having each demuxer do it (only demux_mkv actually did...), let generic code determine whether the file is seekable. This requires adding exceptions to demuxers where the stream is not seekable, but the demuxer is. Sort-of try to improve handling of unseekable files in the player. Exit early if the file is determined to be unseekable, instead of resetting all decoders and then performing a pointless seek. Add an exception to allow seeking if the file is not seekable, but the stream cache is enabled. Print a warning in this case, because seeking outside the cache (which we can't prevent since the demuxer is not aware of this problem) still messes everything up.
* | demux: remove movi_start/movi_end fieldswm42013-11-037-28/+13
| | | | | | | | | | | | | | Pointless, using stream->start_pos/end_pos instead. demux_mf was the only place where this was used specially, but we can rely on timestamps instead for this case.
* | stream: more consistent checks for whether stream is seekablewm42013-11-031-6/+10
| | | | | | | | | | | | | | | | | | Never check s->seek (except in init), because it'd have to check s->flags anyway. Also, for fast skippable streams (like pipes), don't set the bit that indicates support for seek forward. Make sure s->end_pos is always 0 for unseekable streams. Lots of code outside of stream.c uses this to check seeking support.
* | stream: reconnecting doesn't make sense if stream is not seekablewm42013-11-031-0/+2
|/ | | | | | | This stops mpv from being stuck in reconnecting at the end of the file with some unseekable streams. Test URL: http://playerservices.streamtheworld.com/pls/CBC_R1_VCR_H.pls
* w32: implement functionality required for window-scalewm42013-11-021-0/+23
| | | | Same semantics with respect to fullscreen as x11.
* x11: make window-scale use windowed size in fullscreen modewm42013-11-021-2/+2
| | | | | | This is a bit more intuitive, since before, the window size was just set to something random when setting the window-scale property during fullscreen.
* ta: re-add MinGW cargo cultingwm42013-11-021-0/+6
| | | | | | | | Not really cargo cult, but an unexplainable, needless difference that just exists to annoy us. Fixes that gcc on MinGW treats format specifiers in MSVC mode. Just why? Why?
* demux: rename Windows symbolswm42013-11-026-134/+110
| | | | | | | | | | | | | | | | | | | | There are some Microsoft Windows symbols which are traditionally used by the mplayer core, because it used to be convenient (avi was the big format, using binary windows decoders made sense...). So these symbols have the exact same definition as the Windows one, and if mplayer is compiled on Windows, the symbols from windows.h are used. This broke recently just because some files were shuffled around, and the symbols defined in ms_hdr.h collided with windows.h ones. Since we don't have windows binary decoders anymore, there's not the slightest reason our symbols should have the same names. Rename them to reduce the risk for collision, and to fix the recent regression. Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines its own version if the windows headers don't define it, and ao_wasapi is not available on systems where this symbol is missing. Also reindent ms_hdr.h.
* demux_mkv: fix warningwm42013-11-021-1/+1
| | | | | | | | Now that matroska.pl generates struct fields in deterministic order, this should be the last time I change this. (gcc and clang shouldn't warn about this line of code, but since they do, we want to workaround and silence the warning anyway.)
* matroska.pl: Sort the generated struct field listDiogo Franco (Kovensky)2013-11-021-2/+2
| | | | | | | Newer versions of perl randomize the hash used for hashes every time it's run; this makes the order of the fields be non-deterministic. Tack a sort there to make it deterministic. Needed to fix (or allow fixing) a buggy gcc warning.
* Fix some more -Wshadow warningswm42013-11-0110-36/+36
| | | | | | These aren't printed with newer gcc or clang versions for some reason. All of them seem to be about local variables shadowing global functions.
* tl_matroska: initialize segment related arrays with 0wm42013-11-011-4/+6
| | | | | | | | | | | | | mpv crashed when linked files were not found. The reason was that the chapters array contained some uninitialized data. I have no idea how this code works (after the merge). The old code actually seems to remove missing chapters, while the new code just leaves them unintiialized. Work around the crash by initializing the chapters array (and a bunch of other things) with 0, which means the missing chapter will be located at 00:00:00 and have no name. There is a regression since commit af0306d.
* video: check profiles with hardware decodingwm42013-11-018-72/+142
| | | | | | | | | | | | | | | We had some code for checking profiles earlier, which was removed in commits 2508f38 and adfb71b. These commits mentioned that (working) hw decoding was sometimes prevented due to profile checking, but I can't find the samples anymore that showed this behavior. Also, I changed my opinion, and I think checking the profiles is something that should be done for better fallback to software decoding behavior. The checks roughly follow VLC's vdpau profile checks, although we do not check codec levels. (VLC's profile checks aren't necessarily completely correct, but they're a welcome help anyway.) Add a --vd-lavc-check-hw-profile option, which skips the profile check.
* demux_mkv: use a more universal zero initializerwm42013-11-011-1/+1
| | | | | | | | | | | | Unfortunately, we can't avoid this warning 100%, because e