> -----Original Message-----
> From: libav-devel [mailto:[email protected]] On Behalf Of
> Kravchenko, Alexander
> Sent: February 27, 2018 8:59 AM
> To: libav development <[email protected]>
> Subject: Re: [libav-devel] [PATCH] AMF SDK integration code cleanup: remove
> writer_id option & move AMF_COMMON_OPTIONS out from amfenc.h
>
> >
> > Hi, I thought the library user would like to have a separate writer_id
> > since I assumed that the identifier is used for logging and resource
> > accounting purposes (e.g. browsers using this backend might want to
> > use a separate identifier per-tab).
> >
> > The common options pattern is used when there are multiple codecs
> > relying on the same backend. I would expect to have the common options
> > expanded instead of dropped, what are your plans exactly?
> >
> > lu
> >
>
> Hi,
>
> 1) AMFTraceWriter is abstraction to configure how AMF outputs its logs for
> current process, not for component.
>
> Example instances of AMFTraceWriter can be
> * FileWriter
> * SocketWriter
> * DebugOutputWriter
> * LibavWriter (output using av_log function).
>
> AMFTraceWriter can be Registered/Unregistered/Enabled/Disabled and
> configured to output particular level of trace output.
>
> If we use multiple LibavWriter objects in one process, we will have
> duplication of output in avlib log.
> To prevent this scenario we should use one constant writer_id .
>
> 2) AMF_COMMON_OPTIONS in header. It is more about balance between
> preventing duplication and code readability and visibility.
> IMHO minor duplication is less important than core readability and visibility.
> I'd recommend to have property map for each component in one place.
>
>
To address the issue of uniquely identifying a component/codec/filter shouldn't
we add some common mechanism?
Imagine that an app has two x264 encoders and wants to distinguish traces for
each one.
If every component will have own system of identification it will be very hard
to use.
Mikhail
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
