Comments (7)
The change to collapse all streams to stdout is completely intentional. Regardless of this change, your frontend relying on this seems rather strange. The API has log levels for a reason. Use them.
from mpv.
I didn't see the change log in DOCS/client-api-changes.rst.
Console output is not an API. You should not rely on it for any parsing activities. The API exists to access mpv log grouped by log level . Use them.
from mpv.
Of course, the front end relies on these log information. I must use the changes in these logs to determine whether the current command transmitted to mpv is correct. This information is also the most comprehensive, correct, and intuitive. This is why I read these.
The log needs to consider practicality and why it was previously divided into two pipeline outputs. At least the two pipeline outputs are very easy to read.
You may only use these log information after generating the .log, but in fact you are not the only one looking at this information. The front end reads these log information when it changes. This may also be the reason why the output was previously split into 2 pipes.
When I first debugged the merged debug log, I even thought that the log output of the Standard Output pipeline was faulty, because there was only playback progress information in the Standard Output at this time. why is it like this? Because the video information will only be captured when the file starts playing, when I look at these logs a few seconds later, the video information has already disappeared without a trace, as if this information has never been captured, because They are already at the top of the long log message and will most likely be deleted. The two logs mixed together are also difficult to read.
You may think that it is natural to use observe_property to monitor changes in mpv. I also use observe_property to monitor changes in most parameters, but observe_property has some unavoidable shortcomings in actual use:
-
Not everyone is an expert in mpv. I only used observe_property after reading these log information, because as a beginner, I didn’t know which parameter changes needed to be tracked. There were too many parameters. When I was a beginner, I didn't know that there was such a good thing as observe_property. The log gave me a good reference. Now it is much more difficult for beginners.
-
Using observe_property to batch monitor parameter changes will cause the pipe to be blocked (at least in Qt). I usually send 5 parameters in batches and then pause them so that mpv has time to read them. This is usually no problem, but multiple pauses will extend the command execution time and waste the front-end startup time.
-
Parameters are captured in the log faster, especially the width, height and duration of the video. This allows the front-end to prioritize these parameters and make the interface display faster. If you use observe_property, you must first create a pipeline and then use multiple questions and answers to obtain this information. I know this is not the correct way to use logging, but in practice it works very well.
I respect the changes you have made. I only need to modify three lines of code to solve the bug caused by this change. It will not even slow down the front-end startup speed, but it will become much more difficult for me to read these real-time log changes in the future. I may need to add new code to separate them again (from the front end, at least I don't expect that change).
You can close this issue, I have determined that this is not a bug.
Thank you very much, thank you for all your contributions to mpv, I also like mpv very much.
from mpv.
Using observe_property to batch monitor parameter changes will cause the pipe to be blocked (at least in Qt).
If you use observe_property, you must first create a pipeline and then use multiple questions and answers to obtain this information.
Are you using the JSON IPC? Why "batch monitor parameter changes will cause the pipe to be blocked"? Can you provide information on how your code interact with mpv?
from mpv.
I can only give you a rough description, because this problem was solved several years ago, so I can only give the following information from the description and memories added to the relevant code
2 possible phenomena:
Add the following code as text to the strlist [strlist_observe_property_1], and then send this strlist to mpv. If the text is too long, it may exceed the maximum value that mpv can read, which will cause some commands mpv to fail to obtain successfully.
Or for each line of code below, use a for loop to quickly pass it to mpv in batches. Then the transfer speed will be too fast, causing mpv to not even run normally.
This should be a problem with my code, not mpv.
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 100 , \"filename\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 111 , \"volume\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 122 , \"chapters\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 133 , \"playlist-count\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 144 , \"playlist-pos\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 155 , \"loop-playlist\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 166 , \"osd-bar\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 177 , \"audio-params/channel-count\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 188 , \"container-fps\"]}";
strlist_observe_property_1 << "{ \"command\": [\"observe_property\", 199 , \"hwdec-current\"]}";
from mpv.
Add the following code as text to the strlist [strlist_observe_property_1], and then send this strlist to mpv. If the text is too long, it may exceed the maximum value that mpv can read, which will cause some commands mpv to fail to obtain successfully.
You need to add \n
to separate each command. See the documentation:
Every message must be terminated with \n. Additionally, \n must not appear anywhere inside the message. In practice this means that messages should be minified before being sent to mpv.
from mpv.
This is not the reason. Only the command that is too long and the interval between multiple transmissions is too short will cause problems. If this is the problem, then each command sent to mpv will not take effect, and in the end I will not be able to control mpv.
from mpv.
Related Issues (20)
- Frame skipping when playing 720p 50/60fps video on a 1080p60 monitor using vo=gpu-next with gpu-api=opengl.
- Make ytd_hook.lua's ytdl binary file path and the ytdl json output available to other scripts HOT 3
- MPV throwing increase the analyze duration and unknown codec error
- HDR is too bright and lacks color tones HOT 20
- In fractional scaling on X (Cinnamon) if no app in "always on top": when starting and exiting full screen mpv resets display(s) back and forth HOT 6
- Sourceforge mpv downloader. HOT 3
- Tone map V-Log to PQ HDR HOT 7
- How to change the vertical position of the floating progress bar Or how to hide the floating progress bar? HOT 1
- Please considering remove `smb` from `X-KDE-Protocols` in desktop entry. HOT 2
- `--no-title-bar` mode the title bar appears after toggling fullscreen and window-maximized HOT 5
- Please allow users to disable and hide the floating progress bar completely. HOT 2
- why if do not use '--playlist' to open playlist in 0.38, playlist items randomize HOT 1
- Audio and Video go out of sync when using video-sync=display-resample HOT 38
- With [vo=direct3d], mpv does not render osc/osd/logo when opening app without playing file (idle mode)
- [question] is there a limit to entries for m3u playlist files in mpv? HOT 11
- wasapi Dolby THD channel confusion can we use LAV Filters HOT 23
- What are the units of the equalizer? HOT 4
- v0.37.0 v0.38.0 high gpu usage in win10 22h2 HOT 1
- A way to disable a command's repeatability (I need it for volume) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mpv.