aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* egl_helpers: change minimum framebuffer size to 8 bit per componentGravatar wm42018-04-29
| | | | | | | | | | | | | | | | | | | | | | | | This is for working around bugs in certain Android devices. At least one device fails to sort EGLConfigs by size, so eglChooseConfig() ends up choosing a config with 5/6/5 bits per r/g/b component. The other attributes in the affected EGLConfigs did not look like they should affect the sorting process as specified by the EGL 1.4 standard. The device was reported as: Sony Xperia Z3 Tablet Compact Firmware 6.0.1 build number 23.5.A.1.291 GL_VERSION='OpenGL ES 3.0 V@140.0 AU@ (GIT@I741a3d36ca)' GL_VENDOR='Qualcomm' GL_RENDERER='Adreno (TM) 330' Other Qualcom/Adreno devices have been reported as unaffected by this (including some with same GL_RENDERER string). "Fix" this by always requiring at least 8 bit. This means it would fail on devices which cannot provide this. We're fine with this. mpv-android/mpv-android#112
* encode: do not clear video PTS on VOCTRL_RESETGravatar wm42018-04-29
| | | | | | | | | | | | | | This was supposed to be a replacement for encode_lavc_discontinuity() (so we don't need to store last_video_in_pts in a way which requires synchronization). Unfortunately, VOCTRL_RESET is also called before termination, and even though it shouldn't matter as far as the VO API is concerned, it does. It's because vo_lavc.c buffers a frame to compute the frame duration. Drop this code. The consequence is that it appears to encode 2 frames with the same PTS if multiple files are encoded into one. Before this, it merely dropped a frame (maybe the first of every subsequent file, not sure).
* egl_helpers: log certain EGL attributesGravatar wm42018-04-29
| | | | Might be helpful with broken EGL implementations.
* player: don't wait for last video frame in encode modeGravatar wm42018-04-29
| | | | | This code makes the player wait using real time, which makes sense for normal playback, but not encode mode.
* TOOLS/matroska.py: ignore some unused elementsGravatar wm42018-04-29
| | | | So that demux_mkv doesn't log them as unknown.
* f_decoder_wrapper: fix a typo in log messageGravatar wm42018-04-29
|
* input: raise log level of some noisy messagesGravatar wm42018-04-29
| | | | Same as the commit before this.
* demux_mkv: adjust log verbosity levelsGravatar wm42018-04-29
| | | | | | | | | With -v -v ("debug" level), which is the default for --log-file, this would log every damn Matroska EBML element and some other uninteresting things, which was very noisy. Adjust the log levels to make them less noisy. Also, change some log calls to MP_ERR for things which are actually errors.
* filter: hide warning when disconnecting pins drops framesGravatar wm42018-04-29
| | | | | | | | | | Sometimes this hints that there's a bug, but sometimes it's normal. Since the code for --end/--frames puts frames that should not be shown anymore back into the pin, using those options will show this warning when playback ends. This is a minor annoyance. We could change how it's done (e.g. set an explicit flag somewhere), but that seems bothersome, so just change the message from warning to verbose.
* encode: rewrite half of itGravatar wm42018-04-29
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* vo: add vo_reconfig2()Gravatar wm42018-04-29
| | | | | | 1. I want to get away from mp_image_params (maybe). 2. For encoding mode, it's convenient to get the nominal_fps, which is a mp_image field, and not in mp_image_params.
* encode: get rid of AVDictionary setter helperGravatar wm42018-04-29
| | | | | | | | | | | | Removes a good hunk of weird code. This loses qscale "emulation", some logging, and the fact that duplicate keys for values starting with +/- were added with AV_DICT_APPEND. I don't assign those any importance, even if they are user-visible changes. The new M_OPT_ flag is just so that nothing weird happens for other key-value options, which do not interpret a "help" key specially.
* encode: some more cleanupsGravatar wm42018-04-29
|
* f_output_chain: remove a redundant variableGravatar wm42018-04-29
|
* options: remove broken --video-stereo-mode optionGravatar wm42018-04-29
| | | | | See changelog for minor explanation. Basically, 3D is unused crap and nobody cares.
* video: remove internal stereo_out flagGravatar wm42018-04-29
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* demux_lavf: discard "und" language tagGravatar wm42018-04-29
| | | | | | | | | Going by ISO 639.2, "und" means "Undetermined". Whatever it's supposed to mean, in practice it's user for "unset". We prefer if the language tag remains simply unset in this case. This removes an ugliness with mp4 in partricular, because libavformat will export unset languages as such, which affects most mp4 files.
* f_output_chain: log status of auto filtersGravatar wm42018-04-29
| | | | | Just so users don't think the filters do anything when they don't insert any filters.
* f_output_chain: log input instead of output formatGravatar wm42018-04-29
| | | | | | | I think this is more intuitive. This requires a dedicated "out" dummy filter. But keep the "in" dummy filter for symmetry, like in the old filter code. (We could remove the "in" dummy filter, because the first actual filter would still show the real input format.)
* client API: add some render API extensions for timingGravatar wm42018-04-29
| | | | | | | | | | | | Attempts to enable the following things: - let a render API user do "proper" audio-sync video timing itself - make it possible to not re-render repeated frames if the API user has better mechanisms available (e.g. waiting for a DisplayLink cycle instead) - allow the user to delay or skip redraws if it makes sense Basically this information will be needed by API users who want to be "clever" about optimizing timing and rendering.
* vo_libmpv: support GPU rendered screenshotsGravatar wm42018-04-29
| | | | | Like DR, this needed a lot of preparation, and here's the boring glue code that finally implements it.
* vo_libmpv: adjust redraw handling to new API semanticsGravatar wm42018-04-29
| | | | | | | | | | | | | | | | | In MPV_RENDER_PARAM_ADVANCED_CONTROL mode, a simple update callback does not necessarily make the API user redraw. So handle it differently. For one, setting vo->want_redraw already uses the "normal" redraw path, which will call draw_frame() and set next_frame. Then there are redraws trigered by mpv_render_context_set_parameter(), which are on the render thread, and would require a separate mechanism. I decided this is not really a good idea, since it's not even clear that setting an arbitrary parameter should redraw. Also this could trigger an unbounded number of redraws. The user can trigger redraws manually if really needed, depending on the parameter that's being set. If we really wanted vo_libmpv to do this, we could add a new flag like need_redraw, which would be 4 lines of code or so.
* vo_libmpv: remove annoying indirectionsGravatar wm42018-04-29
| | | | I think this is a bit more readable this way.
* vo_libmpv: move some update() callbacks out of context lockGravatar wm42018-04-29
| | | | | | | | update() used to require the lock, but now it doesn't matter. It's slightly better to do it outside of the lock now, in case the update callback reschedules before returning, and the user render thread tries to acquire the still held lock (which would require 2 more context switches).
* vo_libmpv: move up update() functionGravatar wm42018-04-29
| | | | Avoids a forward declaration.
* vo_libmpv: add support for DRGravatar wm42018-04-29
| | | | | With all the preparation work done, this only has to do the annoying dance of passing it through all the damn layers.
* client API: preparations for allowing render API to use DR etc.Gravatar wm42018-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this.
* vo: move DR helper code to a separate source fileGravatar wm42018-04-29
| | | | | So it can be reused by vo_libmpv.c, which needs to use it in a slightly different way.
* mp_image: fixup a simple 10L in ref_bufferGravatar Jan Ekström2018-04-21
| | | | | We didn't want to set the pointer to zero, but the value that the pointer was pointing towards.
* vo_gpu: move some extra code for screenshot to video.cGravatar wm42018-04-20
| | | | | This also happens to fix some UB on the error path (target being declared after the first "goto done;").
* client API: minor clarificationGravatar wm42018-04-20
| | | | This was a bit confusing.
* README: mention that Libav support is brokenGravatar wm42018-04-20
| | | | | I hoped Libav would add the FFmpeg changes (codec/demuxer/filter list APIs), but nothing happened. So it's broken currently.
* encode: simplify colorspace settingGravatar wm42018-04-20
| | | | | This was also refactored at some point, and is now unnecessarily roundabout.
* encode: cosmeticsGravatar wm42018-04-20
| | | | Mostly whitespace changes; some semantic preserving transformations.
* vo_lavc: remove pointless uint32_t type for int valuesGravatar wm42018-04-20
| | | | | params->w/h are int, and the further use of these variables are int. The uint32_t is probably some refactoring artifact.
* encode: remove some unused functionsGravatar wm42018-04-20
|
* encoding: deprecate a bunch of obscure optionsGravatar wm42018-04-20
| | | | | --audio-delay does not work correctly yet, but hopefully this can be fixed later.
* audio: fix EOF handling if there was no data at allGravatar wm42018-04-20
| | | | | | It stopped and did nothing, instead of terminating (or just letting video play, if there was any video). Regression due to recent filter changes.
* video: pass through container fps to filtersGravatar wm42018-04-19
| | | | | | | | | | | | This means vf_vapoursynth doesn't need a hack to work around the filter code, and libavfilter filters now actually get the frame_rate field on input pads set. The libavfilter doxygen says the frame_rate field is only to be set if the frame rate is known to be constant, and uses the word "must" (which probably means they really mean it?) - but ffmpeg.c sets the field to mere guesses anyway, and it looks like this normally won't lead to problems.
* demux: support for some kinds of timed metadataGravatar wm42018-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes ICY title changes show up at approximately the correct time, even if the demuxer buffer is huge. (It'll still be wrong if the stream byte cache contains a meaningful amount of data.) It should have the same effect for mid-stream metadata changes in e.g. OGG (untested). This is still somewhat fishy, but in parts due to ICY being fishy, and FFmpeg's metadata change API being somewhat fishy. For example, what happens if you seek? With FFmpeg AVFMT_EVENT_FLAG_METADATA_UPDATED and AVSTREAM_EVENT_FLAG_METADATA_UPDATED we hope that FFmpeg will correctly restore the correct metadata when the first packet is returned. If you seke with ICY, we're out of luck, and some audio will be associated with the wrong tag until we get a new title through ICY metadata update at an essentially random point (it's mostly inherent to ICY). Then the tags will switch back and forth, and this behavior will stick with the data stored in the demuxer cache. Fortunately, this can happen only if the HTTP stream is actually seekable, which it usually is not for ICY things. Seeking doesn't even make sense with ICY, since you can't know the exact metadata location. Basically ICY metsdata sucks. Some complexity is due to a microoptimization: I didn't want additional atomic accesses for each packet if no timed metadata is used. (It probably doesn't matter at all.)
* player: remove in_dispatch fieldGravatar wm42018-04-18
| | | | (Not sure if worth the trouble, but it does seem less awkward.)
* dispatch: simplify, disallow recursive invocationGravatar wm42018-04-18
| | | | | | | | | Recursive invocation was needed up until the previous commit. Drop this feature, and simplify the code. It's more logical, and easier to detect miuses of the API. This partially reverts commit 3878a59e. The original reason for it was removed.
* w32_common: avoid recursive dispatch queue callsGravatar wm42018-04-18
| | | | | | | | I suppose this doesn't matter in practice, i.e. even if calls relayed over the dispatch queue will cause WndProc to be invoked, WndProc will never run for a longer time. Preparation for removing recursion support from the dispatch queue code.
* scripting: change when/how player waits for scripts being loadedGravatar wm42018-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fundamentally, scripts are loaded asynchronously, but as a feature, there was code to wait until a script is loaded (for a certain arbitrary definition of "loaded"). This was done in scripting.c with the wait_loaded() function. This called mp_idle(), and since there are commands to load/unload scripts, it meant the player core loop could be entered recursively. I think this is a major complication and has some problems. For example, if you had a script that does 'os.execute("sleep inf")', then every time you ran a command to load an instance of the script would add a new stack frame of mp_idle(). This would lead to some sort of reentrancy horror that is hard to debug. Also misc/dispatch.c contains a somewhat tricky mess to support such recursive invocations. There were also some bugs due to this and due to unforeseen interactions with other messes. This scripting stuff was the only thing making use of that reentrancy, and future commands that have "logical" waiting for something should be implemented differently. So get rid of it. Change the code to wait only in the player initialization phase: the only place where it really has to wait is before playback is started, because scripts might want to set options or hooks that interact with playback initialization. Unloading of builtin scripts (can happen with e.g. "set osc no") is left asynchronous; the unloading wasn't too robust anyway, and this change won't make a difference if someone is trying to break it intentionally. Note that this is not in mp_initialize(), because mpv_initialize() uses this by locking the core, which would have the same problem. In the future, commands which logically wait should use different mechanisms. Originally I thought the current approach (that is removed with this commit) should be used, but it's too much of a mess and can't even be used in some cases. Examples are: - "loadfile" should be made blocking (needs to run the normal player code and manually unblock the thread issuing the command) - "add-sub" should not freeze the player until the URL is opened (needs to run opening on a separate thread) Possibly the current scripting behavior could be restored once new mechanisms exist, and if it turns out that anyone needs it. With this commit there should be no further instances of recursive playloop invocations (other than the case in the following commit), since all mp_idle()/mp_wait_events() calls are done strictly from the main thread (and not commands/properties or libmpv client API that "lock" the main thread).
* cocoa-cb: fix a warning with swift 4.1 and slight cleanupGravatar Akemi2018-04-17
| | | | | | the icc profile data is mutated to an UnsafeMutablePointer and could possibly changed. therefore the size of it should be accessed before a possible change.
* HIDRemote: fix volume buttons on macOS 10.13Gravatar Akemi2018-04-17
| | | | | | | this is a backport of line 1039 to 1046 from https://github.com/iospirit/HIDRemote/commit/33a32ab6136feb8b8220e99ec52c7504c3a82242#diff-8a4d13f0849b3beffa4267954ca28517R1039 Fixes #5721
* hwdec_ios: fix crash after mapper_init failureGravatar Aman Gupta2018-04-17
|
* demux: mark eia608 packets as keyframesGravatar Aman Gupta2018-04-17
| | | | | | This fixes an issue where captions stop rendering after an in-demuxer-cache seek, because the demuxer keeps waiting to find a keyframe (ds->skip_to_keyframe set to true in execute_cache_seek).
* demux, player: mark dependent tracksGravatar Aman Gupta2018-04-17
| | | | | | | ffmpeg marks audio tracks which are not meant to be played standalone as DEPENDENT. these are typically used in DVB broadcasts for audio descriptions, and are meant to be mixed into the main audio track during playback.
* client API: make sure to send IDLE event after mpv_initialize()Gravatar wm42018-04-16
| | | | | | | | | | | This was slightly broken: since mp_initialize() did not necessarily interrupt core_thread() (which is waiting for initialization), it did not enter mp_play_files(), which would have sent an IDLE event. I suppose that in some cases (like with mpv-android), the initial IDLE event was never actually sent, because the first wakeup of the core thread happens with the "loadfile" command, which will disallow the core thread an IDLE event.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 15:57:46 +0000