On Thu, 22 Mar 2018 14:42:40 +0100
"Sven Dueking" <s...@nablet.com> wrote:

> > -----Ursprüngliche Nachricht-----
> > Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von
> > wm4
> > Gesendet: Donnerstag, 22. März 2018 14:38
> > An: libav-devel@libav.org
> > Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> > 
> > On Thu, 22 Mar 2018 14:24:08 +0100
> > "Sven Dueking" <s...@nablet.com> wrote:
> >   
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag
> > > > von
> > > > wm4
> > > > Gesendet: Donnerstag, 22. März 2018 14:03
> > > > An: libav-devel@libav.org
> > > > Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> > > >
> > > > On Thu, 22 Mar 2018 13:17:16 +0100
> > > > Diego Biurrun <di...@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@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  
> > ?
> > 
> > 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.
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to