On date Saturday 2011-05-28 06:57:10 -0400, Ronald S. Bultje encoded: > Hi, > > On Sat, May 28, 2011 at 5:43 AM, Stefano Sabatini > <[email protected]> wrote: > > * the function code knows exactly why the failure happened, and can > > provide useful hints for spotting the problem, which can't be done > > in the calling code. > > We can log this under NULL, AV_LOG_DEBUG or even as a av_dlog() message... > > The problem goes both ways. The function doesn't know the context in > which the parsing happened (was it the UI using the API for some > preference box?
The calling function can provide such a context, with a further log message. > Or libavfilter internal setup? Or a developer testing > a new feature he's developing and screwing up a test? Or a user typing > an invalid ffmpeg -x parameter?). But the caller doesn't know the > detailed reason why it failed. > > Generally the user cares more about the context (and then can figure > out why 320c240 wasn't a valid size, oh, it should be s/c/x/ - typo). With number parsing it is more complicated, the failure may depend on an invalid range, on a typo, or on the parsed number not being an integer, discovering the reason of the failure requires duplicating the logic in the called code, if you don't report the failure you have a poor feedback (and I don't want to duplicate the error reporting every time I use that function, check ffmpeg for an example). > Developers can use av_dlog() messages with DEBUG defined. So there is > something to say for it. Whatever you guys prefer is fine with me, I'd > have a slight preference for the part where you have a simpler (so 4- > instead of 6-argument API), but don't care much. I believe the two parameters are a modest price for the added flexibility/functionality. -- FFmpeg = Fascinating and Fierce Monstrous Pitiful Experimenting Guru _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
