summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* audio: remove S8, U16, U24, U32 formatswm42015-06-1614-199/+26
| | | | | | | | | | | | | They are useless. Not only are they actually rarely in use; but libavcodec doesn't even output them, as libavcodec has no such sample formats for decoded audio. Even if it should happen that we actually still need them (e.g. if doing direct hardware output), there are better solutions. Swapping the sign is a fast and lossless operation and can be done inplace, so AO actually needing it could do this directly. If you wonder why we keep U8 instead of S8: because libavcodec does it.
* DOCS/compile-windows.md: drop unused dependencywm42015-06-161-1/+1
|
* audio: fix crash on uninitwm42015-06-151-1/+1
| | | | Shit.
* af_lavcac3enc: fix A/V syncwm42015-06-151-3/+17
| | | | | | The filter can buffer singificant amounts of audio. (The proper fix is making the filter chain PTS-aware.)
* af: fix an aspect of filter chain flushingwm42015-06-151-0/+11
| | | | | Even if we flush the current filter, we have to read the remaining output from the frame we previously fed to the filter.
* audio: remove unused readonly fieldwm42015-06-152-3/+1
| | | | Its last use was removed in 433402b5.
* win32: use atomics for COM interface refcountwm42015-06-141-4/+5
|
* demux_mkv: always copy video extradatawm42015-06-131-16/+14
| | | | | | The existing code avoided doing this for some codecs. I see no point in this, and it seems the original reason this exists was due to some cleanup in 2007. libavformat doesn't do this. So just drop it.
* demux_mkv: fix mpeg2 mappingwm42015-06-131-1/+1
| | | | | | | | It's well possible that we've always ended up invoking the AV_CODEC_ID_MPEG1VIDEO codec, but it's hard to tell. Mangling everything through FourCCs (and then back) makes it hard to analyze. Also, libavformat's Matroska demuxer uses AV_CODEC_ID_MPEG2VIDEO here, so it should be quite safe to do anyway.
* demux_mkv: remove FourCCs from video codec handlingwm42015-06-132-39/+27
| | | | | | | | | | | | | | | | | | | Inherited from MPlayer times, we used FourCCs to identify video codecs. This was later changed to libavcodec codec names (which made life a whole lot simpler). But demux_mkv still uses FourCCs a lot. Change this for video. It's pretty simple, because some preparation was done in the past. We just have to replace some "internal" FourCCs with different handling. One potentially complicated issue is that there is no natural way to set the sh->format (AVCodecContext.codec_tag) field anymore. Most decoders do not need it, though mjpeg is an exception. Note that the AVI compatibility code still requires codec mappings, but these are provided by FFmpeg. Also, the audio code is not changed. For the MKV_V_MPEG2 -> mpeg1video thing see next commit.
* demux_mkv: remove a level of indentationwm42015-06-131-53/+52
| | | | | Replace an else block with a nested if with just "else if". No functional or other changes.
* demux_mkv: remove ms_compat codewm42015-06-131-11/+5
| | | | Reduces the mess slightly.
* vo_drm: fixed crashes with --profile=pseudo-guiMarcin Kurczewski2015-06-131-1/+1
|
* test: update cmocka version to 1.0Stefano Pigozzi2015-06-134-25/+25
|
* chmap: make up some channel layout nameswm42015-06-121-0/+3
| | | | | Going by the existing names, these should make sense. HDMI knows about these layouts, but does not name them.
* ao_alsa: if possible, reorder device maps to std layoutswm42015-06-121-0/+2
| | | | | | | Channel maps reported by the device as SND_CHMAP_TYPE_VAR can be freely reordered. We don't use this much (out of laziness), but in this case it's a simple way to reduce necessary reordering (which would be an extra libavresample invocation), and to make debug output more readable.
* ao_alsa: make it accept 7.1 over HDMIwm42015-06-121-0/+2
| | | | | SDR/SDL is what lavc outputs for 7.1(rear), while RRC/RLC is what ALSA uses for some 7.1 layouts, so this makes sense to me.
* chmap_sel: improve speaker replacement handlingwm42015-06-122-17/+48
| | | | | This didn't really work since the last time the channel map fallback code was touched. In some cases, quite bad results were selected.
* chmap_sel: do naive speaker replacements lastwm42015-06-121-3/+4
| | | | | This prevents that the potentially better pick by mp_chmap_sel_fallback() is overridden.
* audio: fill NA channels with silencewm42015-06-121-11/+29
| | | | | | | | | | | | | | | Until now, we didn't do this, because it required some effort, and didn't seem to be necessary. It probably still isn't, but it sounds like a good idea not to output arbitrary data on these channels. The situation is complicated by the fact that just adding new channels to a planar frame would require messing with buffers. So we would have to allocate new buffers and add them to the frame. We could have to maintain an extra buffer pool for this. Avoid this by being "clever", and just allocate a frame with enough channels in the first place. libav/swresample won't know about these channels and won't write to them, but we can grab them in reorder_planes() and use them for the NA channels.
* audio: use unknown channel layouts if there is no standard layoutwm42015-06-121-5/+5
| | | | | | | | | This is just a conceptual issue, since for now every channel count has an associated standard layout. But should the max. channel count ever be bumped, some things would stop function if mp_chmap_from_channels() refused to work for any channel count within the allowed range.
* audio: fix messed up channel reorderingwm42015-06-121-2/+2
| | | | Quite a blunder, really.
* audio: deal with AVFrame-style buffer assignmentswm42015-06-122-4/+17
| | | | | | | | | | | | | | | | In the AVFrame-style system (which we inreasingly map our internal data stuctures on), buffers and plane pointers don't necessarily have a 1:1 correspondence. For example, a single buffer could cover 2 or more planes, all while other planes are covered by a second buffer, and so on. They don't need to be ordered in the same way. Change mp_audio_get_allocated_size() to retrieve the maximum size all planes provide. This also considers the case of planes not pointing to buffer start. Change mp_audio_realloc() to reset all planes, even if corresponding buffers are not reallocated. (The caller has to be careful anyway if it wants to be sure the contents are preserved on realloc calls.)
* lua: support MPV_END_FILE_REASON_REDIRECTwm42015-06-112-0/+11
| | | | And also add the missing "unknown" entry to the manpage.
* client API: add MPV_END_FILE_REASON_REDIRECTwm42015-06-113-3/+17
| | | | | Requested. Minor incompatible behavior change, as it was signalling MPV_END_FILE_REASON_EOF previously.
* client API: leave mpv_event_end_file.error to 0 on no errorwm42015-06-111-2/+2
| | | | | Making sure this is true makes it closer to the libmpv docs, and possibly less confusing in corner cases.
* lua: export end-file event fieldswm42015-06-112-0/+37
|
* ao_alsa: change ALSA braindeath heuristicwm42015-06-111-3/+4
| | | | | | | | | | | | If you try to play surround with dmix, it will advertise surround and lets you set more than 2 channels, but will report a stereo channel map, with the extra channels identified as NA. We could handle this now, but we don't want to (because it's excessively stupid). Do it only if the channel map is not what we requested, instead of just acting if it contains NA entries at all. This avoids that we hurt ourselves in the unlikely but possible case we actually have to use channel maps with NA entries.
* command: add keypress, keydown, and keyup commands.torque2015-06-115-0/+54
| | | | | These commands are used to simulate keypresses using the key names from input.conf.
* player: use 4 as process exit code on user quitswm42015-06-102-1/+2
| | | | | | | | | | | | | So successful playback and user quit can be distinguished, for whatever reason you may want to do this. Normally, the "quit" command can be customized, but this does not work for quit commands sent by the terminal signal handler. One solution would be introducing something like "ON_SIGNAL" (equivalent to "CLOSE_WIN"), but considering there are a bunch of possible signals, I'd rather not get into this. So go with the dumb solution. Probably fixes #2029.
* options: make keyvalue list parsing less strictwm42015-06-101-7/+8
| | | | | Affects for example --script-opts. A bunch of characters are now allowed in them without causing trouble to the user.
* vo_opengl: fix a small memory leak when loading user shaderswm42015-06-091-1/+1
| | | | | When gl_shader_cache was destroyed, existing user shader entries leaked the file path string.
* vo_opengl: fix dangling pointers with vo_cmdlinewm42015-06-091-0/+24
| | | | | | | | | | | | gl_video_set_options() does not acquire ownership of the opts parameter or its contents. In case of vo_cmdline, opts will point to temporary memory. This memory will be free'd at a later point, and p->opts will point to free'd memory on the next reinitialization. The fix is pretty ugly, but it's a quick bug fix. This can probably be removed once VO sub-options are exposed as properties. Fixes #2035.
* audio: add some change notificationswm42015-06-091-0/+4
| | | | | We must be sure that every change comes with a notification. Otherwise, some property changes could possibly be missed.
* ao_coreaudio: change physical stream format synchronouslywm42015-06-092-5/+2
|
* audio/out/pull: avoid dropping some audio when drainingwm42015-06-091-9/+18
| | | | | | | | | | | | If the audio API takes a while for starting the audio callback, the current heuristic can be off. In particular, with very short files, it can happen that the audio callback is not called before playback is stopped, so no audio is output at all. Change draining so that it essentially waits for the ringbuffer to empty. The assumption is that once the audio API has read the data via the callback, it will always output it, even if the audio API is stopped right after the callback has returned.
* audio/out/pull: correctly pad partial frames with silencewm42015-06-091-1/+1
| | | | | | | | If a frame could only be partially filled with real audio data, the silence wasn't written at the correct offset. It could have happened that the remainder of the frame contained garbage. (This didn't happen in the more common case of playing dummy silence.)
* command: fix audio-out-detected-device propertywm42015-06-091-2/+3
| | | | | | | Used a wrong condition, and I suppose it could crash in some situations. Change it to lazily initialize the hotplug stuff, like the audio-device-list property does.
* command: remove unnecessary event IDswm42015-06-092-4/+0
| | | | | These were actually not needed for correct function, since individual property change notifications via mp_notify_property() are used.
* command: make property event mask matching more restrictivewm42015-06-091-1/+2
| | | | | | This was matching e.g. both "foo/bar" and "foobar" against "foo", when only the former should match. This could cause more property notifications than necessary.
* ao_alsa: refine channel count mismatch error messagewm42015-06-091-2/+2
| | | | I suspect we need to hand this more gracefully in some cases.
* vaapi: add missing license headerwm42015-06-081-0/+17
| | | | | | Absence of license header implies LGPL, as mentioned in the "Copyright" file. But vaapi.h contains some code taken from the mplayer-vaapi patch, which was under the typical MPlayer license.
* gl_osd: fix license headerwm42015-06-081-0/+5
| | | | | | | All vo_gl.c related code has been GPL+LGPL dual-licensed. The OSD code is no exception and is also derived from vo_gl.c. Thus it should have the same license (although I think technically speaking sub-licensing it by removing one of the licenses is ok).
* vo: clarify conditionwm42015-06-081-1/+1
| | | | | This is (at least currently) redundant, but makes the code more explicit. (This was discussed on IRC.)
* vo: restore frame-drop logic for high-fps clipsAvi Halachmi (:avih)2015-06-071-0/+22
| | | | | | | | | Commits 92b27be and f4ce99d removed high-fps logic to to a bug. That bug was a missing parenthesis around everything after duration >= 0 && ... at the removed code. This patch restores the removed code, fixes the bug and then refactors the code a bit.
* ytdl_hook: Support 'multi_video' resultsJaime Marquínez Ferrándiz2015-06-071-1/+1
| | | | | They can be handled by the same codes used for playlists, most of them will use an EDL. Fixes #2027.
* Revert "opengl: drop less frames when clip and display have similar fps"wm42015-06-071-9/+1
| | | | | | | This reverts commit f1746741dee6000b7fd139e7a10f72aba0674b3b. Together with the other revert, this fixes #2023 (the reason being broken framedrop handling - it was dropping frames when it shouldn't).
* Revert "vo: improve frame drop logic on high playback rate"wm42015-06-071-11/+3
| | | | This reverts commit ffcad1a72b9a3bf5a7ac5ddcbfa71ec19b6faf9b.
* vo_vdpau: add a NULL check, verify image dimensionswm42015-06-061-1/+2
| | | | | | | | read_output_surface() could fail and return NULL. Also, make sure we don't set the image to a size larger than the allocated size. Normally this shouldn't happen, but in theory it could in corner cases; this is for robustness.
* audio: add --audio-spdif as new method for enabling passthroughwm42015-06-0510-18/+101
| | | | | | | | | | | | | This provides a new method for enabling spdif passthrough. The old method via --ad (--ad=spdif:ac3 etc.) is deprecated. The deprecated method will probably stop working at some point. This also supports PCM fallback. One caveat is that it will lose at least 1 audio packet in doing so. (I don't care enough to prevent this.) (This is named after the old S/PDIF connector, because it uses the same underlying technology as far as the higher level protoco is concerned. Also, the user should be renamed that passthrough is backwards.)
* ad_spdif: use a pseudo codec entry to select DTS-HD instead of an optionwm42015-06-051-1/+10
| | | | | | | | | This deprecates the --ad-spdif-dtshd option, and replaces it with a pseudo decoder. This means ad_spdif will report two decoders, "dts" and "dts-hd", of which the second simply enables what the option did. The --ad-spdif-dtshd option will actually be deprecated in the next commit.
* audio: do not allow AO to change passthrough formatswm42015-06-051-7/+17
| | | | | | | This makes no sense, because the format can't be converted anyway. It just sets up the filter chain init code, which will vomit a bunch of useless and confusing messages. So uninit and fail explicitly when this happens.
* vo_vdpau: limit output surfaces to allowed maximum dimensionswm42015-06-051-4/+12
| | | | | | We can't do much in this case, but at least we can not call the vdpau API functions with too large sizes. Apparently the API considers this undefined behavior, and random stuff might happen.
* vo_vdpau: directly get surface size from surface for screenshotswm42015-06-052-6/+12
| | | | | | | The previous code was not wrong, but I'd claim this makes the code more robust. If a situation could happen in which the passed surface size is incorrect, we could have passed a too small image, and VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
* vo_vdpau: shorten 2 variable nameswm42015-06-051-10/+9
| | | | Why should I be required to type so much?
* video: remove worthless log messagewm42015-06-051-6/+0
| | | | | All this information is already output otherwise. Except the FourCC, which lost most of its importance in mpv.
* vf_sub: minor simplificationwm42015-06-053-7/+3
|
* filter_kernels: distinguish between regular/EWA robidouxNiklas Haas2015-06-051-2/+4
| | | | | This is because it turns out the regular robidoux is pretty useful for tscale etc.
* vo_vdpau: check maximum video sizewm42015-06-042-0/+21
| | | | | | | | | Check the maximum size of video surfaces, and refuse initialization if the video is too large for them. Maybe we could do something more sophisticated, like inserting a software scaler. On the other hand, this would have a very questionable benefit, as it would be guaranteed to be too slow.
* audio: do not exit when loading small files in paused modewm42015-06-041-1/+1
| | | | | | | | When starting in paused mode, no audio is written to the device at all, because writing audio implicitly unpauses the AO. If the file is very small, and all audio fits within the AO buffer, this accidentally triggered the EOF condition. (In unpaused mode, it would write all audio, end playback, and then wait until the AO has everything played.)
* ao_alsa: refuse to use spdif if AES flags can't be setwm42015-06-041-6/+6
| | | | | Seems like a good idea to avoid accidentally playing noise by writing spdif data to pure PCM devices.
* af_lavrresample: slightly better computation of total delaywm42015-06-041-6/+9
| | | | | | | On libavresample, don't ignore the buffered output data. On libswresample, don't round the total buffer size to the input samplerate.
* af_lavrresample: use a new libswresample function if availablewm42015-06-041-0/+4
| | | | | It was recently added to libswresample, and it does exactly what we need.
* af_lavrresample: change output samples calculationwm42015-06-041-2/+2
| | | | | | This is better, because now we call swr_get_delay() with the output samplerate, instead of with the input samplerate and then multiplying it with the ratio and rounding it up.
* ao_alsa: hack against potential spdif failurewm42015-06-041-3/+16
|
* bootstrap.py: make it work on win32wm42015-06-041-1/+1
| | | | | | Apparently, just running ./waf and hoping that it will be run with a Python interpreter doesn't necessarily work. The workaround is pretty simple and reliable.
* inpout.conf: make shift+o toggle between 2 states onlywm42015-06-033-2/+6
| | | | | | | | | | | | | The "osd" command cycles between 4 states (OSD level 0-3), which is probably confusing and inconvenient. OSD levels 0 and 2 are rarely needed. I would claim there is normally not much of a need to completely disable OSD by setting level 0 during playback. Level 2 is just slightly less information than level 3, and I'm not sure why it exists at all. Change it so that it toggles between level 3 and 1. Note that this ignores the default OSD level. If the default is 3, the first use of this key will set it to 3 again. Just assume 1 is the default. If someone complains, this could be improved.
* player: print track list when switching trackswm42015-06-031-0/+4
|
* player: print a message along with track listwm42015-06-033-7/+9
| | | | Slightly less strange.
* player: don't print stream list when adding external tracks during loadwm42015-06-031-5/+7
| | | | | | | | | There's a short time during loading where external commands can add external streams even before the main file is loaded (like during ytdl hook execution). The track list is printed every time an external track is added via commands. This was quite awkward when ytdl was adding multiple streams, so don't print it in this stage. They are printed anyway at the end of the loading pr