summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* vaapi: remove unused hw image formats, simplifywm42013-11-297-26/+11
| | | | | | | | | | PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not sure why they were even added, and they sound like they are just for compatibility with XvMC-style decoding, which sucks anyway. Now that there's only a single vaapi format, remove the IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was unused.
* build: make pthreads mandatorywm42013-11-2810-56/+17
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* command: allow "current" as argument to playlist_remove commandwm42013-11-283-3/+10
| | | | Feature request from github issue #376.
* input: use separate type for command definitionswm42013-11-284-54/+79
| | | | | | | | | | | | | Introduce a mp_cmd_def struct to define commands, instead of using mp_cmd for this. This way each command parameter can be a m_option, instead of m_option plus some more stuff. Define the ARG_ macros directly in terms of the OPT_ macros. Not sure if this makes it easier to read (maybe not, even if it looks simpler), but at least it makes it easier to add other option types. Another idea was adding a name for each parameter (so you could have named parameters), but not today.
* player: simple hack to make backstep code somewhat more robustwm42013-11-281-3/+12
| | | | | | | | | | | | | | | | | | | The hr-seek code assumes that when seeking the demuxer, the first image decoded after the seek will have a PTS exactly equal to the demuxer seek target time, or before that target time. Incorrect timestamps, implicitly dropped initial frames, or broken files/demuxers can all break this assumption, and lead to hr-seek missing the seek target. Generally, this is not much a problem (the user won't notice being off by one frame), but it really shows when using the backstep feature. In this case, backstepping would simply hang. Add a simple hack that basically forces a minimal value for the --hr- seek-demuxer-offset option (which is 0 by default) when doing a backstep-seek. The chosen minimum value is arbitrary. There's no perfect value, though in general it should perhaps be slightly longer than the frametime, which the chosen value is more than enough for typical framerates.
* video: add insane hack to work around FFmpeg/Libav insanitywm42013-11-284-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
* video: warn against non-monotonic PTS instead of decreasing PTSwm42013-11-281-2/+2
| | | | And by non-monotonic, we mean "strictly non-monotonic".
* video: add heuristic to prevent framedrop during hrseek if pts brokenwm42013-11-283-1/+13
| | | | | | | | | | | | | | | | | | | | | | | Using --start with files that use DTS only, or which simply have broken PTS timestamps, would incorrectly drop frames and possibly not execute the seek correctly. Add yet another heuristic to detect this. The intent is that --start and hr-seeks in general should work correctly, but in order to keep things fast, we still want to allow frame dropping during hr-seek if there are no problems doing so. Do this by disabling frame dropping by default, but re-enabling it if there are no problems found for a while. As a consequence, --start might be somewhat slower, but normal user interaction should remain as fast as before. Note that there's something subtle about the added code: the has_broken_packet_pts field is checked even before the first packet is fed to dec_video.c, so the field must not be set to 0 right on start. It's not initially set to 0 anyway, because the heuristic requires decoding some images before enabling frame drop anyway. Note 2: it's not clear whether frame dropping during hr-seek really helps; I didn't benchmark it.
* build: make --disable-gl disable all the gl backendsStefano Pigozzi2013-11-283-4/+22
| | | | Fixes #369
* build: add custom -I/-L flags for the BSDs [2]Stefano Pigozzi2013-11-281-4/+4
| | | | Fixup commit. .append() seems to to nothing.
* ao_coreaudio: simplify ch label to speaker id conversionStefano Pigozzi2013-11-271-23/+37
| | | | | | | | Previous code was using the values of the AudioChannelLabel enum directly to create the channel bitmap. While this was quite smart it was pretty unreadable and fragile (what if Apple changes the values of those enums?). Change it to use a 'dumb' conversion table.
* build: add custom -I/-L flags for the BSDsStefano Pigozzi2013-11-271-0/+8
| | | | Apparently this is needed for stuff like iconv.
* old-build: fix iconv check on openbsdStefano Pigozzi2013-11-271-1/+1
|
* af_lavi: actually free the filter graph on uninitwm42013-11-271-5/+1
| | | | | | | This was a memory leak. Also remove the AF_CONTROL_COMMAND_LINE code, which was inactive. (It's never called if the new option parser is used.)
* video: replace d_video->pts field, change PTS jump checkswm42013-11-276-31/+24
| | | | | | | | | | | | | The d_video->pts field was a bit strange. The code overwrote it multiple times (on decoding, on filtering, then once again...), and it wasn't really clear what purpose this field had exactly. Replace it with the mpctx->video_next_pts field, which is relatively unambiguous. Move the decreasing PTS check to dec_video.c. This means it acts on decoder output, not on filter output. (Just like in the previous commit, assume the filter chain is sane.) Drop the jitter vs. reset semantics; the dec_video.c determined PTS never goes backwards, and demuxer timestamps don't "jitter".
* video: if PTS is missing, make something up using the frameratewm42013-11-272-10/+7
| | | | | | Also get rid of the PTS check _after_ filters. This means if there's a video filter which unsets PTS, no warning will be printed. But we assume that all filters are well-behaved enough by now.
* video: refactor PTS code, add fall back heuristic to DTSwm42013-11-275-76/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the PTS handling code to make it cleaner, and to separate the bits that use PTS sorting. Add a heuristic to fall back to DTS if the PTS us non-monotonic. This code is based on what FFmpeg/Libav use for ffplay/avplay and also best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non- monotonic, but DTS is sorted. The code is pretty much the same as in Libav [1]. I'm not sure if all of it is really needed, or if it does more than what the paragraph above mentions. But maybe it's fine to cargo-cult this. This heuristic fixes playback of mpeg4 in ogm, which returns packets with PTS==DTS, even though the PTS timestamps should follow codec reordering. This is probably a libavformat demuxer bug, but good luck trying to fix it. The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit inelegant, but maybe better than trying to mess the PTS back into the decoder callback again. [1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
* Move some code from player to audio/video reset functionswm42013-11-274-13/+13
|
* cosmetics: rename video/audio reset functionswm42013-11-2711-21/+21
| | | | | | | | | | These used the suffix _resync_stream, which is a bit misleading. Nothing gets "resynchronized", they really just reset state. (Some audio decoders actually used to "resync" by reading packets for resuming playback, but that's not the case anymore.) Also move the function in dec_video.c to the top of the file.
* video: remove commented codewm42013-11-271-13/+2
|
* video: use dts as fallback when determining pts by sortingwm42013-11-271-11/+10
| | | | | This makes the new code equivalent with the old one, which often passed dts as pts. Also rename some variables to clear up things.
* ao_coreaudio: map channel labels needed for 8ch layoutsStefano Pigozzi2013-11-271-4/+30
| | | | | | The code stopped at kAudioChannelLabel_TopBackRight and missed mapping for 5 more channel labels. These are in a completely different order that the mpv ones so they must be mapped manually.
* audio: better rejection of invalid formatswm42013-11-274-20/+28
| | | | | | | | | This includes the case when lavc decodes audio with more than 8 channels, which our audio chain currently does not support. the changes in ad_lavc.c are just simplifications. The code tried to avoid overriding global parameters if it found something invalid, but that is not needed anymore.
* video/filter: fix PIC compile on x86Natanael Copa2013-11-262-3/+9
| | | | | | | | | | | | | When using PIC on x86 (eg with hardened toolchains) the ebx register is reserverd and cannot be used in assembly code. For vf_eq we allow the compiler to use memory as input. For vf_noise we temoporarily borrow the ebp register. This fixes #361. Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
* video: unbreak --no-correct-pts with demuxers that use DTSwm42013-11-264-6/+8
|
* demux_mkv: fix realvideo timestamp handlingwm42013-11-261-47/+40
| | | | | | | | | | | | | | | | | | | This was broken by the recent commits. Apparently realvideo timestamps are severely mangled, and Matroska _of course_ doesn't have the sane, umangled timestamps, but something unusable. The existing unmangling code in demux_mkv.c didn't output proper timestamps either. Instead, it was something weird that triggered sorting. Without sorting (it was disabled by default recently), you'd get decreasing PTS warnings In order to fix this, steal some code from libavcodec. Basically copy the contents of rv34_parser.c (with some changes), which makes everything magically work. (Maybe it would be better to use the libavcodec parser API, but I don't want to do that just for this. An alternative idea would be refusing to read files that have realvideo tracks, and delegate this to demux_lavf.c, but maybe that's too redical too.) I wish I hadn't notice this...
* bootstrap.py: reindent to 4 spacesStefano Pigozzi2013-11-261-4/+4
|
* build: remove pointless exception handling in oss checkStefano Pigozzi2013-11-261-9/+5
|
* build: unbreak __get_osslibdir__ on python3Stefano Pigozzi2013-11-261-1/+1
| | | | Fixes #370
* cocoa: unlock on uninitStefano Pigozzi2013-11-261-1/+3
| | | | NSLock should be unlocked before dealloc is called on it.
* build: check for pthreads with and without additional cflagsStefano Pigozzi2013-11-261-1/+5
|
* av_common: fix typo in commentStefano Pigozzi2013-11-261-1/+1
|
* ao_alsa: do not forcibly disable ALSA resamplingMartin Herkt2013-11-261-6/+0
| | | | | | | | Resampling with non-ancient ALSA setups works fine, so there is no need to keep this around. Furthermore, as of writing, the default builtin resampler used by many ALSA setups (taken from libspeex) actually has higher quality than the default resampling modes of avresample and swresample.
* ad_lavc: increase number of packets for initial decodewm42013-11-261-2/+5
| | | | | | | | | | | Apparently just 5 packets is not enough for the initial audio decode (which is needed to find the format). The old code (before the recent refactor) appeared to use 5 packets, but there were apparently other code paths which in the end amounted to more than 5 packets being read. The sample that failed (see github issue #368) needed 9 packets. Fixes #368.
* player: don't use a loop when no loop is neededwm42013-11-261-4/+1
| | | | | This used a really weird idiom: a loop that iterates only once, so you can use break; to jump out of the block.
* player: move code for skipping 0-sized video packets to demuxerwm42013-11-262-10/+9
| | | | | | | | | | These packets have to be explicitly dropped, because usually libavcodec uses 0-sized packets to flush delayed frames, meaning just passing through these packets would have bad consequences. Normally, libavformat doesn't output 0-sized packets anyway. But I don't want to take any chances, so don't delete it, and just move it out of the way to demux.c.
* build: make cygwin use *nix timersStefano Pigozzi2013-11-262-2/+1
|
* build: add -mwin32 on cygwinStefano Pigozzi2013-11-261-0/+4
|
* build: add a gdi check for windowsStefano Pigozzi2013-11-262-2/+7
| | | | | Incidentally this seems wrong in the configure as well because only gl-win32 depends on it instead of also making direct3d depend on this (as I did here).
* sub: respect detected language for fuzzy-matched external subtitleswm42013-11-253-21/+26
| | | | | | | Solve this by passing through the language to the player, which then uses the generic subtitle selection code to make a choice. Fixes #367.
* player: only pause for waiting on cache if it makes sensewm42013-11-251-1/+3
| | | | | | | | | If the value for --cache-on-pause is larger than --cache-min, and the cache runs below --cache-on-pause, but above --cache-min, the logic would demand to pause the player and then unpause immediately again. This doesn't make much sense, and alternating the pause state in each playloop iteration has negative consequences. Add an explicit check to avoid this situation.
* video: move timestamp determination code to dec_videowm42013-11-253-42/+44
| | | | | | | | | | This means the code that tries to figure out the timestamp from demuxer and decoder output is now all in dec_video.c. We set the final timestamp on the returned image (mp_image.pts), as well as the d_video->pts field. The way the player uses d_video->pts field is still a bit messy. Maybe this could be cleaned up later.
* video: disable PTS sorting fallback by defaultwm42013-11-254-6/+13
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* demux_lavf: disable genpts by default, remove the builtin genpts hackwm42013-11-252-94/+13
| | | | | | | | | This was needed to determine PTS from DTS, but the previous commits make it unnecessary. The builtin genpts hack was used for DVD, because libavformat's genpts essentially went amok on DVD timestamp resets. See commit 65d87091 for details.
* demux: export dts from demux_lavf, use it for aviwm42013-11-258-25/+45
| | | | | | | | | Having the DTS directly can be useful for restoring PTS values. The avi file format doesn't actually store PTS values, just DTS. An older hack explicitly exported the DTS as PTS (ignoring the [I assume] genpts generated non-sense PTS), which is not necessary anymore due to this change.
* player: merge no-correct-pts with correct-pts codewm42013-11-254-52/+16
| | | | | | Now the --no-correct-pts mode is like the normal mode, just with different timestamp calculations. The semantics should be about the same as before this commit.
* player: change semantics of --no-correct-ptswm42013-11-252-27/+8
| | | | | | | | | | | | | Before this commit, this mode estimated the frame time by subtracting successive packet PTS values. This is complete non-sense for video codecs which use reordering. The code compensated frame times for these non-sense using the FPS value, but confused the rest of the player with non-sense jumping around timestamps. So, all in all this mode is not very useful. Repurpose this mode for fixed frame rate playback. This gives almost the same behavior as the old mode with forced framerate (--fps option). The result is simpler and often more robust.
* dec_video: fix function signaturewm42013-11-252-4/+6
| | | | Just why...? And why did this take 7 years?
* video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFramewm42013-11-255-30/+30
| | | | | | | | | | | | | | | Instead of passing the PTS as separate field, pass it as part of the usual data structures. Basically, this removes strange artifacts from the API. (It's not finished, though: the final decoded PTS goes through strange paths, and filter_video() finally overwrites the decoded mp_image's pts field with it.) We also stop using libavcodec's reordered_opaque fields, and use AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because these pts fields are not "really" opaque anymore, yet we treat them as such. But the end result should be the same, and reordered_opaque is marked as partially deprecated (it's not clear whether it's really deprecated).
* player: warn if PTS association mode switcheswm42013-11-251-2/+2
| | | | | | | | | | | | | | | | | This normally shouldn't happen. It does happen with VfW-muxed mkv files, and would normally happen with avi files (except that we force the correct association mode using an explicit hack for avi). This is usually prepended by warnings like: Decreasing video pts: 0.125000 < 0.167000 and after the switch, there should be no warnings anymore. Background: avi likes to use DTS for timestamps instead of PTS. Basically, there are no proper timestamps in the file, only frame numbers. And Matroska is insane and stores the made-up DTS instead of a proper PTS. This will be handled properly later.
* build: don't abort if our OSS implementation isn't from 4FrontStefano Pigozzi2013-11-251-3/+3
| | | | | | Original commit was implemented differently by @bugmen0t. The problem here was that the waf API was called directly, instead of using our own check_cc (which defaults, among other things, to non mandatory checks).
* build: run oss_audio.c check with oss cflags as wellStefano Pigozzi2013-11-251-4/+6
|
* build: unbreak __get_osslibdir__()bugmen0t2013-11-251-2/+4
| | | | | | | - without Utils.* always returns empty string - subprocess doesn't need extra quoting for sh -c - "source" is a bash'ism, not in POSIX sh - most shell commands embed newline at the end
* build: only check 4Front OSS after passing its CFLAGSbugmen0t2013-11-251-10/+10
|
* input: discard precise scrolling commands with no valueStefano Pigozzi2013-11-251-0/+2
| | | | | | | | | | | Apparently Cocoa precise scrolling generates a lot of spurious events with a delta that is equal to 0.0. Make sure that they are discarded and not added to the input queue. Even though this only known to happen with Cocoa, I implemented this at core level since it makes sense in general. Fixes: #310
* build: fix construction of args to pkg-configNatanael Copa2013-11-251-2/+8
| | | | | | This makes it work with pkgconf (https://github.com/pkgconf/pkgconf) Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
* build: work around bug in waf's bundle installationStefano Pigozzi2013-11-251-0/+5
| | | | | | waf wrongly installs resources to BundleRoot/Resources instead of BundleRoot/Contents/Resources. Will post a patch to them later. Either way, this must worked around until the next waf patch release.
* build: add install_files call after the mpv target was definedStefano Pigozzi2013-11-241-2/+3
| | | | | This makes it work on cold compiles when there is no `build/` directory and one does ./waf configure && ./waf install (i.e.: no ./waf build).
* bootstrap.py: check version if waf already existseng2013-11-241-7/+9
|
* build: also install mpv CLI binary when building OS X bundleStefano Pigozzi2013-11-241-0/+2
|
* gitignore: add generated file