fix hwdec printing mess #15909
Open
fix hwdec printing mess #15909
+89
−34
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
a3823ce made this request a special case because of all the threading considerations. Unfortunately, the implementation made it so that VDCTRL_GET_HWDEC always would return CONTROL_UNKNOWN when using mp_decoder_wrapper_control. This didn't matter because VDCTRL_GET_HWDEC in vd_lavc would always succeed, but in reality it shouldn't. It takes some time before we actually know what the hwdec is and if you query during that time, you'll could get some bogus value (e.g. during hwdec auto probing). So fix that by returning false in vd_lavc if hwdec_notified isn't there yet and adjust the wrapper control logic to take this into account.
All of this just to fix the giant mess that is printing the current hwdec when using keybindings. This never actually worked properly although bbac628 made it more obviously wrong for everyone. Previously, when you changed hwdec and allowed the osd to pretty print a message, all that would happen is that it would immediately fetch hwdec-current when the change in the hwdec option is signalled. This could very easily be wrong. e.g. for me it would print "vulkan" but in reality that failed and I fell back on vaapi-copy. That's because it would just fetch whatever hwdec method was being tried at that point an time and didn't bother to verify if it was actually in use or not. bbac628 didn't help because it delays option callbacks until the next playloop tick which effectively means what is printed on screen is actually the opposite of what is actually used. Very funny. Since the previous commit implemented more proper reporting in the hwdec-currert property (e.g. it can return unavailable now instead of lying to you), we can fix this by using a queueing approach. In the list of property_osd_display, a queue flag is added which signals that the printing of ths property needs to be handled on a special queue. Since we know this has to go after the option callback handlers, this gets processed in the playloop right afterwards. We check to see if the property can be gotten first. If so, process it and print the correct value. If not, put it back in the queue and wait until the next playloop. It's written generically for any potential property, but probably hwdec is the only thing that will ever use this.
|
Download the artifacts for this pull request: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This never really worked before and then I made it work for even less people, so might as well fix it now.