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

wm4 nfxjfg at googlemail.com
Thu Mar 22 14:55:16 CET 2018


On Thu, 22 Mar 2018 14:42:40 +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:38
> > An: libav-devel at libav.org
> > Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> > 
> > 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.  
> 
> Thanks much for your personal, but I disagree and still think opensrt is fine. I really see no reason why this should confuse users and any relation to RTP. Besides this, I send this patch to FFMPEG month ago and you didn´t response about the name. Looking for forward to get more feedback from the community about the name of this lib, since it seems to be very important.

Well, it was always confusing. At first I thought it was a patch for
some modification of the SRT format, and wondered why that would need
an external library.


More information about the libav-devel mailing list