[libav-devel] [PATCH] Add Haivision Open SRT protocol

wm4 nfxjfg at googlemail.com
Thu Mar 22 14:37:40 CET 2018


On Thu, 22 Mar 2018 14:24:08 +0100
"Sven Dueking" <sven at nablet.com> wrote:

> > -----Ursprüngliche Nachricht-----
> > Von: libav-devel [mailto:libav-devel-bounces at libav.org] Im Auftrag von
> > wm4
> > Gesendet: Donnerstag, 22. März 2018 14:03
> > An: libav-devel at libav.org
> > Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> > 
> > On Thu, 22 Mar 2018 13:17:16 +0100
> > Diego Biurrun <diego at biurrun.de> 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 at 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 at libav-fate:/tmp$ cd srt/
> > > > > libav at libav-fate:/tmp/srt$ git grep -i "opensrt"
> > > > > libav at libav-fate:/tmp/srt$ git grep -i "open srt"
> > > > > libav at 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 ?

There's a lot of names you could come up with. Personally I think that
something like "hosrt" or "haisrt" would already sound very different
from the SRT subtitle format or RTP variants, so that no confusion can
happen.


More information about the libav-devel mailing list