On 26/02/17 11:14, Nicolas George wrote: > L'octidi 8 ventôse, an CCXXV, Mark Thompson a écrit : >> And what would the user conclude from that message? Have they done >> something incorrectly? If so, what? Or is it a bug in the filter? >> All of these messages pretty much require reading the source code and >> looking at the documentation for the relevant libmfx function to >> determine what they mean. (Well, maybe not "out of memory".) > >> I disagree. For normal output, yes, this sort of thing is unhelpful. >> For fatal error cases, precise information such as error codes should >> be provided so that someone reading the source code can determine >> exactly what the error was and where it happened. > > Anything above the verbose level is meant for users, not just > developers. If reading the source code is necessary to understand it, > then you are doing something seriously wrong.
I suspect that the thing I am doing seriously wrong is attempting to use an opaque proprietary library which has more complex semantics than we can sensibly express. > If the error results from invalid parameters set by the user, then the > error message should say so, possibly stating what parameter and its > acceptable values. For this sort of thing the set of acceptable inputs is not well-defined, unfortunately. (My original problem - seemingly some apparently-equivalent dxva2/qsv surfaces are more equal than others, in a way I am as-yet-unable to determine.) > If the error results from external (hardware or system) problems, then > the error message should say so, pointing to the cause of the problem. > > Otherwise, the error should clearly state that it is a BUG, and suggest > the user to report it, along with diagnostics relevant for the > developers obtained at loglevel debug. Would you prefer something like "external error: MFXVideoVPP_RunFrameVPPAsync returned error code %d", which would emphasise the origin of the problem? _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
