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

Diego Biurrun diego at biurrun.de
Thu Mar 22 14:24:01 CET 2018


On Thu, Mar 22, 2018 at 02:03:03PM +0100, wm4 wrote:
> 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.

Do you see an alternative? It's not like I came up with the (sort of)
duplicate name myself..

Diego


More information about the libav-devel mailing list