GNOME Bugzilla – Bug 638663
RFC: track bus (error,warning,info) messages in discoverer
Last modified: 2018-05-06 16:52:41 UTC
Created attachment 177485 [details] [review] track bus (error,warning,info) messages in discoverer Gather messages from the bus and add API to access them. I'd like to have this for gst-mediainfo to be able to show if media is in perfect shape or e.g. if there are some quirks (odd length chunks, inconsistent fields etc.).
An example of the output after the patch has been applied would be: Analyzing file:///xxx/yyy/zzz Done discovering file:///xxx/yyy/zzz An error was encountered while discovering the file Messages: Error: decodebin21: Your GStreamer installation is missing a plug-in. ../../../gst/playback/gstdecodebin2.c(3137): gst_decode_bin_expose (): /GstPipeline:Discoverer/GstURIDecodeBin:discoverer-uri/GstDecodeBin2:decodebin21: no suitable plugins found Warning: discoverer-uri: No decoder available for type 'text/uri-list'. ../../../gst/playback/gsturidecodebin.c(756): unknown_type_cb (): /GstPipeline:Discoverer/GstURIDecodeBin:discoverer-uri
Not so fond of this. IMHO: - errors should be notified via the GError * - missing plugins should be (are already?) notified via dedicated API - quirks should not be notified to the app via GST_ELEMENT_{ERROR,WARNING,INFO} - these are meant for translated messages shown to the user - quirks should be notified to the app via new dedicated messages which contain more structure (codes/categories/tags) so can be handled programmatically if desired. - even if quirks/recoverable parsing errors are currently notified via GST_ELEMENT_{WARNING,INFO}, this isn't really right IMHO and should be replaced by a better mechanism. Not that I'm against adding this API to retrieve ERROR/WARNING/INFO messages per se, it's just that it seems to me that it's being suggested for the wrong reasons.
So we agree that the elements should use something that uses a GError (which includes a domain, code and message), but not the GST_ELEMENT_{ERROR,WARNING,INFO} macros? Would it be okay to use GST_MESSAGE_{ERROR,WARNING,INFO}? That's basically the part I need. If not, I would suggest that someone clarifies the purpose of GST_MESSAGE_[WARNING,INFO} in the API docs. The benefit of getting this info to the app over the bus (instead of just having it in the log) would be that apps can indicate to the user that one media file might not work perfectly (e.g. it contains inconsistent info and the implementation made the wrong decision).
> So we agree that the elements should use something that uses a GError (which > includes a domain, code and message) I'm not sure of that. I think just a code + message doesn't provide enough detail and leaves no room for expansion (also, I don't think we want to expose loots of these codes in core header files). I think we'd want such things to be machine-processable and more structured, not just free-form string messages to the user. e.g. if we're not reading some Qt Atom because it's broken or we can't handle it we might want to say which atom it is (just a random example why I don't think just a code is enough). I have no specific ideas about how to do this exactly though. Someone would need to go through the code and get the various GST_WARNING/GST_ERROR/GST_ELEMENT_WARNING to make a list of possibilities. (Also, the scope isn't quite clear yet, e.g. is it only brokenness or would such an API also be used to signal whether an index is present, for example?) > GST_ELEMENT_{ERROR,WARNING,INFO} > macros? Would it be okay to use GST_MESSAGE_{ERROR,WARNING,INFO}? That's > basically the part I need. If not, I would suggest that someone clarifies the > purpose of GST_MESSAGE_[WARNING,INFO} in the API docs. It's not about the macros, but the messages for me. I don't know what the original intention was when they were added, but they are clearly for alerting the user of things. But most of the stuff we're talking about here "the user" does not really need to know. > The benefit of getting this info to the app over the bus (instead of just > having it in the log) would be that apps can indicate to the user that one > media file might not work perfectly (e.g. it contains inconsistent info and the > implementation made the wrong decision). I agree that there would be benefits in exposing such info to the application (via the bus), it's just that I don't think GST_MESSAGE_{ERROR,WARNING,INFO} isn't the right vehicle for that.
So maybe we need a element_{error,warning,info} or internal_{error,warning,info} athough it is still not easy to draw the line between the new messages and the old messages. It is so that one is a user_{e,w,i} and the other is an app_{w,e,i}. The app-messages would not be translated and would be meant for internal processing by the application. If the application would like to inform the user, the app would need to map it to user error messages and handle the i18n itself? The macros have the nice side effect of being convenient to use output to the log at the same time. Of course the nexw facillity could offer the same comfort.
Tim, Stefan, Do we still want this ? Is it not a more generic issue ?
Lets close.