summaryrefslogtreecommitdiffstats
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* test: make libmpv_test abort if an error is loggedsfan518 hours1-7/+39
| | | | | Among others this provides a trivial test that built-in scripts aren't throwing an error at load or init time.
* test: add an encoding test with libmpvsfan57 days2-3/+145
|
* test: support format refs for multiple ffmpeg versionsDudemanguy12 days10-3/+3725
| | | | | | With some small tweaks to the test, we can support multiple ffmpeg versions. This adds back ffmpeg 6 support that was removed in the previous commit.
* test: update format refs for new major ffmpeg versionDudemanguy12 days5-14/+14
| | | | | | | xvmc was removed and d3d12 was added. https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/a12cd3be98e8aba6e74274192ec6532988aa9444 https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/142f727b9ca21c95414536074e3f89c687271dd4
* win32: change fputs to fwrite wrapperKacper Michajłow2024-04-071-1/+1
| | | | | | | | | Removes mp_puts/mp_fputs and adds mp_fwrite. In fact I wanted fwrite instead of puts, no need to make it more awkward with the implicit new lines. Fixes: fc55f355fc8225328cf0472e3deb4021eba96303
* test: fflush output stream before abortKacper Michajłow2024-03-211-0/+6
| | | | For `meson test` to not eat lines on abort.
* m_property: add `>` for fixed precision floating-point expansionKacper Michajłow2024-03-212-0/+102
| | | | | | | | | | | | | | This enhancement makes it easier to create constant width property expansions, useful for the `--term-status-msg`. Additionally, it changes to `%f` printing with manual zero trimming, which is easier to control than `%g`. With this method, we can directly specify precision, not just significant numbers. This approach also avoids overly high precision for values less than 1, which is not necessary for a generic floating-point print function. A new print helper function is added, which can be used with adjusted precision for specific cases where a different default is needed. This also unifies the code slightly.
* meson: remove winmm dependency for win32 desktop targetnanahi2024-03-191-1/+0
| | | | Not needed anymore as timeBeginPeriod() is removed.
* win32: increase hires timer resolutionnanahi2024-03-191-0/+1
| | | | | | | | | | | timeBeginPeriod() only allows setting minimum timer resolution to 1 ms. However, modern x86 platforms support a minimum timer resolution of 0.5 ms. Use NtSetTimerResolution() instead for the increased resolution, which can be set with MPV_HRT_RES. Additionally, change the units of mp_start_hires_timers(), mp_end_hires_timer(), MPV_HRT_RES, and MPV_HRT_MAX to nanoseconds, in accordance with other functions used in timer.h.
* win32: add puts/fputs wrappersKacper Michajłow2024-03-191-1/+2
|
* win32: optimize mp_vfprintf a littleKacper Michajłow2024-03-191-1/+1
| | | | | | | | - remove redundant strlen/wcslen - reuse allocated temporary buffers The difference is not big, but it satisfies me to remove those redundancies.
* win32: cache GetConsoleMode state for stdout/stderrKacper Michajłow2024-03-192-2/+3
| | | | | | | GetConsoleMode() can be quite slow and in mpv the mode never changes, so we can just check it once. Fixes performance when writing lots of logs to terminal.
* image_writer: fix TOCTOU in screenshot filename generationnanahi2024-03-191-1/+1
| | | | | | | | | | | | | | | | The screenshot command is documented to not overwrite existing files. However, there is a race window between the filename is generated with gen_fname and when the file is open to write. Specifically, the convert_image function in this window can be very time consuming depending on video and screenshot image format and size. This results in existing file being overwritten because the file writing functions don't check for the existance of file. Fix this be opening the file in exclusive mode. Add overwrite parameter to write_image for other operations that are documented to overwrite existing files, like screenshot-to-file. Note that for write_avif, checking existance is used instead because avio_open does not support exclusive open mode.
* test/test_utils: add mp_msg_set_max_level stubDudemanguy2024-03-032-0/+2
| | | | Needed since the previous commit.
* test: add missing libplacebo dependencyder richter2024-02-241-2/+2
|
* options/path: move path utility functions to misc/path_utilsnanahi2024-02-231-0/+1
| | | | | These utility functions have nothing to do with user and config dir/file. Move them to a separate file.
* osdep/timer: update documentation and test for mp_time_nsKacper Michajłow2024-01-261-1/+1
| | | | No longer true after 8bbcc87feea7abf256a6c7f511244d09f5520c17.
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-223-18/+20
|
* win32: move IME candidate window to video windownanahi2024-01-151-0/+1
| | | | | By default the IME candidate window appears on the top left corner of the monitor. Move it to the video window for sane behavior.
* test: update ffmpeg format refsDudemanguy2023-11-185-2/+102
| | | | | | | | These tests should really be rewritten to be less stupid so they don't break everytime ffmpeg updates its formats, but that's too much effort right now. Bump the required libavutil version as well. https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/8e1ef7c38f6906455ae96984d032e57106e11b77
* ALL: use pl_hdr_metadata and nuke sig_peakKacper Michajłow2023-11-052-1/+5
| | | | | | | | This commit replaces all uses of sig_peak and maps all HDR metadata. Form notable changes mixed usage of maxCLL and max_luma is resolved and not always max_luma is used which makes vo_gpu and vo_gpu_next behave the same way.
* timer: remove unused codeKacper Michajłow2023-11-051-16/+0
|
* threads: rename threads.c to threads-posix.cKacper Michajłow2023-11-051-1/+1
|
* mp_thread: add win32 implementationKacper Michajłow2023-11-052-5/+8
|
* test: unbreak build when win32-internal-pthreads is disabledKacper Michajłow2023-10-261-2/+5
|
* test/meson: add missing libplacebo depKacper Michajłow2023-10-241-4/+4
|
* test: add basic tests for timer codesfan52023-10-204-22/+61
|
* test: change test_utils stubs to ns variantsDudemanguy2023-10-162-6/+6
| | | | The functions now internally use the ns timer and not the us one.
* meson: don't link pthreads when internal impl is usedKacper Michajłow2023-09-291-1/+5
|
* meson: add missing gl-video test dependencyKacper Michajłow2023-09-291-1/+2
|
* timer: rename mp_add_timeout to reflect what it actually doesKacper Michajłow2023-09-292-2/+2
|
* timer: rename mp_time_us_to_timespec to reflect what it actually doesKacper Michajłow2023-09-292-2/+2
|
* test/meson: add missing avutil dependency to chmap testJan Ekström2023-08-061-1/+2
| | | | | Found out with a CI image where FFmpeg is not located in the default sysroot.
* test: indicate test function ran in logsfan52023-08-061-0/+5
|
* test: enable log messages for libmpv testsfan52023-08-061-2/+3
|
* test: refactor helper methods to be universally usablesfan52023-08-061-17/+17
|
* test: bump libmpv test timeoutDudemanguy2023-08-012-10/+3
| | | | | | | Get rid of the time during the while loop and just let this run forever in case of a failure and also bump the timeout in meson to 60 seconds since we know it is possible for msys to take a very long time on occasion. That should be plenty of time for it to finish.
* test: enhance libmpv testDudemanguy2023-07-272-6/+250
| | | | | | | | | | We already have a libmpv test, but it's really basic and barely does anything. In an effort to hopefully prevent future breakage, lets expand this to do more stuff. First of all, it simply tests setting a bunch of properties/options. Secondly, it tries to load a file (the mpv icon that we already have in the source tree). And then finally it tries the lavfi-complex filter since this is a known special case where weird things can happen.
* json: unify json_parse depth to MAX_JSON_DEPTH=50cvzi2023-07-081-3/+1
|
* test/meson: explicitly specify lavf dependencycloud116652023-07-013-3/+6
| | | | Added stubs for mp_set_avdict().
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* test: update format refs to ffmpeg 6Dudemanguy2023-03-155-3/+227
| | | | | | | | | Major release means new formats and failing tests so just add the new stuff to the ref again and bump the minimum libavutil version. The last ffmpeg commit that added a new format and is the minimum required version for these subset of tests is referenced below. https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/479747645f795b6f4f376578ea1556409f943c31
* test: integrate unittests with mesonDudemanguy2023-03-0221-430/+526
| | | | | | | | | | | | This reworks all of mpv's unit tests so they are compiled as separate executables (optional) and run via meson test. Because most of the tests are dependant on mpv's internals, existing compiled objects are leveraged to create static libs and used when necessary. As an aside, a function was moved into video/out/gpu/utils for sanity's sake (otherwise most of vo would have been needed). As a plus, meson multithreads running tests automatically and also the output no longer pollutes the source directory. There are tests that can break due to ffmpeg changes, so they require a specific minimum libavutil version to be built.
* test: update ffmpeg format refsDudemanguy2023-03-024-22/+156
| | | | | | A few formats were added recently, some were removed, and some flags were changed. Maybe this should be better, but just update for now so the tests stop failing.
* test/repack.c: skip tests that exceeded maximum allowed ZIMG dimensionKacper Michajłow2023-01-281-12/+27
| | | | Fixes tests on 32-bit platforms
* test: update to reflect that Vulkan is a generic format againPhilip Langdale2022-10-291-1/+1
| | | | | In the previous change, I removed the explicit mapping for Vulkan, so it now shows up as [GENERIC].
* f_hwtransfer: mp_image_pool: support HW -> HW mappingPhilip Langdale2022-09-211-1/+1
| | | | | | | | | | | | | | | | Certain combinations of hardware formats require the use of hwmap to transfer frames between the formats, rather than hwupload, which will fail if attempted. To keep the usage of vf_format for HW -> HW transfers as intuitive as possible, we should detect these cases and do the map operation instead of uploading. For now, the relevant cases are moving between VAAPI and Vulkan, and VAAPI and DRM Prime, in both directions. I have introduced the IMGFMT entry for Vulkan here so that I can put in the complete mapping table. It's actually not useless, as you can map to Vulkan, use a Vulkan filter and then map back to VAAPI for display output.
* test/chmap: start adding AVChannelLayout unit testsJan Ekström2022-06-151-0/+130
| | | | | | | | The first set iterates through all standard FFmpeg layouts and checks that those which fit MP_NUM_CHANNELS succeed. The second set iterates through built-in named channel layouts, and attempts to convert them to AVChannelLayouts.
* various: fix typosCœur2022-04-251-1/+1
|
* command: add secondary-sub-start and secondary-sub-end propertiesRipose2021-07-121-0/+8
| | | | | | | Adds secondary-sub-start and secondary-sub-end properties by setting the current_track index in the m_property's priv variable which later gets accessed in get_times. Also adds a test of the secondary subtitle time properties in tests/subtimes.js bound to 'T'.
* command: extend subprocess commandwm42020-07-201-6/+12
| | | | | | | | | | | | | | | | | | | | Add env and detach arguments. This means the command.c code must use the "new" mp_subprocess2(). So also take this as an opportunity to clean up. win32 support gets broken by it, because it never made the switch to the newer function. The new detach parameter makes the "run" command fully redundant, but I guess we'll keep it for simplicity. But change its implementation to use mp_subprocess2() (couldn't do this earlier, because win32). Privately, I'm going to use the "env" argument to add a key binding that starts a shell with a FILE environment variable set to the currently playing file, so this is very useful to me. Note: breaks windows, so for example youtube-dl on windows will not work anymore. mp_subprocess2() has to be implemented. The old functions are gone, and subprocess-win.c is not built anymore. It will probably work on Cygwin.
* zimg: add slice threading and use it by defaultwm42020-07-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This probably makes it much faster (I wouldn't know, I didn't run any benchmarks ). Seems to work as well (although I'm not sure, it's not like I'd perform rigorous tests). The scale_zimg test seems to mysteriously treat color in fully transparent alpha differently, which makes no sense, and isn't visible (but makes the test fail). I can't be bothered with investigating this more. What do you do with failing tests? Correct, you disable them. Or rather, you disable whatever appears to cause them to fail, which is the threading in this case. This change follows mostly the tile_example.cpp. The slice size uses a minimum of 64, which was suggested by the zimg author. Some of this commit is a bit inelegant and weird, such as recomputing the scale factor for every slice, or the way slice_h is managed. Too lazy to make this more elegant. zimg git had a regressio around active_region (which is needed by the slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the bug was never released, so just add a warning to the manpage.
* test: update to new ffmpeg pixfmtswm42020-06-175-5/+25
| | | | | Mainly, X2RGB10BE is added. Add our own unpack test for this format. Also, swscale seems to have added support for GBRPF conversion.
* video: add AV_PIX_FMT_UYYVYY411 conversion supportwm42020-05-223-4/+8
| | | | | | | | | | It may be completely useless, and I can't verify it as no known samples or other known/accessible software using it, but why not? Putting this together with he 422 code requires making it slightly more generic. I'm still staying with a "huge" if tree instead of a table to select the scanline worker callback, because it's actually small and not huge (although it not being generic still feels slightly painful).
* video: clean up pixel metadata stuff some morewm42020-05-202-275/+280
| | | | | | | | | | | | | | | A repeat of the previous useless commits. Pondered whether to use separate fields or just a flags integer for color and component types; the latter won for now. Functions like mp_imgfmt_get_component_type() are now discouraged, and mp_imgfmt_desc.flags is back for defining all information. Some days ago I felt like the opposite would be the better design. Fortunately, it doesn't matter. With this, I think all image format properties that mpv needs are exhaustively defined all in one place.
* video: shuffle imgfmt metadata code aroundwm42020-05-202-92/+97
| | | | | | | | | | | | | | | | | I guess I decided to stuff it all into mp_imgfmt_desc (the "old" struct). This is probably a mistake. At first I was afraid that this struct would get too fat (probably justified, and hereby happened), but on the other hand mp_imgfmt_get_desc() (which builds the struct) calls the former mp_imgfmt_get_layout(), and the separation doesn't make too much sense anyway. Just merge them. Still, try to keep out the extra info for packed YUV bullshit. I think the result is OK, and there's as much information as there was before. The test output changes a little. There's no independent bits[] array anymore, so formats which did not previously have set this now show it. (These formats are mpv-only and are still missing the metadata. To be added later). Also, the output for the cursed packed formats changes.
* video: fix AV_PIX_FMT_UYYVYY411 allocationwm42020-05-181-2/+1
| | | | | | | My previous commit added support for this format, but it was still broken, and prevented the allocation code from working. It's unknown whether it's correct now (because this pixfmt is so obscure and useless, there are no known samples around), but who cares.
* video: add pixel component location metadatawm42020-05-182-1/+513
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought I'd probably want something like this, so the hardcoded stuff in repack.c can be removed eventually. Of course this has no purpose at all, and will not have any. (For now, this provides only metadata, and nothing uses it, apart from the "test" that dumps it as text.) This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite, because the format is 100% useless). Support for some mpv-only formats is missing, ironically. The code goes through _lengths_ to try to make sense out of the FFmpeg AVPixFmtDescriptor data. Which is even more amazing that the new metadata basically mirrors pixdesc, and just adds to it. Considering code complexity and speed issues (it takes time to crunch through all this shit all the time), and especially the fact that pixdesc is very _incomplete_, it would probably better to have our own table to all formats. But then we'd not scramble every time FFmpeg adds a new format, which would be annoying. On the other hand, by using pixdesc, we get the excitement to see whether this code will work, or break everything in catastrophic ways. The data structure still sucks a lot. Maybe I'll redo it again. The text dump is weirdly differently formatted than the C struct - because I'm not happy with the representation. Maybe I'll redo it all over again. In summary: this commit does nothing.
* video: clean up some imgfmt related stuffwm42020-05-184-667/+671
| | | | | | | | | | | | | | | | Remove the vaguely defined plane_bits and component_bits fields from struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove the bytes[] field, replace uses with bpp[]. Fix some potential alignment issues in existing code. As a compromise, split mp_image_pixel_ptr() into 2 functions, because I think it's a bad idea to implicitly round, but for some callers being slightly less strict is convenient. This shouldn't really change anything. In fact, it's a 100% useless change. I'm just cleaning up what I started almost 8 years ago (see commit 00653a3eb052). With this I've decided to keep mp_imgfmt_desc, just removing the weird parts, and keeping the saner parts.
* test: explicitly test repacking for all packed RGB variantswm42020-05-182-36/+117
| | | | This stuff is very annoying, so it's good to have full coverage.
* draw_bmp: use command line options for any used scalerswm42020-05-131-3/+3
|
* draw_bmp: add integer blending for 8 bit formatswm42020-05-121-28/+28
| | | | | | | | Whatever it's worth. Instead of doing a pretty stupid conversion to float, just blend it directly. This works for most RGB formats that are 8 bits per component or below (the latter because we expand packed fringe RGB formats for simplicity). For higher bit depth RGB this would need extra code.
* draw_bmp: don't make strange decisions on broken iknput csp paramswm42020-05-122-64/+64
| | | | | | | | | | | | This checked params->color.space for being RGB. If the colorspace is unset, this did dumb things because even if the imgfmt was a RGB one, the colorspace was not set to RGB. This actually also happened to the tests. (Short-cutting RGB like this is actually wrong, since RGB could still have strange gamma or primaries, which would warrant a full conversion. So you'd need to check for these other parameters as well. To be fixed later.)
* draw_bmp: add a function to return a single-texture OSD overlaywm42020-05-111-2/+2
| | | | | | | | | | | | | | Maybe this is useful for some of the lesser VOs. It's preferable over bad ad-hoc solutions based on the more complex sub_bitmap data structures (as observed e.g. in vo_vaapi.c), and does not use that much more code since draw_bmp already created such an overlay internally. But I still wanted something that avoids having to upload/render a full screen-sized overlay if for example there's only a tiny subtitle line on the bottom of the screen. So the new API can return a list of modified pixels (for upload) and non-transparent pixels (for display). The way these pixel rectangles are computed is a bit dumb and returns dumb results, but it should be usable, and the implementation can change.
* draw_bmp: rewritewm42020-05-092-0/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This