Is your feature request related to a problem? Please describe.
As far as I can tell, srt-live-transmit does not provide a defined logging output format for machine interpretation. This makes it difficult to tell e.g. the state of a connection from a script or test application with confidence, since the exact log format is presumably not specified and could change between versions.
Describe the solution you'd like
I'd like to be able to configure srt-live-transmit so it outputs everything in a standardized, parseable format, with some reasonable policy to allow for backwards-compatible changes and deprecation.
The output should include:
Normal log events, containing the message, log level, and perhaps additional context.
Statistics reports (if enabled)
Connection state events, although these could conceivably be part of log events.
Each message should contain a top-level value that declares the message's schema. This prevents a consumer from needing to check several values to determine how a message should be interpreted. It should also contain a timestamp with reasonable (millisecond?) resolution.
Some examples follow, and assume JSON (which is probably the most reasonable). I'm not attached to the particular details of the schema, as long as it's clearly defined and straightforward to interpret programmatically.
Describe alternatives you've considered
The statistics output is quite nice, but getting connection state change events currently requires manual parsing of the log messages.
Additional context
Related to #908, and perhaps #55
Is your feature request related to a problem? Please describe. As far as I can tell,
srt-live-transmit
does not provide a defined logging output format for machine interpretation. This makes it difficult to tell e.g. the state of a connection from a script or test application with confidence, since the exact log format is presumably not specified and could change between versions.Describe the solution you'd like I'd like to be able to configure
srt-live-transmit
so it outputs everything in a standardized, parseable format, with some reasonable policy to allow for backwards-compatible changes and deprecation.The output should include:
Each message should contain a top-level value that declares the message's schema. This prevents a consumer from needing to check several values to determine how a message should be interpreted. It should also contain a timestamp with reasonable (millisecond?) resolution.
Some examples follow, and assume JSON (which is probably the most reasonable). I'm not attached to the particular details of the schema, as long as it's clearly defined and straightforward to interpret programmatically.
Log message:
Separate connection state event:
Alternatively, the log message combined with connection state event:
Statistics report:
Describe alternatives you've considered The statistics output is quite nice, but getting connection state change events currently requires manual parsing of the log messages.
Additional context Related to #908, and perhaps #55