aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
...
* manpage: warn about the use of HDR functions for target-trcGravatar Niklas Haas2016-06-28
| | | | | | | Most devices seems to require special signalling (e.g. via HDMI metadata) to actually decode HDR signals and treat them as such, so it's probably worth warning the potential user about the fact that mpv pretty definitely does *not* set any of this metadata signalling.
* vo_opengl: implement ARIB STD-B68 (HLG) HDR TRCGravatar Niklas Haas2016-06-28
| | | | | | | | | | | | | | This HDR function is unique in that it's still display-referred, it just allows for values above the reference peak (super-highlights). The official standard doesn't actually document this very well, but the nominal peak turns out to be exactly 12.0 - so we normalize to this value internally in mpv. (This lets us preserve the property that the textures are encoded in the range [0,1], preventing clipping and making the best use of an integer texture's range) This was grouped together with SMPTE ST2084 when checking libavutil compatibility since they were added in the same release window, in a similar timeframe.
* audio: add a helper for getting frame end PTSGravatar wm42016-06-27
| | | | Although I don't see any use for it yet, why not.
* dec_audio: fix segment boudnary switchingGravatar wm42016-06-27
| | | | | | | | | | | | | Some bugs in this code are exposed by e.g. playing lossless audio files with --ad-lavc-threads=16. (libavcodec doesn't really support threaded audio decoding, except for lossless files.) In these cases, a major amount of audio can be buffered, which makes incorrect handling of this buffering obvious. For one, draining the decoder can take a while, so if there's a new segment, we shouldn't read audio. The segment end check was completely wrong, and used the start value.
* ao_lavc, vo_lavc: Migrate to new encoding API.Gravatar Rudolf Polzer2016-06-27
| | | | | Also marked some places for possible later refactoring, as they became quite similar in this commit.
* Fix misspellingsGravatar stepshal2016-06-26
|
* vo_opengl utils: use gl->main_fb when reading window contentGravatar quilloss2016-06-26
| | | | | | | | The main framebuffer is not the default framebuffer for the dxinterop backend. Bind the main framebuffer and use the appropriate attachment when reading the window content. Fix #3284
* manpage: fix typoGravatar wm42016-06-26
|
* vo_xv: fix behavior with odd sizesGravatar wm42016-06-25
| | | | | | | | | | The size check introduced in commit d941a57b did not consider that Xv can round up the image size to the next chroma boundary. Doing that makes sense, so it can't certainly be considered server misbehavior. Do 2 things against this: allow if the server returns a larger image (we just crop it then), and also allocate a properly aligned image in the first place.
* DOCS: change version references from 0.17.1 to 0.18.0Gravatar wm42016-06-25
| | | | 0.17.1 was never released, so the actual 0.18.0 release takes its place.
* image_writer: port to new encode APIGravatar wm42016-06-24
|
* ass_mp.h: remove conditional inclusion guardsGravatar wm42016-06-24
| | | | | This file is only used when libass is enabled. (It used to be different, when code was more entangled.)
* af_lavcac3enc: use av_err2str() call (fixes Libav build)Gravatar wm42016-06-23
| | | | | I added this call because I thought it'd be nice, but Libav doesn't have this function (macro, actually).
* af_lavcac3enc: make encoder configurableGravatar wm42016-06-23
|
* af_lavcac3enc: implement flushing on seekGravatar wm42016-06-23
| | | | | There's a lot of data that could have been buffered, and which has to be discarded.
* af_lavcac3enc: port to new encode APIGravatar wm42016-06-23
|
* af_lavcac3enc: automatically configure most encoder parametersGravatar wm42016-06-23
| | | | | | | | | | | Instead of hardcoding what the libavcodec ac3 encoder expects, configure it based on the AVCodec fields. Unfortunately, it doesn't export the list of sample rates, so that is done manually. This commit actually fixes the rate always to 48Khz. I don't even know whether the other rates worked. (Possibly did, but they'd still change the spdif parameters, and would work differently from ad_spdif.c.)
* af_lavcac3enc: drop log message prefixesGravatar wm42016-06-23
| | | | MPlayer leftover. They're already added by the logging code.
* af_lavcac3enc: fix custom bitratesGravatar wm42016-06-23
| | | | | | Probably has been broken for ages. (Not sure why anyone would use this feature, though.)
* vo_opengl: improve missing function warningGravatar wm42016-06-22
| | | | | Mostly a cosmetic change. Handling bultin and extension functions separaterly makes more sense here too.
* ad_lavc: resume from mid-stream EOF conditions with new decode APIGravatar wm42016-06-22
| | | | | | | | | | | | | | | | Workaround for an awful corner-case. The new decode API "locks" the decoder into the EOF state once a drain packet has been sent. The problem starts with a file containing a 0-sized packet, which is interpreted as drain packet. This should probably be changed in libavcodec (not treating 0-sized packets as drain packets with the new API) or in libavformat (discard 0-sized packets as invalid), but efforts to do so have been fruitless. Note that vd_lavc.c already does something similar, but originally for other reasons. Fixes #3106.
* vo_opengl: add scaler name to the 'Disabling scaler' messageGravatar dirb2016-06-22
| | | | | Print to the user the name of the scaler that gets disabled rather than just printing its number.
* vf_vdpaurb: use new common nv12 download codeGravatar wm42016-06-21
| | | | | | | | | | See previous commit. (The mixing case was never supported, so this has equivalent functionality.) This also implicitly fixes a bug: the old code allocated image data for the cropped surface size only, which means the video_surface_get_bits_y_cb_cr call could write beyond the allocated image memory.
* vdpau: get surface data as nv12 if possibleGravatar wm42016-06-21
| | | | | | | | | | | | | | | | For now, this affects taking screenshots only. If the video mixer is actually needed, we want to go through the video mixer for screenshots too - which is why this function simply always used the video mixer, and then copied the surface to RAM as RGBA. Add reading the surface as nv12 if possible. If the format is correct, and no special video processing (like deinterlacing) is used, then it's read directly without going through the video mixer. There's no particular reason for doing this, other than avoiding the video mixer (like vo_opengl can do it now). Also, the next commit will make use of this in vf_vdpaurb.c.
* command: improve playlist* properties change notificationsGravatar wm42016-06-20
| | | | | | | Until now, only the "playlist" property itself had proper change notification. Extend it to all other properties as well. Fixes #3267 (hopefully).
* github: move "reproduction steps" before behavior sectionsGravatar wm42016-06-20
|
* vo_opengl: manually add the GL_BACK_LEFT constant for GLESGravatar Floens2016-06-20
| | | | | GLES doesn't have this constant. It's not used on GLES. I'm starting to think we need some better way to do this.
* vo_opengl: GL_ARB_timer_query compile fix for GLESGravatar Floens2016-06-20
| | | | | | | | The GL_ARB_timer_query extension and thus the GL_TIME_ELAPSED constant don't exist for GLES. For ES the EXT_disjoint_timer_query is used so take the constant from that else provide the constant manually. See pr #3216 which introduced this error.
* vf_vdpaurb: fix operationGravatar wm42016-06-20
| | | | | The hw_subfmt field remained set, while it has to be unset for non-hwdec formats.
* vo_opengl: unmap hwdec images once rendering is doneGravatar wm42016-06-20
| | | | | Instead of keeping them for a while. While keeping the mapping was perfectly ok, nothing speaks against reducing the time they're mapped.
* vo_opengl: vdpau interop without RGB conversionGravatar wm42016-06-19
| | | | | | | | | | | | | | | | | | | | | | Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
* refqueue: free referenced images on freeGravatar wm42016-06-19
| | | | | | | | Otherwise stale references will survive forever. Could leak hardware video surfaces. In particular, the mpv vdpau code crashed with an assertion when exiting after toggling deinterlacing, because not all references were released.
* bitmap_packet: let max=0 mean unlimitedGravatar wm42016-06-18
| | | | | And remove the strange PACKER_MAX_WH define. This is more convenient for users which don't care about limits, such as sd_lavc.c.
* sd_lavc: fix sub-bitmap alignmentGravatar wm42016-06-18
| | | | Ooops.
* vo_opengl: remove prescaling framework with superxbr prescalerGravatar Bin Jin2016-06-18
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: remove uniform buffer object routinesGravatar Bin Jin2016-06-18
|
* vo_opengl: remove nnedi3 prescalerGravatar Bin Jin2016-06-18
|
* cocoa: fix display refresh rate retrieval on multi monitor setupsGravatar Akemi2016-06-18
| | | | | | | | | | | | | | | | | | 1. this basically reverts commit de4c74e5a4a996e8ff431c8f33a32c4b580be203. even with CVDisplayLinkCreateWithActiveCGDisplays and CVDisplayLinkSetCurrentCGDisplayFromOpenGLContext we still have to explicitly set the current display ID, otherwise it will just always choose the display with the lowest refresh rate. another weird thing is, we still have to set the display ID another time with CVDisplayLinkSetCurrentCGDisplay after the link was started. otherwise the display period is 0 and the fallback will be used. if we ever use the callback method for something useful it's probably better to use CVDisplayLinkCreateWithActiveCGDisplays since we will need to keep the display link around instead of releasing it at the end. in that case we have to call CVDisplayLinkSetCurrentCGDisplay two times, once before and once after LinkStart. 2. add windowDidChangeScreen delegate to update the display refresh rate when mpv is moved to a different screen.
* cocoa: fix actual display refresh rate retrievalGravatar Akemi2016-06-18
| | | | | | | | | | | | | We have two problems here. 1. CVDisplayLinkGetActualOutputVideoRefreshPeriod, like the name suggests, returns a frame period and not a refresh rate. using this as screen_fps just leads to a slideshow. why didn't this break video playback on OS X completely? the answer to this leads us to the second problem. 2. it seems that CVDisplayLinkGetActualOutputVideoRefreshPeriod always returns 0 if used without CVDisplayLinkSetOutputCallback and hence always fell back to CVDisplayLinkGetNominalOutputVideoRefreshPeriod. adding a callback to CVDisplayLink solves this problem. the callback function at this moment doesn't do anything but could possibly used in the future.
* vo_opengl: dxinterop: render to gl->main_fbGravatar James Ross-Gowan2016-06-18
| | | | | | | This can also remove all the stuff for lazily attaching the texture. It doesn't matter if the dxinterop backend changes the bound framebuffer during a VOCTRL, since the renderer does not rely on the GL state being preserved.
* vo_opengl: add ability to render to an arbitrary backing framebufferGravatar wm42016-06-18
| | | | | | | Most of the functionality already exists for the sake of vo_opengl_cb. We only have to use it. This will be used by dxinterop in the following commit.
* sd_lavc: align sub-bitmaps for the sake of libswscaleGravatar wm42016-06-18
| | | | | | | Since there are not many sub-rectangles, this doesn't cost too much. On the other hand, it avoids frequent warnings with vo_xv. Also, the second copy in mp_blur_rgba_sub_bitmap() can be dropped.
* sd_lavc: fix typoGravatar wm42016-06-18
|
* sub, vo_opengl: use packed sub-bitmaps directly if availableGravatar wm42016-06-17
| | | | | | | | | | | | | | | | | | The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
* sd_lavc: change hack against vobsubs with wrong resolutionGravatar wm42016-06-17
| | | | | | | The sub-bitmaps get extended by --sub-gauss, so we have to compute the bounding box on the original subs. Not sure if this is really eqauivalent to what the code did before, and I don't have the sample anymore. (But this approach sure is a _shitty_ hack.)
* sub: fix --sub-gaussGravatar wm42016-06-17
| | | | | | | | | | | | | | | | | | | | Implement it directly in sd_lavc.c as well. Blurring requires extending the size of the sub-images by the blur radius. Since we now want sub_bitmaps to be packed into a single image, and we don't want to repack for blurring, we add some extra padding to each sub-bitmap in the initial packing, and then extend their size later. This relies on the previous bitmap_packer commit, which always adds the padding in all cases. Since blurring is now done on parts of a large bitmap, the data pointers can become unaligned, depending on their position. To avoid shitty libswscale printing a dumb warning, allocate an extra image, so that the blurring pass is done on two newly allocated images. (I don't find this feature important enough to waste more time on it.) The previous refactor accidentally broke this feature due to a logic bug in osd.c. It didn't matter before it happened to break, and doesn't matter now since the code paths are different.
* sub: move paletted image handling completely to sd_lavc.cGravatar wm42016-06-17
| | | | | | | | | | | | | | | | | | | Until now, subtitle renderers could export SUBBITMAP_INDEXED, which is a 8 bit per pixel with palette format. sd_lavc.c was the only renderer doing this, and the result was converted to RGBA in every use-case (except maybe when the subtitles were hidden.) Change it so that sd_lavc.c converts to RGBA on its own. This simplifies everything a bit, and the palette handling can be removed from the common code. This is also preparation for making subtitle images refcounted. The "caching" in img_convert.c is a PITA in this respect, and needs to be redone. So getting rid of some img_convert.c code is a positive side- effect. Also related to refcounted subtitles is packing them into a single mp_image. Fewer objects to refcount is easier, and for the libass format the same will be done. The plan is to remove manual packing from the VOs which need single images entirely.
* bitmap_packer: make manual use slightly more convenientGravatar wm42016-06-17
| | | | | | | | | | | | | | | | | Apply the padding internally to each input bitmap, instead of requiring this for the semi-public API. Right now, everything still uses packer_pack_from_subbitmaps() to fill the input bitmap sizes, but that's going to change with the following commit. Since bitmap_packer.in is mutated during packing anyway, it's more convenient to add the padding automatically. Also, guarantee that every sub-bitmap has a padding border around it. Don't let the padding overlap. Add padding even on the containing borders. This is simpler, doesn't cost much in memory usage, and is convenient for one of the following commits.
* sd_lavc: move AVSubtitle bitmap setup code into its own functionGravatar wm42016-06-17
| | | | No functional changes.
* Add github issue and pull request templatesGravatar wm42016-06-17
| | | | | | | I do not understand why github requires adding this crap to source code repositories themselves, instead of making them part of the repository configuration. Remove CONTRIBUTING.md to compensate for github crap accumulating.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 02:25:07 +0000