summaryrefslogtreecommitdiffstats
path: root/video/out/vo_corevideo.c
Commit message (Collapse)AuthorAgeFilesLines
* vo: make draw_image and vo_queue_image transfer image ownershipwm42014-06-171-0/+1
| | | | Basically a cosmetic change. This is probably more intuitive.
* video: introduce failure path for image allocationswm42014-06-171-1/+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-12/+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.
* video/out: remove unused config() parameterswm42014-05-071-2/+1
| | | | This was cleaned up yesterday.
* vo_corevideo: remove unused variableStefano Pigozzi2014-03-311-1/+0
|
* Fix compilation on OSX and win32wm42014-03-291-1/+0
| | | | Probably.
* video/out: remove legacy colorspace stuffwm42014-03-291-33/+16
| | | | | | | | | 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.
* vo_corevideo: remove unused variableStefano Pigozzi2014-02-171-1/+0
|
* video/out: don't access aspdat in VOswm42014-01-221-3/+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.
* vda: fix build on OS X 10.7Stefano Pigozzi2014-01-021-0/+1
| | | | | Looks like on 10.8 OpenGL.h recursively includes CGLIOSurface.h. That is not the case for 10.7 so the build was broken on that version of OS X.
* corevideo: fix video initialization when not using VDAStefano Pigozzi2013-12-261-52/+46
| | | | | | | query_format was setting state even if wasn't the correct thing to do. Somehow it worked by pure luck (until commit e6e6b88b6da). Fix the initialization by setting state inside of reconfig.
* 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.
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-4/+4
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* video/out: remove useless info struct and redundant fieldswm42013-10-231-6/+2
| | | | The author and comment fields were printed only in -v mode.
* gl_osd: mp_msg conversionwm42013-09-121-1/+1
|
* vo_corevideo: use dwidth/dheight for window dimensionsStefano Pigozzi2013-08-251-1/+1
| | | | | In the previous commit I wrongly used params->d_h/d_w which happened to work by chance.
* vo_corevideo: convert to use reconfig instead of configStefano Pigozzi2013-08-251-7/+6
|
* vo_corevideo: don't set colormatrix on direct rendering pathStefano Pigozzi2013-08-251-23/+49
| | | | | | | | | | | The current code uses GL_YCBCR_422_APPLE texture format. This allows to handle transparently the conversion to RGB but always use BT.601 colormatrix [1]. Hopefully I can adapt gl_video to take CVPixelBuffers soon so that `vo=opengl` can be used instead of `vo=corevideo` with `hwdec=vda` [1]: http://www.opengl.org/registry/specs/APPLE/ycbcr_422.txt http://www.opengl.org/registry/specs/APPLE/rgb_422.txt
* vo_corevideo: fix regression in colormatrix handlingStefano Pigozzi2013-08-251-40/+22
| | | | | | | | | | Regression since 18b6c01d92. That commit changed the colorspace handling to always reinit the video output. Since the CVPixelBuffers are lazily created, VOCTRL_SET_YUV_COLORSPACE was always called when the CVPixelBufferRef was NULL. Since CoreVideo functions do not complain when called on NULL, no one noticed that CVBufferSetAttachment, which stored the color matrix meta data was called on NULL.
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-221-105/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec' decoder in FFmpeg. The Good: This new implementation has some advantages over the previous one: - It works with Libav: vda_h264_dec never got into Libav since they prefer client applications to use the hwaccel API. - It is way more efficient: in my tests this implementation yields a reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and ~65-75% compared to h264 software decoding. This is mainly because `vo_corevideo` was adapted to perform direct rendering of the `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework. The Bad: - `vo_corevideo` is required to use VDA decoding acceleration. - only works with versions of ffmpeg/libav new enough (needs reference refcounting). That is FFmpeg 2.0+ and Libav's git master currently. The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture. One one end this makes the code simple since Apple's OpenGL implementation actually supports this out of the box. It would be nice to support other output image formats and choose the best format depending on the input, or at least making it configurable. My tests indicate that CPU usage actually increases with a 420p IMGFMT output which is not what I would have expected. NOTE: There is a small memory leak with old versions of FFmpeg and with Libav since the CVPixelBufferRef is not automatically released when the AVFrame is deallocated. This can cause leaks inside libavcodec for decoded frames that are discarded before mpv wraps them inside a refcounted mp_image (this only happens on seeks). For frames that enter mpv's refcounting facilities, this is not a problem since we rewrap the CVPixelBufferRef in our mp_image that properly forwards CVPixelBufferRetain/CvPixelBufferRelease calls to the underying CVPixelBufferRef. So, for FFmpeg use something more recent than `b3d63995` for Libav the patch was posted to the dev ML in July and in review since, apparently, the proposed fix is rather hacky.
* vo_corevideo: add uyvy422 pixel format supportStefano Pigozzi2013-08-151-0/+5
| | | | | Looks like the vda_h264_dec in ffmpeg likes to output this format and it inserted swscale to do pixfmt conversion to yuyv422.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-1/+1
| | | | Followup commit. Fixes all the files references.
* vo_corevideo: use new log APIStefano Pigozzi2013-08-011-15/+5
| | | | | Also removes the printing of the OpenGL info when using verbose mode since gl_common already does that.
* vo_corevideo: move to C from Objective-CStefano Pigozzi2013-08-011-0/+401
This file was alredy written in C. The only remaining part was the file exension and `#import`s.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-19 18:15:23 +0000