Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libmpv doesn't use libmpv video output as default #14022

Closed
brainrom opened this issue Apr 29, 2024 · 3 comments
Closed

Libmpv doesn't use libmpv video output as default #14022

brainrom opened this issue Apr 29, 2024 · 3 comments

Comments

@brainrom
Copy link

Important Information

Provide following Information:

  • 0.38.0-1
  • ArchLinux + Hyprland
  • ArchLinux's world repo
  • 0.38
  • AMD Radeon RX580

Reproduction steps

  1. Initialize mpv context from third-party software according to official libmpv usage examples.
  2. Start to play video

Expected behavior

libmpv render video in provided OpenGL context

Actual behavior

mpv creates it's own window

Log file

https://pastebin.com/BFsJW8vJ

I'm currently developing an mpv frontend using libmpv Render API (display mpv's video over OpenGL) and v0.38 introduced this bug. On v0.37 all works fine and mpv shows video in OpenGL context. It fixes with simple mpv_set_option_string(mpv, "vo", "libmpv"), but should libmpv try to output video not via libmpv as default at all?

@sfan5
Copy link
Member

sfan5 commented Apr 29, 2024

https://github.com/mpv-player/mpv/blob/master/DOCS/client-api-changes.rst

- partially revert the changes from API version 1.27, remove libmpv as
    the default VO and move it to the bottom of the auto-probing order.
    This restores the prior behavior on all platforms other than macOS,
    but still auto selects libmpv/cocoa-cb on macOS if it was built with
    support for cocoa-cb.

@brainrom
Copy link
Author

Oops, didn't find. Checked the main changelog, but not separate one.
But why this was reverted?

Then, examples should be fixed, not mpv?

@kasper93
Copy link
Contributor

Let's consolidate the discussion about those changes in #13974 and what should be done to make releases smoother in terms of breaking changes.

Now that it has been released as 0.38, it is too late to change it back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants