path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* encode: cosmeticswm42018-04-201-33/+48
| | | | Mostly whitespace changes; some semantic preserving transformations.
* encode: remove some unused functionswm42018-04-202-20/+0
* encoding: deprecate a bunch of obscure optionswm42018-04-201-4/+8
| | | | | --audio-delay does not work correctly yet, but hopefully this can be fixed later.
* demux: support for some kinds of timed metadatawm42018-04-182-7/+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.)
* av_common: cosmetic simplification to ffmpeg component iteration loopswm42018-04-031-4/+2
* f_lavfi: use new libavfilter iteration APIwm42018-04-031-1/+0
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-032-51/+0
| | | | This is new, thus a dependency bump is required.
* Fix recent FFmpeg deprecationswm42018-02-133-49/+46
| | | | | | | | | This includes codec/muxer/demuxer iteration (different iteration function, registration functions deprecated), and the renaming of AVFormatContext.filename to url (plus making it a malloced string). Libav doesn't have the new API yet, so it will break. I hope they will add the new APIs too.
* codecs: remove unused family fieldwm42018-02-013-14/+7
| | | | | | | | | | MPlayer used this to distinguish multiple decoder wrappers (such as libavcodec vs. binary codec loader vs. builtin decoders). It lost meaning in mpv as non-libavcodec things were dropped. Now it doesn't serve any purpose anymore. Parsing was removed quite a while ago, and the recent filter change removed any use of the internal family field. Get rid of it.
* audio: move to decoder wrapperwm42018-01-301-8/+0
| | | | | | | | | | | | | | | | Use the decoder wrapper that was introduced for video. This removes all code duplication the old audio decoder wrapper had with the video code. (The audio wrapper was copy pasted from the video one over a decade ago, and has been kept in sync ever since by the power of copy&paste. Since the original copy&paste was possibly done by someone who did not answer to the LGPL relicensing, this should also remove all doubts about whether any of this code is left, since we now completely remove any code that could possibly have been based on it.) There is some complication with spdif handling, and a minor behavior change (it will restrict the list of codecs to spdif if spdif is to be used), but there should not be any difference in practice.
* video: rewrite filtering glue codewm42018-01-302-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* av_log: stop accessing private ffmpeg fieldswm42018-01-031-2/+2
| | | | MPlayer legacy added in 3c49701490aecb.
* command: add demuxer-lavf-list propertyRicardo Constantino2018-01-022-0/+18
| | | | | | | | | Was only available with --demuxer-lavf-format=help and the demuxer needed to be used for it to actually print the list. This can be used in the future to check if 'dash' support was compiled with FFmpeg so ytdl_hook can use it instead. For now, dashdec is too rudimentary to be used right away.
* build: move copyright statement to a shared locationwm42018-01-012-0/+2
| | | | | | | Now macosx_menubar.m and mpv.rc (win32) use the same copyright string. (This is a bit roundabout, because mpv.rc can't use C constants. Also the C code wants to avoid rebuilding real source files if only version.h changed, so only version.c includes version.h.)
* encode: implement --oset-metadata, and --oremove-metadataTheAMM2017-12-262-1/+27
| | | | | | | | | | | | This commit introduces a new --oset-metadata key-value-list option, allowing the user to specify output metadata when encoding (eg. --oset-metadata=title="Hello",comment="World"). A second option --oremove-metadata is added to exclude existing metadata from the output file (assuming --ocopy-metadata is enabled). Not all output formats support all tags, but luckily libavcodec simply discards unsupported keys.
* encode: rename option --ometadata to --ocopy-metadataTheAMM2017-12-262-4/+4
| | | | | | --copy-metadata describes the result of the option better, (copying metadata from the source file to the output file). Marks the old --no-ometadata OPT_REMOVED with a suggestion for the new --no-ocopy-metadata.
* tags: add mp_tags_removeKevin Mitchell2017-12-262-0/+21
| | | | | This removes all tags matching the provided key. This will be used for removing metadata tags during encoding.
* msg: bump up log level of --log-fileNiklas Haas2017-12-151-2/+2
| | | | This now logs -v -v by default, instead of -v.
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-152-3/+3
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* Fix various typos in log messagesNicolas F2017-12-031-1/+1
* av_common: drop old hack against ancient lavc vdpau wrapperwm42017-12-011-6/+1
| | | | | | | Seems like they finally got rid of this. It was the first lavc vdpau API, and mpv stopped supporting it in favor of newer APIs a long time ago, causing confusion to users who tried to enable vdpau decoding by forcing the decoders (MPlayer style).
* build: make it easier to force FFmpeg upstreamwm42017-11-011-4/+2
| | | | | | | | | | | Apparently some people want this. Actually making it compile is still their problem, though, and I expect that build with FFmpeg upstream will occasionally be broken (as it is right now). This is because mpv also relies on API provided by Libav, and if FFmpeg hasn't merged that yet, it's not our problem - we provide a version of FFmpeg upstream with those changes merged, and it's called ffmpeg-mpv. Also adjust the README which still talked about FFmpeg releases.
* Bump libav* API usewm42017-10-301-4/+4
| | | | (Not tested on Windows and OSX.)
* av_common: fix Libav buildwm42017-10-161-0/+13
| | | | Fucking shit.
* video: properly pass through ICC datawm42017-10-162-0/+38
| | | | | | | | | | | | | | | | | | The same should happen with any other side data that matters to mpv, otherwise filters will drop it. (No, don't try to argue that mpv should use AVFrame. That won't work.) ffmpeg_garbage() is copy&paste from frame_new_side_data() in FFmpeg (roughly feed201849b8f91), because it's not public API. The name reflects my opinion about FFmpeg's API. In mp_image_to_av_frame(), change the too-fragile *new_ref = (struct mp_image){0}; into explicitly zeroing out the fields that are "transferred" to the created AVFrame.
* msg: make --msg-level affect --log-file toowm42017-10-041-1/+1
| | | | | | | But --msg-level can only raise the log level used for --log-file, because the original idea with --log-file was that it'd log verbose messages to disk even if terminal logging is lower than -v or fully disabled.
* build: add preliminary LGPL modewm42017-09-212-18/+14
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* player: fix --lavfi-complex freezewm42017-08-111-4/+5
| | | | | | | | | | | | | | | | | | | Commit 0e0b87b6f3297 fixed that dropped packets did not trigger further work correctly. But it also made trivial --lavfi-complex freeze. The reason is that the meaning if DATA_AGAIN was overloaded: the decoders meant that they should be called again, while lavfi.c meant that other outputs needed to be checked again. Rename the latter meaning to DATA_STARVE, which means that the current input will deliver no more data, until "other" work has been done (like reading other outputs, or feeding input). The decoders never return DATA_STARVE, because they don't get input from the player core (instead, they get it from the demuxer directly, which is why they still can return DATA_WAIT). Also document the DATA_* semantics in the enum. Fixes #4746.
* vo_opengl: further GL API use separationwm42017-08-072-0/+7
| | | | | | | | | | | | | | | Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
* common, vo_opengl: add/use helper for formatted strings on the stackwm42017-07-242-0/+17
| | | | | | | | | | | Seems like I really like this C99 idiom. No reason not to generalize it do snprintf(). Introduce mp_tprintf(), which basically this idiom to snprintf(). This macro looks like it returns a string that was allocated with alloca() on the caller site, except it's portable C99/C11. (And unlike alloca(), the result is valid only within block scope.) Use it in 2 places in the vo_opengl code. But it has the potential to make a whole bunch of weird looking code look slightly nicer.
* Replace remaining avcodec_close() callswm42017-07-161-8/+2
| | | | | | | | This API isn't deprecated (yet?), but it's still inferior and harder to use than avcodec_free_context(). Leave the call only in 1 case in af_lavcac3enc.c, where we apparently seriously close and reopen the encoder for whatever reason.
* options: handle suffixes like -add in a more generic waywm42017-06-261-3/+3
| | | | | | | | | | | | | | | | This affects options like --vf or --display-tags. These used a "*" suffix to match all options starting with a specific name, and handled the rest in the option parser. Change this to remove the "*" special case, and require every option parser to declare a list of allowed suffixes via m_option_type.actions. The new way is conceptually simpler, because we don't have to account for the "*" in a bunch of places anymore, and instead everything is centrally handled in the CLI part of the option parser, where it's actually needed. It automatically enables suffixes like -add for a bunch of other stringlist options.
* options: unbreak -vwm42017-06-231-1/+1
| | | | Sigh... broken with the --really-quiet commit. I hate -v.
* options: remove weird --really-quiet special behaviorwm42017-06-231-1/+5
| | | | | | | | | This was especially grating because it causes problems with the option/property unification, uses as only thing OPT_FLAG_STORE, and behaves weird with the client API or scripts. It can be reimplemented in a much simpler way, although it needs slightly more code. (Simpler because less special cases.)
* encode_lavc: move from GPL 2+ to LGPL 2.1+.Rudolf Polzer2017-06-133-14/+37
* player: make sure version information is always included in --log-filewm42017-05-222-0/+14
| | | | | | | If --log-file was used in config files, this could be missing due to the exact timing when the messages are print, and when the options are applied. Fix this by always dumping the version again when a log file is opened.
* demux_raw: drop "mp-rawvideo" usewm42017-05-201-4/+0
| | | | | | This is an old pseudo codec to pass through the pixel format. Setup a suitable AVCodecParameter directly instead, so the "rawvideo" codec can be used.
* av_log: mark as almost LGPLwm42017-05-051-0/+2
| | | | | All authors agreed. Some of the code originated from commit 3c49701490aecb by michael, thus the license change has to be delayed.
* msg.c/h: partially change license to LGPLwm42017-05-052-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | msg.c is "partial" due to "michael", whose work can be changed to LGPL only once the core is LGPL. It's explained in the Copyright file. I prefer to do the relicensing incrementally (due to the overwhelming workload). Changing the license before that happens would be legally questionable, but nothing can stop us from essentially marking it as "will be LGPL". All authors have agreed to LGPL, with the following exceptions: 9df11ee8bf: the author (probably) didn't agree, but the line that is added is later fully removed. 35e90f1556: was not asked, but all iconv code was 100% removed from the mp_msg mechanism (we alwas require UTF-8 now). 4e4f3f806e: the change by michael. 50a86fcc34: the identify variable was move, and completely removed the latest in commit 48bd03dd91232. 1f6c494641: did not agree, but due to a major mp_msg change the added line became unnecessary and was removed. da63498bf9: was not reachable, but the MPlayer GUI is gone from mpv anyway (also commit fc4d6e617d8d removed these specific additions a long time ago).
* common.h: change license to LGPLwm42017-04-211-7/+7
| | | | | | | | | | | The only definitions from MPlayer code are the CONTROL_* defines (added in 7a2eec4b as part of libao2 - not part of libao), and MP_NOPTS_VALUE, which was added in e6338c58. The latter is by "michael", who has agreed under the condition that the core is LGPL, which has not happened yet, but considering the macro definition used to be different, has the same value and similar name to libavformat's AV_NOPTS_VALUE (which existed first, and as LGPL), and that this almost certainly not copyrightable, I'm assuming that this is fine.
* video: support positional arguments for automatic lavfi option bridgewm42017-04-031-0/+30
| | | | | | Now e.g. --vf=pad=1000:1000 works. All in all pretty ugly and hacky. Just look away.
* encode_lavc: fix build failure after libavcodec major bumpwm42017-03-231-2/+2
* options: add M_OPT_FILE to some more file optionsPhilip Sequeira2017-03-061-1/+1
| | | | (Helps shell completion.)
* Use AV_INPUT_BUFFER_PADDING_SIZE instead of deprecated onewang-bin2017-02-081-2/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* player: add experimental stream recording featurewm42017-02-072-0/+405
| | | | | This is basically a WIP, but it can't remain in a branch forever. A warning is print when using it as it's still a bit "shaky".
* build: explicitly check for FFmpeg vs. Libav, and their exact versionswm42017-01-271-4/+4
| | | | | | | | | | | | | | | | | | In a first pass, we check whether libavcodec is present. Then we try to compile a snippet and check for FFmpeg vs. Libav. (This could probably also be done by somehow checking the pkgconfig version. But pkg-config can't deal with that idiotic FFmpeg idea that a micro version number >= 100 identifies FFmpeg vs. Libav.) After that we check the project-specific version numbers. This means it can no longer happen that we accidentally allow older, unsupported versions of FFmpeg, just because the Libav version numbers are somehow this way. Also drop the resampler checks. We hardcode which resampler to each with each project. A user can no longer force use of libavresample with FFmpeg.
* ad_lavc, vd_lavc: preserve codec_id/codec_type when setting paramswm42017-01-251-0/+8
| | | | | | | | | | avcodec_parameters_to_context() overwrites codec_type and codec_id. But we already set these by passing the selected AVCodec to avcodec_alloc_context3(). It's entirely possible that at least codec_id is different when forcing codecs with --ad/--vd. It's probably better not to cause confusion by overwriting them. It might even trigger undefined behavior in libavcodec (how it behaves or whether codec_id is supposed to be strictly set is unknown, though).
* ad_lavc, vd_lavc: move mpv->lavc decoder parameter setup to common codewm42017-01-252-6/+70
| | | | | | | | This can be useful in other contexts. Note that we end up setting AVCodecContext.width/height instead of coded_width/coded_height now. AVCodecParameters can't set coded_width, but this is probably more correct anyway.
* av_common: remove old/unused timestamp passthrough codewm42017-01-241-21/+8
| | | | | | | | | | | | | | | | | | This attempted to pass through double float timestamps in a bit exact way by reinterpret casting them to int64_t. This usually worked, because libavcodec (in decoding mode) is mostly not allowed to interpret timestamps. libavcodec doesn't even know the unit of the timestamps, unless the API user sets a timebase. We've stopped doing this, and always set a timebase. Only ad_spdif.c still used this (indirectly through mp_set_av_packet()), but doesn't actually need timestamps on the packet. In fact, it's already explicitly setting the packet timestamp fields to 0 before passing it to FFmpeg API. This code is unused, and the passthrough method wasn't terribly elegant to begin with. Drop this code. Arbitrarily use AV_TIME_BASE_Q as fallback in situations the passthrough was used.
* av_common: drop unused functionwm42017-01-242-24/+0
| | | | Unused since the AVCodecParameters change.
* options: drop deprecated --vd/--ad codecs selection featureswm42017-01-191-58/+11
| | | | | Only simple selection works now. Using "-" to terminate codec selection remains in the code (might get undeprecated).
* Prefix libavcodec CODEC_FLAG_ constants with AV_wm42016-12-291-1/+1
| | | | The unprefixed versions are silently deprecated.
* options: deprecate some other complex --ad/--vd featureswm42016-12-231-0/+3
| | | | | | | Who even needs those? Once these deprecations are gone, --ad/--vd are simple lists without any kind of complex matching.
* options: deprecate codec family selection in --vd/--adwm42016-12-232-12/+20
| | | | | Useless now, so get rid of it. Also affects some user-visible display things (like reported codec in use).
* audio: change how spdif codecs are selectedwm42016-12-232-21/+0
| | | | | | | | | | | | | | Remove ad_spdif from the normal codec list, and select it explicitly. One goal was to decouple this from the normal codec selection, so they're less entangled and the decoder selection code can be simplified in the far future. This means spdif codec selection is now done explicitly via select_spdif_codec(). We can also remove the weird requirements on "dts" and "dts-hd" for the --audio-spdif option, and it can just do the right thing. Now both video and audio codecs consist of a single codec family each, vd_lavc and ad_lavc.
* Remove compatibility thingswm42016-12-074-34/+0
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* av_common: always make sure to return a valid timebasewm42016-11-101-1/+5
| | | | | | | | | | | | | | | av_reduce(&num, &den, 1, 14112000, 1000000) can return num=0, den=1. This means a 1/14112000 timebase (as used by the mp3 demuxer) would become invalid. The intention of mp_get_codec_timebase() is to always return a valid timebase. av_reduce() probably does the logically correct thing - so add a fallback to the safe default timebase. Also, increase the av_reduce() parameter to INT_MAX. Let's just pray this doesn't cause any actual problems. libavformat does the same, but might be in a different position due to using av_rescale() etc., while we convert between fractional timestamps and floats.
* demux_lavf: "support" mov edit lists and log errors if usedwm42016-10-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | FFmpeg recently got "support" for mov edit lists. This is a terrible hack that will fail completely at least with some decoders (in particular wrappers for hardware decoding might be affected). As such it makes no point to pretend they are supported, even if we assume that the "intended" functionality works, that there are no implementation bugs (good luck with all that messy code added to the already huge mov demuxer), and that it covers enough of the mov edit list feature to be of value. So log an error if the FFmpeg code for mov edit lists appears to be active - AV_PKT_FLAG_DISCARD is used only for "clipping" edit list segments on non-key frame boundaries. In the first place, FFmpeg committed this only because Google wanted it in, and patch review did not even pick up obvious issues. (Just look how there was no lavc version bump when AV_PKT_FLAG_DISCARD was added.) We still pass the new packet flag to the decoders (av_common.c change), which means we "support" FFmpeg's edit list code now. (Until it breaks due to FFmpeg not caring about all the details.)
* ad_lavc, vd_lavc: fix a recent libavcodec deprecation warningwm42016-10-171-0/+9
| | | | | | | | | | | | | | Both AVFrame.pts and AVFrame.pkt_pts have existed for a long time. Until now, decoders always returned the pts via the pkt_pts field, while the pts field was used for encoding and libavfilter only. Recently, pkt_pts was deprecated, and pts was switched to always carry the pts. This means we have to be careful not to accidentally use the wrong field, depending on the libavcodec version. We have to explicitly check the version numbers. Of course the version numbers are completely idiotic, because idiotically the pkg-config and library names are the same for FFmpeg and Libav, so we have to deal with this explicitly as well.
* msg: flush after every message for --log-filewm42016-09-301-0/+1
| | | | | | We'd like to get log messages on the output as soon as possible in the output. I also feel like using fflush() is nicer than using setvbuf(). Who knows how the latter behaves on win32.
* msg: make --log-file and --dump-stats accept config path expansionwm42016-09-281-17/+27
| | | | | | | | | Seems like a valid use-case. Not sure if I like it calling back into the config code. Care has to be taken for not letting the config path resolving code dead-lock (which is why locking details in the msg.c code are changed). Fixes #3591.
* client API: more or less deprecate mpv_set_option()wm42016-09-211-19/+19
| | | | | | | | | | | | | | | | | | | | | | With the merging of options and properties, the mpv_set_option() function is close to being useless, and mpv_set_property() can be used for everything instead. There are certain conflicts remaining, which are explained in depth in the docs. For now, none of this should affect existing code using the client API. Make mpv_set_property() redirect to mpv_set_option() before initialization. Remove some options marked as M_OPT_FIXED. The "pause" and "speed" options cannot be written anymore without the playloop being notified by it, so the M_OPT_FIXED does nothing. For "vo-mmcss-profile", the problem was lack of synchronization, which has been added. I'm not sure what the problem was with "frames" - I think it was only marked as M_OPT_FIXED because changing it during playback will have no effect. Except for pause/speed, these changes are needed to make them writable as properties after mpv_initialize(). Also replace all remaining uses of CONF_GLOBAL with M_OPT_FIXED.
* player: make --log-file and --dump-stats freely settable at runtimewm42016-09-192-21/+37
| | | | | Same deal as with the previous commit. We use the file paths to decide when we should attempt to reopen them.
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* common: use char array for version stringwm42016-09-062-4/+4
| | | | | Use a char array instead of a pointer, which allows using the version variables in a constant context.
* m_config: introduce basic mechanism to synchronize global option updateswm42016-09-021-1/+5
| | | | | | | | | | | | | | | | | | The way option runtime changes are handled is pretty bad in the current codebase. There's a big option struct (MPOpts), which contains almost everything, and for which no synchronization mechanism exists. This was handled by either making some options read-only after initialization, duplicating the option struct, using sub-options (in the VO), and so on. Introduce a mechanism that creates a copy of the global options (or parts of it), and provides a well-defined way to update them in a thread-safe way. Most code can remain the same, just that all the component glue code has to explicitly make use of it first. There is still lots of room for improvement. For example, the update mechanism could be better.
* common: add assert.h includewm42016-08-281-0/+1
| | | | Because why not.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-192-0/+26
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* av_common: improve rounding for float->int timestamp conversionswm42016-08-191-2/+4
* player: fatal error if linked and compiled FFmpeg versions mismatchwm42016-07-012-10/+6
| | | | | | | | | We don't support this anymore. This tries to exit in a controlled way after command line options are applied in order to honor logging options and, in case of libmpv, not to kill the host. Not sure if it would be better to just vomit text to stderr and call abort().
* av_log: readd ffmpeg library runtime version mismatch warningwm42016-05-011-1/+13
| | | | It just happens far too often.
* encode_lavc: Migrate to codecpar API.Rudolf Polzer2016-04-112-159/+198
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-312-0/+18
| | | | | | | | | 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.
* playlist: improve shuffle algorithmNiklas Haas2016-03-201-5/+3
| | | | | | | | | | | The old algorithm produced results which were not uniformly distributed, i.e. some particular shuffles were preferred over others. The new algorithm is an implementation of the Fisher-Yates shuffle which is guaranteed to shuffle uniformly given a sufficiently uniform rand() and ignoring potential floating-point errors. Signed-off-by: wm4 <wm4@nowhere>
* av_common: explicitly exclude _vdpau deccoders from enumerationwm42016-03-021-1/+6
| | | | | | | | | | Completely pointless abominations that FFmpeg refuses to remove. They are ancient, long deprecated API which we can't use anymore. They confused users as well. Pretend that they don't exist. Due to the way --vd works, they can't even be forced anymore. The older hack which explicitly rejects these can be dropped as well.
* msg: introduce partial line buffers per mp_logwm42016-03-011-25/+28
| | | | | | | | | | | | | | | | The goal is reducing log messups (which happen surprisingly often) by buffering partial lines in mp_log. This is still not 100% reliable, but better. The extrabuffers for MSGL_STATUS and MSGL_STATS are not needed anymore, because a separate mp_log instance can be used if problems really occur. Also, give up, and replace the snprintf acrobatics with bstr. mp_log.partial has a quite subtle problem wrt. talloc: talloc parents can not be used, because there's no lock around the internal talloc structures associated with mp_log. Thus it has to be freed manually, even if this happens through a talloc destructor.
* msg: minor simplificationwm42016-03-011-11/+6
| | | | | Instead of playing ugly tricks with the buffer to append a \r or \n to the text buffer, extend print_terminal_line() to print a second string.
* av_log: avoid partial lineswm42016-03-011-2/+7
| | | | | | | | | | | | | We want to add a prefix to the ffmpeg log message, so we called mp_msg multiple times until now. But logging such partial lines is a race condition, because there's only one internal mp_msg buffer, and no external mp_msg locks. Avoid this by building the message on a stack buffer. I might make a mp_log-local partial line buffer, but even then av_log() can be called from multiple threads, while targetting the same mp_log. (Really, ffmpeg's log API needs to be fixed.)
* msg: use dynamic buffer for message formattingwm42016-03-011-11/+19
| | | | | | | | | | | | | | | | | Until now, a rather large stack buffer was used for this, and also a static buffer in mp_log_root. The latter was added to buffer partial lines, and the stack buffer was used only for MSGL_STATUS and MSGL_STATS (I guess because these are the most likely/severe to clash with partial line buffering). Make the buffer in mp_log_root dynamically sized, so we don't get cut off log lines if the text is excessively large. (The OpenGL extension list dumped by vo_opengl is such an example.) Since we still have to support partial line buffering (FFmpeg's log callbacks leave no other choice), keep the stack buffer. But make it smaller; there's no way all ~6KB are going to be needed in any situation.
* command: add encoder-list propertywm42016-03-012-0/+16
| | | | | Also change decoder-list (for the sake of sharing the underlying code for both properties).
* Initial Android supportJan Ekström2016-02-101-0/+1
| | | | | * Adds an 'android' feature, which is automatically detected. * Android has a broken strnlen, so a wrapper is added from FreeBSD.
* common/common.c: handle utf16 in mp_parse_escapekwkam2016-02-061-1/+12
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: make libavfilter mandatorywm42016-02-051-9/+2
| | | | | | The complex filter support that will be added makes much more complex use of libavfilter, and I'm not going to bother with adding hacks to keep libavfilter optional.
* audio/video: merge decoder return valueswm42016-02-011-0/+7
| | | | | | Will be helpful for the coming filter support. I planned on merging audio/video decoding, but this will have to wait a bit longer, so only remove the duplicate status codes.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-199-63/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* global: add client API pointer to library handlewm42016-01-151-0/+1
| | | | | | | Makes the next commit simpler. It's probably a bad idea to add more fields to the global state, but on the other hand the client API state is pretty much per-instance anyway. It also will help with things like the proposed libmpv custom stream API.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-116-6/+6
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* common: add mp_tag_str() utility functionwm42016-01-112-0/+20
* common: allow "\/" as escape sequencewm42016-01-081-1/+2
| | | | | | | | | | | | | mp_parse_escape() is used by the JSON parser in json.c, and JSON allows escaping "/" (solidus). Although it makes no sense, apparently Javascript traditionally allowed that as escape sequence for working around issues with embedding Javascript in HTML. (Or something like this must have been the history of this issue.) Since it's valid in Javascript, it had to be valid in JSON as well, and JSON explicitly specifies it as valid escape. Fixes #2694.
* player: make watch later/resume work when "playing" directorieswm42016-01-062-0/+18
| | | | | | | | | | | | | | If you do "mpv /bla/", and then branch out into sub-directories using playlist navigation, and then used quit and watch later, then playing the same directory did not resume from the previous point. This was because resuming is based on the path hash, so a path prefix can't be detected when resuming the parent directory. Solve this by writing each path prefix when playing directories is involved. (This includes all parent paths, so interestingly, "mpv /" would also resume in the above example.) Something like this was requested multiple times, and I want it too.
* command: replace ROUND() with lrint()wm42015-12-261-2/+0
| | | | | lrint() pretty much does what ROUND() is supposed to do, but it's more precise.
* msg: remove redundant conditionwm42015-12-051-1/+1
| | | | Found by Coverity.
* video: pass through libavformat has_b_frames fieldwm42015-10-191-0/+1
| | | | | | | This fixes initial decoding of some samples. See #1341. According to Libav devs, this should be considered a libavcodec bug, but as it's hard to fix, here we go.
* msg: remove the useless trailing comment from stats dumpingwm42015-10-141-4/+2
| | | | | The origin of the stats line was added as a comment (starting with '#'). It was useless and just blowing up file sizes.
* video: make container vs. bitstream aspect ratio configurablewm42015-08-301-1/+0
| | | | | | Utterly idiotic bullshit. Fixes #2259.
* av_common: remove deprecated API usagewm42015-08-071-2/+0
| | | | | | | | | | As the removed comment says, not copying this field may cause problems on older libav* releases. See also commit 5f7de399. Remove this, as newer FFmpeg releases are available. As of this commit, use of mpv with FFmpeg 2.5.x and below, or Libav 11 and below is not recommended, and may lead to random video decoding issues. (Although the failure cases are apparently somewhat obscure.)
* player: warn against using HLS URLs with --playlistwm42015-08-041-0/+4
| | | | | | | | | That just makes no sense, but seems to be a somewhat common user error. The detection is not perfect. It's conceivable that EXT-X-... headers are used in normal m3u playlists. After all, HLS playlists are by definition a compatible extension to m3u playlists, as stupid as it sounds.
* av_log: remove dumb shitwm42015-07-181-24/+1
| | | | | | | It's the user's fault if he/she/it does something that is not recommended. Fixes #2110.
* player: parse and expose m3u playlist titleswm42015-07-101-0/+2
| | | | Requested. Closes #2100.
* av_log: print FFmpeg versionwm42015-07-031-0/+4
| | | | | The individual library versionsd are pretty useless. This will actually tell us at least the git hash or git tag of the FFmpeg build.
* client API: allow using msg-level option for log messageswm42015-06-202-11/+13
| | | | | | | | | | | | | | | | Client API users can enable log output with mpv_request_log_messages(). But you can enable only a single log level. This is normally enough, but the --msg-level option (which controls the terminal log level) provides more flexibility. Due to internal complexity, it would be hard to provide the same flexibility for each client API handle. But there's a simple way to achieve basically the same thing: add an option that sends log messages to the API handle, which would also be printed to the terminal as by --msg-level. The only change is that we don't disable this logic if the terminal is disabled. Instead we check for this before the message is output, which in theory can lower performance if messages are being spammed. It could be handled with some more effort, but the gain would be negligible.
* av_log: skip prefix if unknownwm42015-06-201-2/+3
| | | | | | | | This happens with av_log(NULL, ...) calls. Drop the "?: " fallback prefix, because it was confusing. (Of course FFmpeg should not do this at all, but it's a very long way to making the FFmpeg log callback sane.)
* Various spelling fixesMarcin Kurczewski2015-06-181-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* av_log: set default av_log callback on exitwm42015-06-171-0/+1
| | | | | | | | | | | | This is slightly "dangerous", because it could overwrite a log callback another library has set, after we've set our own callback. But it's probably still slightly better than leaving our own callback, which will run the fallback code if no mpv instance is set. (Multiple mpv instances sharing the same global state will safely avoid overwriting each other's log callback.) Note that we can't do much better, because the global state in FFmpeg is obviously insane.
* audio: add --audio-spdif as new method for enabling passthroughwm42015-06-052-0/+29
| | | | | | | | | | | | | 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.)
* path: make mp_path_join accept normal C stringswm42015-05-091-1/+1
| | | | | Instead of bstr. Most callers of this function do not need bstr. The bstr version of this function is now mp_path_join_bstr().
* x11: query ICC profile based on center of windowNiklas Haas2015-04-292-0/+7
| | | | | | | | | | Right now, the default behavior is to pick the numerically lowest screen ID that overlaps the window in any way - but this means that mpv will decide to pick an ICC profile in a pretty arbitrary way even if the window only overlaps another screen by a single pixel. The new behavior is to query it based on the center of the window instead.
* options: remove unneeded hack from command line parserwm42015-04-232-11/+1
| | | | | | | | | | | | | | | This was traditionally needed to silence terminal output from errors during command line parsing preparsing. Preparsing is done so that options controlling the terminal and config files are parsed and applied first, with a second command line parsing pass applying all other options, _and_ printing error messages for the preparsed ones. But the hack silencing log output during the preparse pass is actually not needed anymore, since the terminal is enabled only after preparsing is finished. update_logging() in main.c does this. So as long as update_logging() is called before m_config_preparse_command_line(), this will work.
* Update license headersMarcin Kurczewski2015-04-1310-46/+38
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vd_lavc: request 1 more threads than CPU coreswm42015-03-051-0/+2
| | | | | | | | | | This duplicates the logic which FFmpeg's libavcodec uses. The effects are unknown, though it's somewhat clear that a single thread doesn't necessarily saturate a single CPU. (Eventually we should just let FFmpeg auto-init the thread count, but for now I prefer it this way, so e.g. verbose mode will print the thread count.)
* player: refine rar:// playlist-safety handlingwm42015-03-021-0/+2
| | | | | | | | | | | | It was possible to make the player play local files by putting rar:// links into remote playlists, and some other potentially unsafe things. Redo the handling of it. Now the rar-redirector (the thing in demux_playlist.c) sets disable_safety, which makes the player open any playlist entries returned. This is fine, because it redirects to the same file anyway (just with different selection/interpretation of the contents). On the other hand, rar:// itself is now considered fully unsafe, which means that it is ignored if found in normal playlists.
* msg: use relaxed atomics for log level testwm42015-03-021-1/+4
| | | | | | This should be sufficient. If stdatomic.h is not available, we make no difference.
* demux: add a demux_open_url() functionwm42015-02-201-10/+7
| | | | | Often stream and a demuxer are opened at the same time. Provide a function for this and replace most of its uses.
* demux: change demux_open() signaturewm42015-02-201-1/+2
| | | | Fold the relatively obscure force_format parameter into demuxer_params.
* player: drop explicit exit() callswm42015-02-121-2/+2
| | | | | | | | | The code in main.c calls exit() explicitly, but the code is actually easier to follow by simply exiting from main() instead. The exit() call in av_log.c happens only on severely broken builds, so replace it with abort(). (Shuts up rpmlint warnings.)
* options: change --msg-level optionwm42015-02-062-34/+17
| | | | | | | | | | | | | | Make it accept "," as separator, instead of only ":". Do this by using the key-value-list parser. Before this, the option was stored as a string, with the option parser verifying that the option value as correct. Now it's stored pre-parsed, although the log levels still require separate verification and parsing-on-use to some degree (which is why the msg-level option type doesn't go away). Because the internal type changes, the client API "native" type also changes. This could be prevented with some more effort, but I don't think it's worth it - if MPV_FORMAT_STRING is used, it still works the same, just with a different separator on read accesses.
* av_common: add comment about using now-deprecated libavcodec fieldwm42015-01-301-1/+2
| | | | | | | | | | FFmpeg and Libav have the stupid practice of replacing and deprecating API symbols on the same day. So with FFmpeg git, this is useless and will print a compile time warning, while it's required with all stable releases, and might lead to decoding errors with xvid/avi (apparently). Add a comment before someone writes a patch and I have to explain it all over again.
* msg: add --log-file optionwm42015-01-261-0/+22
| | | | | | | | | This allows getting the log at all with --no-terminal and without having to retrieve log messages manually with the client API. The log level is hardcoded to -v. A higher log level would lead to too much log output (huge file sizes and latency issues due to waiting on the disk), and isn't too useful in general anyway. For debugging, the terminal can be used instead.
* video: remove vfcap.hwm42015-01-211-3/+2
| | | | | | | | | | | | | | | | | And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
* player: don't set tag strings to NULLwm42015-01-121-3/+3
| | | | | | | | | | | | | bstr is a bounded string type, consisting of a pointer and a length value. If the length is 0, the pointer can be NULL. This is somewhat logical due to how this abstraction works, but it can leak when converting to C strings. talloc_strndup() returns NULL instead of "" in this case, which broke some other code. Use bstrto0() instead, which is the "proper" function to convert bstr to char*. Fixes #1462.
* player: change --display-tags behaviorwm42015-01-121-7/+16
| | | | | | | | | | | | | | | | | | Remove the "all" special-behavior, and instead interpret trailing "*" characters. --display-tags=all is replaced by --display-tags=* as a special-case of the new behavior. See #1404. Note that the most straight-forward value for matchlen in the normal case would be INT_MAX, because it should be using the entire string. I used keylen+1 instead, because glibc seems to handle this case incorrectly: snprintf(buf, sizeof(buf), "%.*s", INT_MAX, "hello"); The result is empty, instead of just containing the string argument. This might be a glibc bug; it works with other libcs (even MinGW-w64).
* player: use libavutil API to get number of CPUswm42015-01-051-3/+2
| | | | | | | | | | | Our own code was introduced when FFmpeg didn't provide this API (or maybe didn't even have a way to determine the CPU count). But now, av_cpu_count() is available for all FFmpeg/Libav versions we support, and there's no reason to have our own code. libavutil's code seems to be slightly more sophisticated than our's, and it's possible that the detected CPU count is different on some platforms after this change.
* player: print used number of threads in verbose modewm42015-01-052-4/+6
| | | | Also, don't use av_log() for mpv output.
* command: make the "run" command work on Windows toowm42015-01-012-3/+5
| | | | | | | | | Do so by using mp_subprocess(). Although this uses completely different code on Unix too, you shouldn't notice a difference. A less ncie thing is that this reserves an entire thread while the command is running (which wastes some memory for stack, at least). But this is probably still the simplest way, and the fork() trick is apparently not implementable with posix_subprocess().
* player: filter tags, add --display-tags optionwm42014-12-292-0/+20
| | | | | | | | This attempts to increase user-friendliness by excluding useless tags. It should be especially helpful with mp4 files, because the FFmpeg mp4 demuxer adds tons of completely useless information to the metadata. Fixes #1403.
* Do not call strerror()wm42014-11-262-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | ...because everything is terrible. strerror() is not documented as having to be thread-safe by POSIX and C11. (Which is pretty much bullshit, because both mandate threads and some form of thread-local storage - so there's no excuse why implementation couldn't implement this in a thread-safe way. Especially with C11 this is ridiculous, because there is no way to use threads and convert error numbers to strings at the same time!) Since we heavily use threads now, we should avoid unsafe functions like strerror(). strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and gives the function different semantics than the POSIX one. It's a bit of work to convince this piece of shit to expose the POSIX standard function, and not the messed up GNU one. strerror_l() is also in POSIX, but only since the 2008 standard, and thus is not widespread. The solution is using avlibc (libavutil, by its official name), which handles the unportable details for us, mostly. We avoid some pain.
* Silence some Coverity warningswm42014-11-211-0/+1
| | | | None of this really matters.
* common: fix version variable declarationswm42014-11-022-2/+3
| | | | This was stupid.
* common: fix \x-style escapingshdown2014-10-161-1/+1
| | | | This was rejecting correct escapes and accepting incorrect ones.
* Add some missing "const"swm42014-10-102-2/+2
| | | | | | | The one in msg.c was mistakenly removed with commit e99a37f6. I didn't actually test the change in ao_sndio.c (but obviously "ap" shouldn't be static).
* fix -Wduplicate-decl-specifier warnings with clangStefano Pigozzi2014-10-092-4/+4
* msg: fix unwanted blank lineswm42014-10-081-1/+3
| | | | Was broken in a commit earlier this day.
* client API: introduce numeric log levelswm42014-10-082-0/+15
| | | | | | | | | | | | | | | | Maybe using strings for log levels was a mistake (too broad and too impractical), so I'm adding numeric log level at least for the receiver side. This makes it easier to map mpv log levels to other logging systems. I'm still too stingy to add a function to set the log level by a numeric value, though. The numeric values are not directly mapped to the internal mpv values, because then almost every file in mpv would have to include the client API header. Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
* msg, client API: buffer partial lineswm42014-10-081-61/+73
| | | | | | | | | | | | | | | The API could return partial lines, meaning the message could stop in the middle of a line, and the next message would have the rest of it (or just the next part of it). This was a pain for the user, so do the nasty task of buffering the lines ourselves. Now only complete lines are sent. To make things even easier for the API user, don't put multiple lines into a single event, but split them. The terminal output code needed something similar (inserting a prefix header on start of each line). To avoid code duplication, this commit refactors the terminal output so that lines are split in a single place.
* msg, client API: never send the status line as log messagewm42014-10-081-1/+1
| | | | | | | | | | | | | The status line is a bit special; for example it uses special control codes by design and is not terminated with a newline character in order to update it on the terminal without scrolling. It's not helpful for client API users either, and would require special-casing them (emulating aspects of a terminal?). Also, the status line code is explicitly disabled on osd.c unless the --terminal option is enabled, so there was no good way to even enable the status line for the API. Just pretend that the status line does not exist as far as the client API is concerned. It won't be sent as MPV_EVENT_LOG_MESSAGE.
* msg: set an explicit overflow messagewm42014-10-081-1/+1
| | | | | | | | So client API users don't have to worry about this specifically. Also document the overflow case. (Not sure if we really need to do this; maybe it'd be better not to, since this just adds more noise to the docs.)
* stream: redo playback abort handlingwm42014-09-131-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanism originates from MPlayer's way of dealing with blocking network, but it's still useful. On opening and closing, mpv waits for network synchronously, and also some obscure commands and use-cases can lead to such blocking. In these situations, the stream is asynchronously forced to stop by "interrupting" it. The old design interrupting I/O was a bit broken: polling with a callback, instead of actively interrupting it. Change the direction of this. There is no callback anymore, and the player calls mp_cancel_trigger() to force the stream to return. libavformat (via stream_lavf.c) has the old broken design, and fixing it would require fixing libavformat, which won't happen so quickly. So we have to keep that part. But everything above the stream layer is prepared for a better design, and more sophisticated methods than mp_cancel_test() could be easily introduced. There's still one problem: commands are still run in the central playback loop, which we assume can block on I/O in the worst case. That's not a problem yet, because we simply mark some commands as being able to stop playback of the current file ("quit" etc.), so input.c could abort playback as soon as such a command is queued. But there are also commands abort playback only conditionally, and the logic for that is in the playback core and thus "unreachable". For example, "playlist_next" aborts playback only if there's a next file. We don't want it to always abort playback. As a quite ugly hack, abort playback only if at least 2 abort commands are queued - this pretty much happens only if the core is frozen and doesn't react to input.
* player: deal with some corner cases with playlist navigationwm42014-09-092-1/+16
| | | | | | | | | | | | | | | The purpose is making accessing the current playlist entry saner when commands are executed during initialization, termination, or after playlist navigation commands. For example, the "playlist_remove current" command will invalidate playlist->current - but some things still access the playlist entry even on uninit. Until now, checking stop_play implicitly took care of it, so it worked, but it was still messy. Introduce the mpctx->playing field, which points to the current playlist entry, even if the entry was removed and/or the playlist's current entry was moved (e.g. due to playlist navigation).
* player: normalize playlist entries on addwm42014-09-091-1/+2
| | | | This is not necessarily more correct, but it's less trouble.
* player: don't allow remote playlists to load local fileswm42014-09-011-3/+6
| | | | | | | | Because that might be a bad idea. Note that remote playlists still can use any protocol marked with is_safe and is_network, because the case of http-hosted playlists containing URLs using other streaming protocols is not unusual.
* playlist: don't add the base path twicewm42014-09-011-3/+0
| | | | | | | | | | | | Loading a playlist with --playlist from a sub-directory added the playlist's base path twice: one time in the playlist demuxer, and then again in playlist_parse_file(). The latter function is used only for --playlist, so it worked when loading the playlist directly. (This is probably a mess-up when the MPlayer playlist parsers were replaced with newer code.) CC: @mpv-player/stable
* player: always load playlistswm42014-08-311-0/+3
| | | | | | | | | Until now, you had to use --load-unsafe-playlists or --playlist to get playlists loaded. Change this and always load playlists by default. This still attempts to reject unsafe URLs. For example, trying to invoke libavdevice pseudo-demuxer is explicitly prevented. Local paths and any http links (and some more) are always allowed.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-298-9/+9
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* posix: use STD*_FILENO constantsBen Boeckel2014-08-281-2/+2
| | | | | Rather than "magic" numbers, use meaningful constant names provided by unistd.h.
* msg: allow duplicating a mp_logwm42014-08-251-15/+20
| | | | Trivial; this is mostly just reindenting the normal codepath.
* demux: always use AVPacketwm42014-08-251-0/+2
| | | | | | | | | | | | | | | | | | | | | This is a simplification, because it lets us use the AVPacket functions, instead of handling the details manually. It also allows the libavcodec rawvideo decoder to use reference counting, so it doesn't have to memcpy() the full image data. The change in av_common.c enables this. This change is somewhat risky, because we rely on the following AVPacket implementation details and assumptions: - av_packet_ref() doesn't access the input padding, and just copies the data. By the API, AVPacket is always padded, and we violate this. The lavc implementation would have to go out of its way to make this a real problem, though. - We hope that the way we make the AVPacket refcountable in av_common.c is actually supported API-usage. It's hard to tell whether it is. Of course we still use our own "old" demux_packet struct, just so that libav* API usage is somewhat isolated.
* win32: emulate some ANSI terminal escape codeswm42014-08-211-12/+16
| | | | | | | | | | | | | | We already redirect all terminal output through our own wrappers (for the sake of UTF-8), so we might as well use it to handle ANSI escape codes. This also changes behavior on UNIX: we don't retrieve some escape codes per terminfo anymore, and just hardcode them. Every terminal should understand them. The advantage is that we can pretend to have a real terminal in the normal player code, and Windows atrocities are locked away in glue code.
* Improve setting AVOptionswm42014-08-024-85/+39
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* Remove the last remains of slave modewm42014-08-011-1/+1
| | | | | | | | | | | Almost nothing was left of it. The only thing this commit actually removes is support for reading input commands from stdin. But you can emulate this via: --input-file=/dev/stdin --input-terminal=no However, this won't work on Windows. Just use a named pipe.
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-302-0/+11
| | | | | This commit also creates a private option struct for stream_lavf.c, but since I'm lazy, I'm not moving any existing options to it.
* command: append entries to the end of the playlist with loadlist appendAlessandro Ghedini2014-07-252-0/+10
| | | | | | Currently entries are added after the current playlist element. This is kinda confusing, more so given that "loadfile append" appends at the end of the playlist.
* encode: deal with codec->time_base deprecationwm42014-07-221-5/+4
| | | | This seems to work with both Libav 10 and FFmpeg d3e51b41.
* tags: add copy functionwm42014-07-162-0/+14
* build: allow compilation without any atomicswm42014-07-051-0/+4
| | | | | | | | | | | | | | | | | | | Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
* demux, stream: change metadata notificationwm42014-07-052-0/+7
| | | | | | | | | | | | (Again.) This time, we simply make it event-based, as it should be. This is done for both demuxer metadata and stream metadata. For some ogg-over-icy streams, 2 updates are reported on stream start. This is because libavformat reports an update right on start, while including the same info in the "static" metadata. I don't know if that's a bug or a feature.
* av_common: remove unneeded fieldwm42014-06-291-1/+0
| | | | This is actually needed for encoding only, and not decoding. Drop it.
* Revert "encode: make the central lock recursive"Rudolf Polzer2014-06-121-2/+1
| | | | This reverts commit 231c6672140f019257edd26db20fbcfc2554258f.
* encode: make the central lock recursivewm42014-06-121-1/+2
| | | | | | | | Unfortunately, there's a recursive function call in ao_lavc.c (play function), leading to a deadlock. The locking is getting a bit messy, so just make the lock recursive. This fixes #844.
* encode: make option struct localwm42014-06-113-6/+58
| | | | Similar to previous commits.
* Add more constwm42014-06-113-4/+4
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* client API: call wakeup callback if there are new messageswm42014-06-062-2/+12
| | | | | | | | | | | | | | | | | | Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
* playlist: fix playlist_move on itselfwm42014-05-251-1/+4
| | | | | | | A playlist_move command that moves an entry onto itself (both arguments have the same index) should do nothing, but it did something broken. The underlying reason is that it checks the prev pointer of the entry which is temporarily removed for moving.
* atomics: switch to C11 stdatomic.hwm42014-05-211-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* encoding: No error when the output format doesn't support a stream type at all.Rudolf Polzer2014-05-161-8/+20
| | | | | | | | When writing a video to foo.mp3, the user's intention is clearly to drop the video stream, and similarly, when writing to foo-%d.png, the intention is clearly to drop the audio stream. Now, explicit specification of --no-audio or --no-video is no longer necessary in these cases.
* common: change MP_NOPTS_VALUE definitionwm42014-05-101-2/+2
| | | | | | | | | Use the exact floating point value, instead of a broken integer constant. The expression calculating the constant probably relied on undefined behavior, because it left-shifts a negative value. This also changes the type of the constant to double, which is perfectly fine, and maybe better than an integer constant.
* common: change mp_snprintf_append semanticswm42014-05-052-5/+12
| | | | | | | | Make it more suitable for chaining. This means a function formatting a value to a string using a static buffer can work exactly like mp_snprintf_append itself. Also rename it to mp_snprintf_cat, because that's shorter.
* options: remove deprecated --identifyMartin Herkt2014-05-042-11/+4
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* common: add mp_snprintf_append() utility functionwm42014-04-292-0/+23
* stream: remove interrupt callback global variableswm42014-04-251-0/+3
| | | | | | | | | | | | This used global variables for the asynchronous interrupt callback. Pick the simple and dumb solution and stuff the callback into mpv_global. Do this because interrupt checking should also work in the connect phase, and currently stream creation equates connecting. Ideally, this would be passed to the stream on creation instead, or connecting would be separated from creation. But since I don't know yet which is better, and since moving stream/demuxer into their own thread is something that will happen later, go with the mpv_global solution.
* terminal: fix printing of prefixwm42014-04-231-2/+3
| | | | This was subtly change in 5cfb18. Revert the change.
* Remove CPU detection and inline asm handlingwm42014-04-192-83/+0
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* player: add a --dump-stats optionwm42014-04-173-2/+48
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
* msg: correct ringbuffer log level comparisonFRAU KOUJIRO2014-04-171-1/+1
* New option --no-ometadata to opt out of including metadata when encoding.Rudolf Polzer2014-04-141-1/+2
| | | | | | | This re-allows the previous behaviour of being able to reencode with metadata removed, which is useful when encoding "inconsistently" tagged data for a device/player that shows file names when tags are not present.
* mp_tags: move generic mp_tags stuff into its own .c/.h files in common/Kevin Mitchell2014-04-132-0/+91
| | | | | | rename add_metadata to the more genera/descriptive mp_tags_copy_items_from_av_dictionary Signed-off-by: wm4 <wm4@nowhere>
* player: remove ASX, SMIL and NSC playlist parserswm42014-04-136-1178/+44
| | | | | | | | | | | | | | | | | | | These playlist parsers are all what's left from the old mplayer playlist parsing code. All of it is old code that does little error checking; the type of C string parsing code that gives you nightmare. Some playlist parsers have been rewritten and are located in demux_playlist.c. The removed formats were not reimplemented. ASX and SMIL use XML, and since we don't want to depend on a full blown XML parser, this is not so easy. Possibly these formats could be supported by writing a very primitive XML-like lexer, which would lead to success with most real world files, but I haven't attempted that. As for NSC, I couldn't find any URL that worked with MPlayer, and in general this formats seems to be more than dead. Move playlist_parse_file() to playlist.c. It's pretty small now, and basically just opens a stream and a demuxer. No use keeping playlist_parser.c just for this.
* terminal: pretty print modules for --msgmoduleEvan Purkhiser2014-04-121-2/+26
* encode_lavc: copy metadata to output fileAlessandro Ghedini2014-03-303-1/+20
| | | | | | | | Closes #684 Signed-off-by: wm4 <wm4@nowhere> Includes some minor cosmetic changes additional to the original PR.
* encode: add lockingwm42014-03-092-4/+43
| | | | | | | | | | Since the AO will run in a thread, and there's lots of shared state with encoding, we have to add locking. One case this doesn't handle correctly are the encode_lavc_available() calls in ao_lavc.c and vo_lavc.c. They don't do much (and usually only to protect against doing --ao=lavc with normal playback), and changing it would be a bit messy. So just leave them.
* encode: don't access ao->ptswm42014-03-073-0/+12
| | | | | | | | | | This field will be moved out of the ao struct. The encoding code was basically using an invalid way of accessing this field. Since the AO will be moved into its own thread too and will do its own buffering, the AO and the playback core might not even agree which sample a PTS timestamp belongs to. Add some extrapolation code to handle this case.
* common: add some helper macroswm42014-03-071-0/+3
* msg: add --msgtime option to add timestamps to each output messagewm42014-02-281-2/+9
| | | | | | | Will be helpful to track down strange wait times and such issues, as well when you have develop something timing related. (Then you may print timestamps in your debug output, and the --msgtime timestamps will help giving context.)
* av_log: add tons of warnings against mismatched ffmpeg/libav librarieswm42014-02-101-0/+22
| | | | | | | | | | | | | Print a warning if a library has mismatched compile time and link time versions. Refuse to work if the compile time and link time versions are a mix of ffmpeg and libav. We print an error message and call exit(). Since we'd randomly crash anyway, I think this is ok. This doesn't catch the case if you e.g. use a ffmpeg libavcodec and a libav libavformat, which would of course just crash as quickly, but I think this checks enough already.
* av_log: restructure version printing codewm42014-02-101-18/+28
| | | | Makes the following commit simpler.
* options: add --no-terminal switchwm42014-02-101-13/+21
| | | | | Mostly useful for internal reasons. This code will be enabled by default if mpv is started via the client API.
* msg: clear lines by printing spaces on MS Windowswm42014-02-091-1/+7
| | | | | | | | | | | | | | | On Windows, no ANSI control sequences are available, so we can't easily clear lines, move the cursor, etc. It's yet to be decided how this should be handled (emulate ANSI escapes in osdep/terminal-win.c, or provide abstracted terminal API functions to unify the Linux and Windows code). For now, this fixes the regression that was introduced earlier by the status line rewrite. It doesn't fix all aspects of status line and terminal OSD handling, as can be clearly seen by the unconditional use of terminal_erase_to_end_of_line further down the changed code. Fixes github issue #499 (sort of).
* msg: don't clear the status line if new and previous status was emptywm42014-01-291-0/+3
| | | | | | | | | | | | | This avoids stray newlines when: 1. Some (non-status line) text was output 2. Then an empty status line is output According to the logic, 2. should print an empty line to show the blank status line. Don't do that, and instead output nothing in this case. This caused problems with, and also looked ugly when using --quiet.
* playlist_parser: restore ASX parsing etc.wm42014-01-201-8/+8
| | | | | | This was broken yesterday: the playlist demuxer will always fall back to plaintext playlist files, which will cause the ASX playlist parser and some others never to be called.
* demux_playlist: move parser for plaintext playlistswm42014-01-191-20/+0
| | | | | This was implemented in playlist_parser.c. To make it use the improved implementation of stream_read_line(), move it to demux_playlist.c.
* msg: expose log level nameswm42014-01-163-3/+7
* msg: add a mechanism to output messages to a ringbufferwm42014-01-162-18/+152
| | | | | | | | | | | | | | | | | | | | | | | | | Until now, mp_msg output always went to the terminal. There was no way to grab the stream of output messages. But this will be needed by various future changes: Lua scripts, slave mode, client library... This commit allows registering a ring buffer. A callback would be more straight-forward, but since msg.c sits at the bottom of the lock hierarchy (it's used by virtually everything), this would probably be a nightmare. A ring buffer will be simpler and more predictable in the long run. We allocate new memory for each ringbuffer entry, which is probably a bit expensive. We could try to be clever and somehow pack the data directly into the buffer, but I felt like this wouldn't be worth the complexity. You'd have to copy the data a bunch of times anyway. I'm hoping that we can get away with using the ringbuffer mechanism for low frequency important messages only (and not e.g. for high volume debug messages), so the cost doesn't matter that much. A ringbuffer has a simple, single log level. I considered allowing --msglevel style per-prefix configuration for each ringbuffer, but that would have been pretty complicated to implement, and wouldn't have been that useful either.
* msg: fix typo in commentwm42014-01-161-1/+1
* msg: move special declarations to msg_control.hwm42014-01-164-13/+21
| | | | | While almost everything uses msg.h, the moved definitions are rarely needed by anything.
* msg: print module prefixes even if message contains newlineswm42014-01-161-12/+23
| | | | | | | | | | | | | | This makes mp_msg(x, y, "a\nb\n") behave the same as mp_msg(x, y, "a\n") mp_msg(x, y, "b\n") which is probably what one would expect. Before this commit, the "b" line didn't have a prefix when using ths single mp_msg call.
* msg: update commentwm42014-01-151-1/+1
* msg: terminal OSD uses stderr, not stdoutwm42014-01-151-1/+1
| | | | | | This is more correct. E.g. if you do "mpv file.mkv > /dev/null", stdout will not be a terminal, but stderr (used by terminal OSD and status line) is.
* msg: don't clear term OSD lines that are not usedwm42014-01-141-3/+5
* msg: fix printing of module headerwm42014-01-141-1/+2
| | | | | The code to set root->header was moved before the point where it's used, which broke the logic.
* player: redo terminal OSD and status line handlingwm42014-01-132-14/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The terminal OSD code includes the handling of the terminal status line, showing player OSD messages on the terminal, and showing subtitles on terminal (the latter two only if there is no video window, or if terminal OSD is forced). This didn't handle some corner cases correctly. For example, showing an OSD message on the terminal always cleared the previous line, even if the line was an important message (or even just the command prompt, if most other messages were silenced). Attempt to handle this correctly by keeping track of how many lines the terminal OSD currently consists of. Since there could be race conditions with other messages being printed, implement this in msg.c. Now msg.c expects that MSGL_STATUS messages rewrite the status line, so the caller is forced to use a single mp_msg() call to set the status line. Instead of littering print_status() all over the place, update the status only once per playloop iteration in update_osd_msg(). In audio- only mode, the status line might now be a little bit off, but it's perhaps ok. Print the status line only if it has changed, or if another message was printed. This might help with extremely slow terminals, although in audio+video mode, it'll still be updated very often (A-V sync display changes on every frame). Instead of hardcoding the terminal sequences, use terminfo/termcap to get the sequences. Remove the --term-osd-esc option, which allowed to override the hardcoded escapes - it's useless now. The fallback for terminals with no escape sequences for moving the cursor and clearing a line is removed. This somewhat breaks status line display on these terminals, including the MS Windows console: instead of querying the terminal size and clearing the line manually by padding the output with spaces, the line is simply not cleared. I don't expect this to be a problem on UNIX, and on MS Windows we could emulate escape sequences. Note that terminal OSD (other than the status line) was broken anyway on these terminals. In osd.c, the function get_term_width() is not used anymore, so remove it. To remind us that the MS Windows console apparently adds a line break when writint the last column, adjust screen_width in terminal- win.c accordingly.
* Factor out setting AVCodecContext extradatawm42014-01-112-10/+15
* common: drop mp_append_utf8_buffer()wm42013-12-302-13/+2
* common: simplify and optimize string escape parsingwm42013-12-302-5/+76
| | | | | | | | | | | This code is shared between input.conf parser and option parser. Until now, the performance didn't really matter. But I want to use this code for JSON parsing too, and since JSON will have to be parsed a lot, it should probably try to avoid realloc'ing too much. This commit moves parsing of C-style escaped strings into a common function, and allows using it in a way realloc can be completely avoided, if the already allocated buffer is large enough.
* asxparser: remove commented codewm42013-12-221-12/+0
* Don't include version.h from make options.cwm42013-12-222-4/+4
| | | | | | | | | I find this annoying. It's the reason common/version.c exists at all. options.c did this for the user agent, which contains the version number. Because not including version.h means you can't build the user agent and use it in mp_default_opts anymore, do something rather awkward in main.c to initialize the default user agent.
* msg: add some comments about thread-safetywm42013-12-221-0/+6
* msg: remove global statewm42013-12-213-59/+58
* msg: don't prefix slave-mode stuff by defaultwm42013-12-211-1/+1
* msg: rename mp_msg_log -> mp_msgwm42013-12-216-31/+31
| | | | Same for companion functions.
* msg: convert defines to enumwm42013-12-213-26/+27
| | | | Also get rid of MSGL_HINT and the many MSGL_DBG* levels.
* msg: remove legacy stuffwm42013-12-212-142/+3
* cpudetect: remove mp_msg callswm42013-12-211-13/+0
| | | | Worthless anyway.
* stream: mp_msg conversionswm42013-12-212-6/+5
| | | | We also drop some slave mode stuff from stream_vcd.
* demux: mp_msg conversionswm42013-12-211-1/+1
| | | | | | | The TV code pretends to be part of stream/, but it's actually demuxer code too. The audio_in code is shared between the TV code and stream_radio.c, so stream_radio.c needs a small hack until stream.c is converted.
* playlist_parser: mp_msg conversionwm42013-12-214-72/+79
* encode_lavc: mp_msg conversionswm42013-12-213-109/+101
| | | | Miss two mp_msg calls, because these conflict with future commits.
* av_log: mp_msg conversionwm42013-12-212-32/+71
| | | | | | | | This is pretty nasty, because FFmpeg/Libav is yet another library with a global message callback. We do something with mutexes trying to get it done, but of course we can't actually solve this problem. If more than one library in a process use FFmpeg/Libav, only one of them will get log messages.
* m_option, m_config: mp_msg conversionswm42013-12-212-14/+16
| | | | | | | | Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
* codecs: avoid having to print error messagewm42013-12-211-3/+2
| | | | | | | | | The mp_select_decoders() function doesn't have a log context (and I don't want to give it one), so get rid of the mp_msg error message by enhancing the semantics such that the syntax error is replaced by a new feature. Now doing "--ad=something" will enable all decoders in the "something" module, same as "--ad=something:*". Pretty useless, but gets rid of the annoyance.
* codecs: mp_msg conversionwm42013-12-212-7/+8
* av_common: abuse av_log to print message instead of mp_msgwm42013-12-211-1/+2
| | | | Saves a little bit of pain.
* msg: handle vsnprintf errorswm42013-12-201-1/+2
| | | | | | | I don't know under which circumstances this can error (other than a broken format string). It seems it won't return an error code on I/O errors, so maybe broken format strings are the only case. Either way, don't continue if an error is returned.
* msg: use a global lock to synchronize printingwm42013-12-201-4/+7
| | | | | | | | | | | | | | We have certain race conditions coming from doing multiple fprintf() calls (setting up colors etc.). I'm not sure whether it would be worth changing to code such that we do only one fprintf() call (and assume this synchronizes access), but considering it would be hard to do (Windows compatibility, ...), and that stdio uses per FILE locks anyway, this is simpler and probably not less efficient. Also, there's no problem handling the weird statusline special case this way. Note that mp_msg_* calls which are silent won't acquire the lock, and acquiring the lock happens on actual output only (which is slow and serialized anyway).
* msg: change --msglevel, reduce legacy gluewm42013-12-202-26/+123
| | | | | | | | | | | | Basically, reimplement --msglevel. Instead of making the new msg code use the legacy code, make the legacy code use the reimplemented functionality. The handling of the deprecated --identify switch changes. It temporarily stops working; this will be fixed in later commits. The actual sub-options syntax (like --msglevel-vo=...) goes away, but I bet nobody knew about this or used this anyway.
* msg: cosmetic changeswm42013-12-202-124/+87
| | | | | In particular, condense the legacy MSGT_ defines and move them to the end of the file.
* msg: change hack to silence command line pre-parse error messageswm42013-12-202-1/+4
| | | | mp_msg_levels[] will go away.
* terminal: remove separate formatting for --msgmodulewm42013-12-201-4/+1
| | | | Instead, --msgmodule uses the same formatting as -v.
* terminal: abstract terminal color handlingwm42013-12-201-95/+5
| | | | | | | | Instead of making msg.c an ifdef hell for unix vs. windows code, move the code to separate functions defined in terminal-unix.c/terminal- win.c. Drop the code that selects random colors for --msgmodule prefixes.
* terminal: move SIGTTOU signal handler setup codewm42013-12-191-7/+0
| | | | | | This comes with a real change in behavior: now the signal handler is set only when the terminal input code is active (e.g. not with --no-consolecontrols), but this should be ok.
* Rename getch2....c/h to terminal....c/hwm42013-12-191-1/+1
| | | | | "getch2" really tells nothing about what the heck this code does. It'd be even worse when moving the rest of terminal handling code there.
* Reduce recursive config.h inclusions in headerswm42013-12-181-3/+4
| | | | | | In my opinion, config.h inclusions should be kept to a minimum. MPlayer code really liked including config.h everywhere, though, even in often used header files. Try to reduce this.
* Remove the _ macrowm42013-12-182-7/+4
| | | | | This was a gettext-style macro to mark strings that should be translated.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-1725-0/+4380