summaryrefslogtreecommitdiffstats
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* 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 L