On Sun, 5 Feb 2017 14:56:26 +0100
u-9...@aetey.se wrote:
> Hello Mark,
>
> On Sun, Feb 05, 2017 at 12:12:37PM +0000, Mark Thompson wrote:
> > On 05/02/17 10:02, u-9...@aetey.se wrote:
> > > To make it a bit more clear, my use case is
> > >
> > > - various devices and videobuffers
> > > - different applications which are not feasible to patch/teach/replace
> > >
> > > Replacing ffmpeg with something else or modifying the applications
> > > unfortunately does not fit there, that's also why get_format() does not
> > > help.
>
> > Even if you need to support such a use-case, doing it via the get_format()
> > callback is still the right thing to do. Once you've done that, all normal
> > applications (including ffmpeg.c itself) can use the standard API as it
> > already exists to set the output format. For your
> > decoding-into-framebuffer case the calling application must already be
> > fully aware of the state of the framebuffer (after all, it has to be able
> > to make a suitable AVFrame to pass to get_buffer2() so that you can avoid
> > the extra copy), so adding get_format() support to also communicate the
> > format is not onerous.
>
> Note that it is generally impossible to let the application decide
> what to choose. Sometimes this may work, but the applications lack
> the relevant needed knowledge, which is not guessable from
> "what the layers before and after me report as supported formats
> in a certain order".
>
> > Then, if you have a proprietary application which cannot be modified
> > because you don't have the source, you could make a shim layer like:
>
> Proprietary or not, I can hardly modify them.
>
> A shim layer is certainly a possible workaround, but from my
> perspective it would be "moving from a mildly inelegant
> to a basically broken and unreliable technology".
>
> The problem is
> <offtopic - system administration>
> the technology of LD_*, an old and really bad design by itself.
> Compared to a _library_specific_ envvar it is a long way father
> from being usable as a general solution.
> Note that an LD_* variable affects _linking_ (which is very intrusive)
> for _all_ programs, related or not, in all child processes.
> Note also that some applications do play tricks with LD_* on their own.
> Have I said enough? :(
> </offtopic>
>
> > static enum AVPixelFormat get_format_by_env_var(pix_fmt_list)
> > {
> > requested_pix_fmt = getenv(SOMETHING);
> > if (requested_pix_fmt in pix_fmt_list)
> > return requested_pix_fmt;
> > else
> > error;
> > }
>
> Exactly, but in my situation it is much more robust and easier to
> enable the corresponding code in the decoder (or even add it there on
> my own in the worst case) than play with binary patching on the fly,
> which dynamic linking basically is.
>
> So instead of forcing the possible fellow sysadmins in a similar situation
> to patch, it would we nice to just let them build lilbavcodec with
> this slightly non-standard (and pretty safe) behaviour.
>
> > and LD_PRELOAD it into the application to achieve the same result (insofar
> > as that is possible - it seems unlikely that it will be able to use
> > get_buffer() appropriately, so there are probably going to be more
> > redundant copies in the application and you would need to patch it directly
> > to eliminate them).
>
> You see.
>
> In any case, thanks for understanding the original problem.
I think you don't get it. There will be no such environment variable
use in the libraries, ever. The discussion about this was over a long
time ago.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
