On Thu, Mar 22, 2018 at 02:24:08PM +0100, Sven Dueking wrote:
> > > On Thu, Mar 22, 2018 at 12:34:29PM +0100, Sven Dueking wrote:
> > > > > On Wed, Mar 21, 2018 at 04:03:18PM +0100, Sven Dueking wrote:
> > > > > > > On Wed, Mar 21, 2018 at 03:00:37PM +0100, Luca Barbato wrote:
> > > > > > > > On 21/03/2018 11:46, Diego Biurrun wrote:
> > > > > > > > > What is it? libsrt or opensrt?
> > > > > > > >
> > > > > > > > You have an opensource implementation of the protocol SRT.
> > > > > > > >
> > > > > > > > I prefer to call it libsrt as configure option.
> > > > > > > >
> > > > > > > > > Where does the opensrt name come from?
> > > > > > > >
> > > > > > > > The protocol is srt (secure reliable transport), the
> > support
> > > > > > > > for it uses an external opensource implementation, as
> > > > > > > > mentioned in many
> > > > > > > places.
> > > > > > > >
> > > > > > > > I edited opensrt to libsrt for the configuration option
> > > > > > > > since it fits the normal pattern better. Probably to be
> > > > > > > > consistent
> > > > > renaming
> > > > > > > > all the other occurrences of opensrt to libsrt would be an
> > > > > option.
> > > > > > >
> > > > > > > I don't see the opensrt name appearing anywhere. Plain srt
> > > > > > > should
> > > > > be
> > > > > > > the name for an internal implementation, for external-
> > library-
> > > > > backed
> > > > > > > ones a lib prefix to the name of the protocol is appropriate.
> > > > > >
> > > > > > Haivison calls the packet OpenSRT and I think that´s a good
> > idea
> > > > > > to avoid any conflicts with SRT (subtitle).
> > > > >
> > > > > Umm, no?
> > > > >
> > > > > libav@libav-fate:/tmp$ git clone git://github.com/Haivision/srt
> > > > > Cloning into 'srt'...
> > > > > remote: Counting objects: 1565, done.
> > > > > remote: Compressing objects: 100% (34/34), done.
> > > > > remote: Total 1565 (delta 15), reused 16 (delta 8), pack-reused
> > > > > 1523 Receiving objects: 100% (1565/1565), 1.80 MiB | 1.44 MiB/s,
> > done.
> > > > > Resolving deltas: 100% (1042/1042), done.
> > > > > libav@libav-fate:/tmp$ cd srt/
> > > > > libav@libav-fate:/tmp/srt$ git grep -i "opensrt"
> > > > > libav@libav-fate:/tmp/srt$ git grep -i "open srt"
> > > > > libav@libav-fate:/tmp/srt$
> > > > >
> > > > > The library calls itself libsrt, the namespace prefix for API
> > > > > functions it uses is "srt_". Following that naming scheme on our
> > > > > side makes sense, let's just drop the "open" from file names,
> > > > > protocol names, and function names. We do that for all other,
> > similar, external libraries.
> > > >
> > > > We will change the name back to opensrt in all places.
> > >
> > > Thus completely breaking backwards compatibility and API? Then we
> > > should wait with this wrapper until that change in libsrt is done.
> > >
> > > Notice that protocols and (subtitle) demuxers live in different
> > namespaces.
> > > There is no conflict between an "srt" protocol (should be "libsrt" in
> > > this
> > > case) and an "srt" demuxer.
> >
> > But it's hellish confusing. Even opensrt is confusing, though.
>
> Any idea for a better name or shell we discuss this for the next days ?
Let me first state what the general naming scheme is: external wrappers
for "foo" get a "lib" prefix to "foo", e.g.:
gsmdec.c:
AVCodec ff_gsm_decoder = {
.name = "gsm",
libgsmdec.c:
AVCodec ff_libgsm_decoder = {
.name = "libgsm",
So here it should be libsrt.c and ff_libsrt_protocol and .name="libsrt".
Is there a problem with that naming scheme?
To clarify another question I have: Do you work on the Haivision SRT
implementation?
Diego
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
