summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* TOOLS/zsh.pl: complete --audio-devicePhilip Sequeira2016-04-161-6/+22
|
* vo_opengl: fix an outdated commentwm42016-04-161-3/+1
| | | | This wasn't updated over multiple iterations.
* command: fix cycling certain propertieswm42016-04-151-1/+1
| | | | | | | Commit a9bd4535 generally changed properties are set to string values. This actually broke the fallback for non-string properties, because the set string action was redirected directly to the property, instead of the generic handler and its fallback code.
* vo_lavc: fix build on Libavwm42016-04-151-2/+1
| | | | | OF COURSE Libav doesn't have AV_PICTURE_TYPE_NONE. Why the fuck would it?
* mp_image: make mp_image_copy_fields_* privatewm42016-04-152-8/+4
| | | | | Future code should always use mp_image_{to,from}_av_frame(). Everything else is way too messy and fragile.
* vo_lavc: unsupport deprecated AVFMT_RAWPICTUREwm42016-04-151-23/+12
| | | | | | | | As of ffmpeg git master, only the libavdevice decklink wrapper supports this. Everything else has dropped support. You're now supposed to use AV_CODEC_ID_WRAPPED_AVFRAME, which works a bit differently. Normal AVFrames should still work for these encoders.
* vo_lavc: send refcounted AVFrame to encoderwm42016-04-151-4/+4
| | | | | | This potentially makes it more efficient, and actually makes it simpler. Yes, AV_PICTURE_TYPE_NONE is the default for pict_type.
* mp_image: add mp_image_to_av_frame()wm42016-04-152-6/+10
| | | | | What mp_image_to_av_frame_and_unref() should have been. (The _unref variant is still useful though.)
* mp_image: simplify mp_image_steal_data()wm42016-04-151-17/+7
| | | | Why was this so complex.
* mp_image: pass through AVHWFramesContextwm42016-04-152-4/+22
| | | | In both directions.
* ao_coreaudio_exclusive: list formats when searching substreamwm42016-04-151-0/+3
| | | | Should help debug problems with AC3 passthrough not working.
* ao_coreaudio: remove unused functionwm42016-04-152-25/+0
|
* lcms: include math.hwm42016-04-151-0/+1
| | | | Fixes #3053.
* command: log property set callswm42016-04-152-8/+17
| | | | | | | And remove the same thing from the client API code. The command.c code has to deal with many specialized M_PROPERTY_SET_* actions, and we bother with a subset only.
* command: allow setting panscan etc. properties if no video is activewm42016-04-151-4/+1
| | | | In that case, it merely changes the underlying option value.
* client API: improve mpv_set_property() handling of MPV_FORMAT_NODEwm42016-04-156-48/+63
| | | | | | | | | If a mpv_node wrapped a string, the behavior was different from calling mpv_set_property() with MPV_FORMAT_STRING directly. Change this. The original intention was to be strict about types if MPV_FORMAT_NODE is used. But I think the result was less than ideal, and the same change towards less strict behavior was made to mpv_set_option() ages ago.
* vo_opengl: rpi: don't include x11 header filewm42016-04-151-1/+0
| | | | Copy & paste bug.
* player: fix use-after-free with --screenshot-directorywm42016-04-141-1/+2
| | | | Probably fixes #3049.
* build: add check for AVHWFramesContext APIwm42016-04-141-0/+6
| | | | | It's not used yet anywhere. Pushing this now so switching between branches is less bothersome.
* m_option: slightly improve --msg-level=help outputwm42016-04-131-1/+1
| | | | In particular get rid of the semi-deprecated ":" separator.
* m_option: add string conversion for --audio-channelswm42016-04-131-0/+8
| | | | Requested in #3040.
* vo_opengl: simplify and improve up scale=oversampleNiklas Haas2016-04-121-21/+5
| | | | | | | | | Since what we're doing is a linear blend of the four colors, we can just do it for free by using GPU sampling. This requires significantly fewer texture fetches and calculations to compute the final color, making it much more efficient. The code is also much shorter and simpler.
* demux_mkv: fix seeking with files that miss the first index entrywm42016-04-121-3/+6
| | | | | | | | | Now it will always be able to seek back to the start, even if the index is sparse or misses the first entry. This can be achieved by reusing the logic for incremental index generation (for files with no index), and start time probing (for making sure the first block is always indexed).
* vf_vavpp: reindentwm42016-04-111-8/+6
|
* vaapi: determine surface format in decoder, not in rendererwm42016-04-115-47/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, we have made the assumption that a driver will use only 1 hardware surface format. the format is dictated by the driver (you don't create surfaces with a specific format - you just pass a rt_format and get a surface that will be in a specific driver-chosen format). In particular, the renderer created a dummy surface to probe the format, and hoped the decoder would produce the same format. Due to a driver bug this required a workaround to actually get the same format as the driver did. Change this so that the format is determined in the decoder. The format is then passed down as hw_subfmt, which allows the renderer to configure itself with the correct format. If the hardware surface changes its format midstream, the renderer can be reconfigured using the normal mechanisms. This calls va_surface_init_subformat() each time after the decoder returns a surface. Since libavcodec/AVFrame has no concept of sub- formats, this is unavoidable. It creates and destroys a derived VAImage, but this shouldn't have any bad performance effects (at least I didn't notice any measurable effects). Note that vaDeriveImage() failures are silently ignored as some drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL interop. In addition, we still probe whether we can map an image in the EGL interop code. This is important as it's the only way to determine whether EGL interop is supported at all. With respect to the driver bug mentioned above, it doesn't matter which format the test surface has. In vf_vavpp, also remove the rt_format guessing business. I think the existing logic was a bit meaningless anyway. It's not even a given that vavpp produces the same rt_format for output.
* Revert "build: disable encoding mode by default"Rudolf Polzer2016-04-111-1/+0
| | | | | | Reverting because the use of deprecated API has been fixed. This reverts commit d0238711dc776aeee2509452202ba4748f863ee4.
* encode_lavc: Migrate to codecpar API.Rudolf Polzer2016-04-114-231/+274
|
* aspect: rework --video-unscaledNiklas Haas2016-04-103-29/+18
| | | | | | | | | | | | | | | | | | | In the past, --video-unscaled also disabled zooming and aspect ratio corrections. But this didn't make much sense in terms of being a useful option. The new behavior just sets the initial video size to be unscaled, but it's still affected by zoom commands and aspect ratio corrections. To get the old behavior back, --video-aspect=0 --video-zoom=0 need to be added as well (in the general case). Most of the time it should not make a difference though. Also, there seems to have been some additional dst_rect clamping code inside src_dst_split_scaling that didn't seem to either be necessary nor ever get triggered. (The code immediately above it already makes sure to crop the video if it's larger than the dst_rect) No idea why it was there, but I just removed it.
* aspect: remove useless debug messageswm42016-04-101-10/+2
| | | | Never needed them. This makes the code slightly more readable.
* vo_opengl: improve rotation handling (again)wm42016-04-082-44/+47
| | | | | | | | | | | | | | | | | Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
* TOOLS/zsh.pl: properly escape last changePhilip Sequeira2016-04-081-2/+2
| | | | | | I'm an idiot. Fixes #3032.
* command: add keepaspect propertywm42016-04-081-0/+1
| | | | | | Just a bridge to the option. (Did I ever mention that I hate the property/option separation.)
* osd: add italic font for osdst4t1k2016-04-084-0/+6
|
* TOOLS/zsh.pl: don't complete URLs by defaultPhilip Sequeira2016-04-081-1/+7
| | | | | | | ...unless no files match. Fixes #2892. To get the old behaviour back, use something like: zstyle ':completion:*:*:mpv:*' tag-order
* vo_opengl: log if glGetString(GL_VERSION) returns NULLwm42016-04-081-1/+3
| | | | | | Typically happens with some implementations if no context is currrent, or is otherwise broken. This is particularly relevant to the opengl_cb API, because the API user will have no other indication what went wrong.
* d3d: fix Windows buildwm42016-04-071-2/+2
| | | | | | Commit f009d16f accidentally broke it. Thanks to RiCON for noticing and testing.
* vo_opengl: videotoolbox: use kCVPixelBufferLock_ReadOnly for screenshotswm42016-04-071-7/+8
| | | | Why not.
* videotoolbox: change how videotoolbox format is managedwm42016-04-074-6/+36
| | | | | | | | | | | | | | | | | | | | | | | The underlying intention of this code is to make changing --videotoolbox-format at runtime work. For this reason, the format can't just be statically setup, but must be read from the option at runtime. This means the format is not fixed anymore, and we have to make sure the renderer is property reinitialized if the format changes. There is currently no way to trigger reinit on this level, which is why the mp_image_params.hw_subfmt field was introduced. One sketchy thing remains: normally, the renderer is supposed to be involved with VO format negotiation, which would ensure that the VO can take the format at all. Since the hw_subfmt is not part of this format negotiation, it's implied the get_vt_fmt() callback only returns formats supported by the renderer. This is not necessarily clear because vo_opengl checks this with converted_imgfmt separately. None of this matters in practice though, because we know all formats are always supported. (This still requires somehow triggering decoder reinit to make the change effective.)
* mp_image: introduce a hw_subfmt fieldwm42016-04-072-0/+8
| | | | | | | | | | | For hwaccel formats, mp_image will merely point to a hardware surface handle. In these cases, the mp_image_params.imgfmt field describes the format insufficiently, because it mostly only describes the type of the hardware format, not its underlying format. Introduce hw_subfmt to describe the underlying format. It makes sense to use it with most hwaccels, though for now it will be used with the following commit only.
* vd_lavc: let hardware decoder request delaying frames explicitlywm42016-04-075-4/+9
| | | | | | | | | | Until now, the presence of the process_image() callback was used to set a delay queue with a hardcoded size. Change this to a vd_lavc_hwdec field instead, so the decoder can explicitly set this if it's really needed. Do this so process_image() can be used in the VideoToolbox glue code for something entirely unrelated.
* vd_lavc: fix codec vs. decoder confusionwm42016-04-0710-31/+32
| | | | | | | | | | Some functions which expected a codec name (i.e. the name of the video format itself) were passed a decoder name. Most "native" libavcodec decoders have the same name as the codec, so this was never an issue. This should mean that e.g. using "--vd=lavc:h264_mmal --hwdec=mmal" should now actually enable native surface mode (instead of doing copy- back).
* vo: don't reset vsync statistics on seeks etc.wm42016-04-061-9/+14
| | | | | | | | | | | | | | | | | | The sync-by-display mode relies on using the vsync statistics for timing. As a consequence discontinuities must be handled somehow. Until now we have done this by completely resetting these statistics. This can be somewhat annoying, especially if the GL driver's vsync timing is not ideal. So after e.g. a seek it could take a second until it locked back to the proper values. Change it not to reset all statistics. Some state obviously has to be reset, because it's a discontinuity. To make it worse, the driver's vsync behavior will also change on such discontinuities. To compensate, we discard the timings for the first 2 vsyncs after each discontinuity (via num_successive_vsyncs). This is probably not fully ideal, and num_total_vsync_samples handling in particular becomes a bit questionable.
* sub: interpret "text" subtitles as srtwm42016-04-061-0/+3
| | | | | Most players will interpret HTML-style tags (aka srt) in almost any kind of text subtitles; make mpv do this too.
* vo_opengl: fix build breakagewm42016-04-061-1/+1
|
* vo_opengl: minor simplificationwm42016-04-051-3/+2
| | | | It's the same functionally.
* vo_opengl: fix nnedi + rectangle textureswm42016-04-053-4/+4
| | | | Shader compilation error due to incompatible samplers.
* cache: disable useless "Cache is not responding" warningwm42016-04-031-1/+1
| | | | | | | | | | | | | | | Tuning it in a way to be actually useful is too much effort. As alternative, there's the "buffering" detection, which operates on a much higher level. The only disadvantage is that it's harder to guess for the user whether this is a network problem, or if e.g. libavformat is probing too much data when opening a stream. Maybe the cache-speed property is helpful here. For now, do not remove the associated code, but just silence the warning. Fixes #3019.
* x11: do not set _NET_WM_BYPASS_COMPOSITOR by defaultwm42016-04-032-3/+3
| | | | | | | | | | | It's pretty "unfriendly" and causes too many issues. (Probably. At least they're more obvious to a user than e.g. broken frame timing.) Potentially we could apply heuristics like applying this only on fullscreen, but let's not. It's up to the user to configure this to get best results. Fixes #2997.
* aspect: make video-zoom logarithmicNiklas Haas2016-04-033-7/+7
| | | | | | | | | | | | | The past behavior was a bit weird, especially when zooming out. There was no simple way to zoom in or out in consistent increments using keybindings alone. The new behavior preserves most of the old behavior's semantics but scales out to infinity better. It coincidentally also makes it really easy to get clean power of 2 ratios (e.g. 2x, 4x, 8x and their inverses). Fixes #3004.
* manpage: change underscore to hyphen in input commandKevin Mitchell2016-04-031-1/+1
| | | | fixes #3018
* manpage: fix typoKevin Mitchell2016-04-021-1/+1
|
* manpage: add example for --msg-levelwm42016-04-021-0/+16
| | | | I guess the syntax is not necessarily very obvious.
* build: make DVB test stricterwm42016-04-022-0/+4
| | | | | | | | | | | | | | | | | | | I got a report that the build on a recent aarch64 Linux kernel failed. DVB support was detected, but errored on compilation: In file included from ../stream/stream_dvb.c:57:0: ../stream/dvbin.h:72:5: error: unknown type name 'fe_bandwidth_t' fe_bandwidth_t bw; Make the test stricter, which should take care of this. (I couldn't find out what exactly triggered the failure, nor could I attempt to reproduce it.) The change in stream/dvbin.h is to make sure that this isn't caused by incorrect header inclusion. It now includes the same files as the configure test.
* build: fix AVCodecParameters FFmpeg API check (again)wm42016-04-021-2/+2
| | | | | | | Commit 0d746522 was complete non-sense. The description and the code mention the wrong struct. This time I actually tested it.
* sd_lavc: use decoder-reordered PTS for PGSwm42016-04-021-3/+21
| | | | | | | | | | | | | | | | There is an obscure feature which requires essentially reordering PTS from different packets. Unfortunately, libavcodec introduced a ridiculously shitty API for this, which works very much unlike the audio/video API. Instead of simply passing through the PTS, it wants to fuck with it for no reason, and even worse, fucks with other fields and changes their semantivcs (??????). This affects AVSubtitle.end_display_time. This probably will cause issues for us, and I have no desire to find out whether it will. Since only PGS requires this, and it happens not to use end_display_time, do it for PGS only. Fixes #3016.
* sd_lavc: add a comment about duration==0 handlingwm42016-04-021-1/+3
| | | | | | | | Basically, this information is useless, because some muxers (hurr libavformat) write bogus information anyway. This means if we e.g. see PGS packets in mkv with duration explicitly set to 0, we must not trust that value anyway. (The FFmpeg API problem is leaking into files, how nice.)
* sd_lavc: fix subtitle display with unknown end timestampswm42016-04-021-1/+1
| | | | | This is a theoretical issue, because subtitle end timestamps for all but the current subtitle are always known.
* ao_coreaudio_exclusive: add missing newline to log messagewm42016-04-011-1/+1
|
* gl_lcms: choose BT.1886 gamma per-channelNiklas Haas2016-04-011-24/+35
| | | | | | | | | This makes the black point closer (chromatically) to the white point, by ensuring channels keep their consistent brightness ratios as they go down to zero. I also raised the 3DLUT version as this changes semantics and is a separate commit from the previous one.
* vo_opengl: generate 3DLUT against source and use full BT.1886Niklas Haas2016-04-017-76/+162
| | | | | | | | | | | | | | | | | | | This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
* build: fix AVCodecParameters FFmpeg API checkwm42016-04-011-1/+1
| | | | | | FFmpeg partially merged the API change. It added the AVCodecParameters definition, but not the AVCodecContext.codecpar field. The new code compiles only with the API fully merged, so adjust the check.
* build: disable encoding mode by defaultwm42016-03-311-0/+1
| | | | | | | | | Encoding mode uses deprecated API. See previous commit. Encoding mode will stop working/compiling at some point in the future, so unless someone fixes the encoding code, it will stay disabled by default. (Note that the deprecations are not merged in FFmpeg yet, but they will soon. They've been deprecated in Libav for a while now.)
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-318-7/+49
| | | | | | | | | AVFormatContext.codec is deprecated now, and you're supposed to use AVFormatContext.codecpar instead. Handle this for all of the normal playback code. Encoding mode isn't touched.
* demux_lavf: remove old MicroDVD frame timing guessingwm42016-03-311-6/+1
| | | | | | | | | | This was changed in 2014, so I suppose users will usually have a FFmpeg release which includes the corresponding upstream change. If not, well too bad for those MicroDVD-obsessed users. Also don't try to retrieve the default framerate as exported by the demuxer, and instead hardcode it and trust it won't ever change. this avoids that we have to deal with a larger mess in the codecpar commit.
* demux_lavf: remove some old framerate guessingwm4201