summaryrefslogtreecommitdiffstats
path: root/video/out/vo_lavc.c
Commit message (Collapse)AuthorAgeFilesLines
* encode_lavc: move from GPL 2+ to LGPL 2.1+.Rudolf Polzer2017-06-131-7/+7
|
* Remove compatibility thingswm42016-12-071-19/+0
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-2/+2
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* ao_lavc, vo_lavc: Migrate to new encoding API.Rudolf Polzer2016-06-271-87/+102
| | | | | Also marked some places for possible later refactoring, as they became quite similar in this commit.
* vo_lavc: fix build on Libavwm42016-04-151-2/+1
| | | | | OF COURSE Libav doesn't have AV_PICTURE_TYPE_NONE. Why the fuck would it?
* vo_lavc: unsupport deprecated AVFMT_RAWPICTUREwm42016-04-151-23/+12
| | | | | | | | As of ffmpeg git master, only the libavdevice decklink wrapper supports this. Everything else has dropped support. You're now supposed to use AV_CODEC_ID_WRAPPED_AVFRAME, which works a bit differently. Normal AVFrames should still work for these encoders.
* vo_lavc: send refcounted AVFrame to encoderwm42016-04-151-4/+4
| | | | | | This potentially makes it more efficient, and actually makes it simpler. Yes, AV_PICTURE_TYPE_NONE is the default for pict_type.
* encode_lavc: Migrate to codecpar API.Rudolf Polzer2016-04-111-31/+35
|
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* video: switch from using display aspect to sample aspectwm42015-12-191-8/+1
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* video/out: remove an unused parameterwm42015-10-031-1/+1
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* Update license headersMarcin Kurczewski2015-04-131-4/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video/out: remove unused colorspace reportingwm42015-03-311-18/+1
| | | | | | | | Rarely used and essentially useless. The only VO for which this was implemented correctly and for which this did anything was vo_xv, but you shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor specific extension for BT.709, whose presence this function essentially reported - use xvinfo 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).
* ao_lavc, vo_lavc: Fix crashes in case of multiple init attempts.Rudolf Polzer2014-11-121-6/+16
| | | | | | | | | | | | When initialization failed, vo_lavc may cause an irrecoverable state in the ffmpeg-related structs. Therefore, we reject additional initialization attempts at least until we know a better way to clean up the mess. ao_lavc currently cannot be initialized more than once, yet it's good to do consistent changes there as well. Also, clean up uninit-after-failure handling to be less spammy.
* encode: don't segfault when bailing out due to resolution changewm42014-11-111-1/+1
| | | | Somehow this code expects lastimg is always set.
* vo_vdpau: better integration with the generic framedrop codewm42014-09-201-2/+2
| | | | | | | | | | | | | | | | | | | | vo_vdpau uses its own framedrop code, mostly for historic reasons. It has some tricky heuristics, of which I'm not sure how they work, or if they have any effect at all, but in any case, I want to keep this code for now. One day it might get fully ported to the vo.c framedrop code, or just removed. But improve its interaction with the user-visible framedrop controls. Make --framedrop actually enable and disable the vo_vdpau framedrop code, and increment the number of dropped frames correctly. The code path for other VOs should be equivalent. The vo_vdpau behavior should, except for the improvements mentioned above, be mostly equivalent as well. One minor change is that frames "shown" during preemption are always count as dropped. Remove the statement from the manpage that vo_vdpau is the default; this hasn't been the case for a while.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+0
| | | | | | | | | 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.
* video: move display and timing to a separate threadwm42014-08-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* vo: make draw_image and vo_queue_image transfer image ownershipwm42014-06-171-12/+15
| | | | Basically a cosmetic change. This is probably more intuitive.
* video: introduce failure path for image allocationswm42014-06-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* video/out: change aspects of OSD handlingwm42014-06-151-16/+6
| | | | | | | | | Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
* encode: fix PTS unit mismatchwm42014-05-101-6/+6
| | | | | | This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS values. This probably happened to work, because both constants use the same value.
* vo_lavc: remove code with no effectwm42014-04-301-1/+0
| | | | This field will also removed in the future.
* encode: write 2-pass stats only per-packetwm42014-04-111-1/+2
| | | | | | The stats were retrieved and written on every encode call, instead of every encode call that actually returned a packet. ffmpeg.c also does it this way, so it must be "more correct". Fixes 2-pass encoding.
* video/out: remove legacy colorspace stuffwm42014-03-291-20/+9
| | | | | | | | | Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
* encode: use new AVFrame APIwm42014-03-161-5/+3
|
* encode: add lockingwm42014-03-091-16/+37
| | | | | | | | | | 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.
* video/out: do remaining config to reconfig replacementswm42014-01-241-8/+8
| | | | | | | The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
* video/out: don't access aspdat in VOswm42014-01-221-10/+2
| | | | | | | | | | | vo->aspdat is basically an outdated version of vo->params, plus some weirdness. Get rid of it, which will allow further cleanups and which will make multithreading easier (less state to care about). Also, simplify some VO code by using mp_image_set_attributes() instead of caring about display size, colorspace, etc. manually. Add the function osd_res_from_image_params(), which is often needed in the case OSD renders into an image.
* sub: uglify OSD code path with lockingwm42014-01-181-1/+2
| | | | | | | | | | | | | | | Do two things: 1. add locking to struct osd_state 2. make struct osd_state opaque While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses lots of osd_state (and osd_object) members. To make sure everything is accessed synchronously, I prefer making osd_state opaque, even if it means adding pretty dumb accessors. All of this is meant to allow running VO in their own threads. Eventually, VOs will request OSD on their own, which means osd_state will be accessed from foreign threads.
* video/fmt-conversion.c: remove unknown pixel format messageswm42013-12-211-2/+5
| | | | | | | | | | | This removes the messages printed on unknown pixel format messages. Passing a mp_log to them would be too messy. Actually, this is a good change, because in the past we often had trouble with these messages printed too often (causing terminal spam etc.), and printing warnings or error messages on the caller sides is much cleaner. vd_lavc.c had a change earlier to print an error message if a decoder outputs an unsupported pixel format.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-291-3/+3
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* osd: remove mp_osd_res.video_par fieldwm42013-11-241-1/+0
| | | | | | This is not needed anymore, because we decided that the PAR of the decoded video matters, and not the PAR of the filtered video that arrives at the VO.
* Rename sub.c/.h to osd.c/.hwm42013-11-241-2/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* vo_lavc: fix -ovoffset.Rudolf Polzer2013-11-111-1/+3
| | | | Previously, using it led to no single frame being output, ever.
* video/out: remove useless info struct and redundant fieldswm42013-10-231-6/+2
| | | | The author and comment fields were printed only in -v mode.
* vo_lavc: mp_msg conversionwm42013-09-201-34/+27
| | | | Also restores consistent log message prefixes with ao_lavc.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* video/out: remove options argument from preinit()wm42013-07-221-1/+1
| | | | | All VOs use proper option parsing now, and compatibility hacks are not needed.
* Remove subopt-helperwm42013-07-221-1/+0
| | | | Finally not used by anything anymore. Farewell.
* vo_lavc: remove unused variablewm42013-06-181-1/+1
|
* vo_lavc: do NOT fill pict_type from the mp_imageRudolf Polzer2013-06-171-0/+4
| | | | | | | | Doing this makes the encoder force the same pict type as original, which is often not even possible. Rather let the codec decide! As there is no documented value to mean "decoder shall pick", I rather save/restore the default value filled by libavcodec.
* vo_lavc: use mp_image_copy_fields_to_av_frameRudolf Polzer2013-06-171-4/+1
|
* encode_lavc strings: use new option syntaxRudolf Polzer2013-06-161-2/+2
|
* vo_lavc: silence warning when writing y4mwm42013-06-131-1/+1
| | | | | Apparently a ffmpeg issue. Hide the warning because it's annoying. Workaround suggested by divVerent.
* encoding: fix -oneverdrop logic when -omaxfps is usedRudolf Polzer2013-06-091-5/+8
| | | | Not that anyone should ever do this...
* encoding -omaxfps: rewrite logicRudolf Polzer2013-06-091-29/+32
| | | | | | Now it properly hits the "0 times displayed" case when frames get skipped; this means the candidate frame for the case the next frame is "long" is set properly.
* encoding -omaxfps: do not shift pts when pts are repeated entirelyRudolf Polzer2013-06-091-1/+1
| | | | | This is just to make sure. I have no test case for this, but the logic seems saner that way.
* Option -omaxfps: limit fps when encodingRudolf Polzer2013-06-091-0/+16
| | | | | Lower-fps content is left alone (NOT aligned to this fps); higher fps content is decimated to this frame rate.
* Replace all calls to GetTimer()/GetTimerMS()wm42013-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
* vo: remove vo.check_events callbackwm42013-05-261-5/+0
| | | | | | Use VOCTRL_CHECK_EVENTS instead. Change the remaining VOs to use it. Only vo_sdl and vo_caca actually need this, and vo_null, vo_lavc, and vo_image had stubs only.
* core: simplify OSD capability handling, remove VFCAP_OSDwm42013-03-011-3/+1
| | | | | | | | | | | | | | | | | | | VFCAP_OSD was used to determine at runtime whether the VO supports OSD rendering. This was mostly unused. vo_direct3d had an option to disable OSD (was supposed to allow to force auto-insertion of vf_ass, but we removed that anyway). vo_opengl_old could disable OSD rendering when a very old OpenGL version was detected, and had an option to explicitly disable it as well. Remove VFCAP_OSD from everything (and some associated logic). Now the vo_driver.draw_osd callback can be set to NULL to indicate missing OSD support (important so that vo_null etc. don't single-step on OSD redraw), and if OSD support depends on runtime support, the VO's draw_osd should just do nothing if OSD is not available. Also, do not access vo->want_redraw directly. Change the want_redraw reset logic for this purpose, too. (Probably unneeded, vo_flip_page resets it already.)
* audio/out, video/out: hide encoding VO/AOwm42013-02-061-0/+1
| | | | | | mpv -ao help and mpv -vo help shouldn't show the encoding outputs (named "lavc" on both cases). Also make it impossible to select these manually when not encoding.
* sub: do not copy the target image if there is no OSD/subswm42013-01-131-1/+0
| | | | | | | | | | | | | | | | | | | | | It's not easy to tell whether the OSD/subs are empty, or if something is drawn. In general you have to use osd_draw() with a custom callback. If nothing is visible, the callback is never invoked. (The actual reason why this is so "hard" is the implementation of osd_libass.c, which doesn't allow separating rendering and drawing of OSD elements, because all OSD elements share the same ASS_Renderer.) To simplify avoiding copies, make osd_draw_on_image() instead of the caller use mp_image_make_writeable(). Introduce osd_draw_on_image_p(), which works like osd_draw_on_image(), but gets the new image allocation from an image pool. This is supposed to be an optimization, because it reduces the frequency of large allocations/deallocations for image data. The result of this is that the frequency of copies needed in conjunction with vf_sub, screenshots, and vo_lavc (encoding) should be reduced. vf_sub now always does true pass-through if no subs are shown. Drop the pts check from vf_sub. This didn't make much sense.
* vo_lavc: use reference countingwm42013-01-131-17/+4
|