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

[Feature request] Track script output state (clip/frame properties) in logfiles #391

Open
qyot27 opened this issue Mar 24, 2024 · 1 comment

Comments

@qyot27
Copy link
Member

qyot27 commented Mar 24, 2024

I think for the purpose of making the retention of frameprops or changing of frameprops when relevant easier, the core's logging function should report the clip's details and frameprop information (optionally with an indication of whether it's changed), with the execution of every function that gets logged normally.

Given this script:

SetLogParams("avslog.log",LOG_INFO)
a=LwLibavAudioSource("../Videos/LG New York HDR UHD 4K Demo.ts")
v=LwLibavVideoSource("../Videos/LG New York HDR UHD 4K Demo.ts",prefer_hw=2).BilinearResize(1920,1080)
AudioDub(v,a)
ConvertToYUV444(false,"709:f")

The result in avslog.log is this:

---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for liblsmashsource_LWLibavAudioSource() by script.
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for liblsmashsource_LWLibavVideoSource() by script.

I would expect there to be, well, more there. At least some indication of where the parser is between executing a certain line of the script, or per the issue title, it should report the clip and frameprops that were loaded (at the beginning of the script after the source loads), and then when other functions occur, whether the clip/frameprops have been changed, added, or deleted. At worst, the log would record the full set of clip/frameprops on every function success, so we always know the output state.

Something like:

---------------------------------------------------------------------
INFO: Autoloaded <MTModes.avsi>
---------------------------------------------------------------------
INFO: MTModes.avsi: Ignoring unnecessary MT-mode specification for liblsmashsource_LWLibavAudioSource() by script.
---------------------------------------------------------------------
INFO: MTModes.avsi: Ignoring unnecessary MT-mode specification for liblsmashsource_LWLibavVideoSource() by script.
---------------------------------------------------------------------
INFO: test_hdr.avs: LwLibavAudioSource added audio stream to variable a
---------------------------------------------------------------------
INFO: test_hdr.avs: LwLibavVideoSource added video stream to variable v
---------------------------------------------------------------------
INFO: test_hdr.avs: LwLibavVideoSource set properties:
Clip properties (maybe yes, just a basic Info() report, but still):
Pixel format: YUV420P10
Framerate: 23.976fps (24000/1001, however it gets formatted)
Resolution: 3840x2160

Frame Properties:
_Matrix: 9 (BT2020_NCL)
_Primaries: 9 (BT2020)
_Transfer: 16 (SMPTE2084)
_ChromaLocation: 0 (LEFT)
_ColorRange: 1 (LIMITED)
_FieldBased: 0 (PROGRESSIVE)
_AbsoluteTime: <populated> <-- since _AbsoluteTime changes per-frame, it's sufficient to know that something like this simply got added rather than track every single time it changes normally
---------------------------------------------------------------------
INFO: test_hdr.avs: AudioDub succeeded
<Clip info with audio added>
---------------------------------------------------------------------
INFO: test_hdr.avs: ConvertToYUV444(false,"709:f") succeeded

Clip Properties:
Pixel format: YUV444P10 *CHANGED

Frame Properties
_Matrix: 1 (709) *CHANGED
_ColorRange: 0 (FULL) *CHANGED
---------------------------------------------------------------------
INFO: EXIT: Script test_hdr.avs EOF
---------------------------------------------------------------------
INFO: EXIT: Script MTModes.avsi EOF

(yes, I know Convert doesn't actually change those frame properties in the above example; the point is that a frameprop state tracker in the log would actually help us find where those deficiencies are and fix them)

Obviously, the above is just an example of how it would look. Feel free to bikeshed to settle on a better way to organize the report lines.

Also, a couple issues that I'm not sure were intended:
The description for SetLogParams appears to be wrong about its defaults, at least on Linux:

  • It says it defaults to stderr if no logfile is set, but it actually errors out. You have to explicitly tell it to use "stderr" as if it were the name of the logfile for it to actually go to stderr.
  • The verbosity selection isn't optional, so it doesn't actually default to LOG_INFO. If omitted, it complains that it requires a numerical value and errors out.

Also, the Wiki is wrong about the param order for ConvertToYUV444: it lists matrix first, when - like the other YUV functions - it's actually second.

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

2 participants