[FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system

[wm4]

On Mon, 11 May 2015 17:06:50 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Mon, May 11, 2015 at 03:43:18PM +0200, Nicolas George wrote:
> > Le duodi 22 floréal, an CCXXIII, Clement Boesch a écrit :
> > > > also the message may originate from a libavcodec used by another lib
> > > > instead of the user application
> > > > 
> > > > I think the average user would benefit from having the option dispayed
> > > > with a exactly useable as is syntax
> > > 
> > > I support this as well. No opinion on the API itself.
> > 
> > Theoretically, that is true. In practice, there are dozens of things that
> > would benefit the user in this area. The most obvious one is of course:
> > having the error message in their native tongue instead of English.
> > 
> > There is a hard design problem in the error reporting mechanism.
> > 
> > The issue that lead to this discussion is the tip of the iceberg. Not even
> > that, is is just a tiny ice peak near the surface amongst dozens of similar
> > and more pressing issues. We are only discussing it because someone had too
> > much free time this week-end and decided to bikeshed Carl Eugen's wording.
> > 
> > Attacking the issues one at a time and addressing them the quick-and-dirty
> > way will only make it that much harder to overhaul the system cleanly.
> 
> does someone intend to actually work on a overhaul and is such
> overhaul actually wanted and usefull, what would it involve?
> 
> is it likely that such overhaul would also fix the issue of
> user application specific option translation?
> 
> if noone will ever do an overhaul then its a fairly bad idea to wait
> for it

In Libav there are plans to make the av_log callback non-global. Then
your current patch might be helpful.

I don't think it's feasible to solve this problem "perfectly", as a
certain someone else is suggesting. This would cause lots of complexity
for little gain.

The correct solution in this specific case is IMHO requiring the API
user to provide a callback for opening further files, instead of
somehow hardcoding lots of policy in libavformat (and then adding
options and log messages to allow the user to interact with it).

If you want a quick and dirty solution, I'd at least word it like "set
the libavformat use_absolute_path option to 1".

> 
> > 
> > So the real question is: is the benefit worth the cost?
> > 
> > The benefit here is: in a few fringe cases, avoid users who do not know it
> > already to look in their application help system how to set a lavf option.
> 
> this assumes it is documented, that they know where or for what to
> search and that they find it.
> as a quick test one could ask a random user to find the page in
> each projects documentation from the error message this thread is
> about. That is the documentation of mplayer, mpv, vlc and gstreamer
> just to pick some random apps
> and look at the clock how much time that did cost to find
> also their subjective oppinon would be interresting to hear if they
> consider it worth it to instead print directly usable syntax
> 
> 
> > 
> > Well, IMHO, no, the benefit is not worth the cost. Not by far.
> > 
> > Of course, if someone comes up with an idea that really enhances the error
> > reporting system that would, as a side effect, fix this negligible issue, I
> > would wholeheartedly support it. But I am sorry to say that despite all my
> > efforts, I have still not come up with a satisfactory solution for error
> > reporting.
> 
> 
> 
> 
> > 
> > Regards,
> > 
> > -- 
> >   Nicola George
> 
> 
> 
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
>