summaryrefslogtreecommitdiffstats
path: root/common/av_common.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: use no overlapping packets for lossless audiowm42019-09-191-0/+7
| | | | | | Worthless optimization, but at least it justifies that the --audio-backward-overlap option has an "auto" choice. Tested with PCM and FLAC.
* f_lavfi: support setting common filter options like "threads"wm42018-04-291-2/+9
| | | | | | | | | AVFilterContext instances support some additional AVOptions over the actual filter. This includes useful options like "threads". We didn't support setting those for the "direct" wrapper (--vf=yadif:threads=1 failed). Change this. It requires setting options on the AVFilterContext directly, except the code for positional parameters still needs to access the actual filter's AVOptions.
* av_common: cosmetic simplification to ffmpeg component iteration loopswm42018-04-031-4/+2
|
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-031-48/+0
| | | | This is new, thus a dependency bump is required.
* Fix recent FFmpeg deprecationswm42018-02-131-16/+17
| | | | | | | | | 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-011-2/+2
| | | | | | | | | | 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.
* command: add demuxer-lavf-list propertyRicardo Constantino2018-01-021-0/+17
| | | | | | | | | 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.
* 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).
* av_common: fix Libav buildwm42017-10-161-0/+13
| | | | Fucking shit.
* video: properly pass through ICC datawm42017-10-161-0/+35
| | | | | | | | | | | | | | | | | | 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.
* 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.
* 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.
* Use AV_INPUT_BUFFER_PADDING_SIZE instead of deprecated onewang-bin2017-02-081-2/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* 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-251-5/+67
| | | | | | | | 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-241-23/+0
| | | | Unused since the AVCodecParameters change.
* Remove compatibility thingswm42016-12-071-5/+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.)
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-191-0/+25
| | | | | | | | | | | | | | | | | | | 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
|
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-311-0/+16
| | | | | | | | | 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.
* 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.
* command: add encoder-list propertywm42016-03-011-0/+15
| | | | | Also change decoder-list (for the sake of sharing the underlying code for both properties).
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* 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.)
* 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.)
* 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.
* 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-051-3/+5
| | | | Also, don't use av_log() for mpv output.
* 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.
* Improve setting AVOptionswm42014-08-021-0/+36
| | | | | | | | 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).
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-301-0/+9
| | | | | 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.
* av_common: remove unneeded fieldwm42014-06-291-1/+0
| | | | This is actually needed for encoding only, and not decoding. Drop it.
* Factor out setting AVCodecContext extradatawm42014-01-111-10/+14
|
* av_common: abuse av_log to print message instead of mp_msgwm42013-12-211-1/+2
| | | | Saves a little bit of pain.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-0/+178