Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Mon, Mar 26, 2018 at 11:37:49AM -0400, Sven Dueking wrote: > protocol requires libsrt (https://github.com/Haivision/srt) to be > installed Luca and I pushed a cleaned-up version of this yesterday. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On 26/03/2018 17:16, nablet developer wrote: names srt and libsrt were found confusing and misleading, because of similar acronyms used for other multimedia related things which are pretty well-known and wide-spread already (e.g. SRT subtitles or SRTP protocol). as result, maintainers/reviewers asked to change name to avoid confusion, and Haivision recommended to use "opensrt" naming in order to distinguish from other similar acronyms. One is SubRip text, quite a different beast. SRTP was already a bad name since RTPs and RTSP existed before and are even closely related. Right now I'm less concerned about spending time introducing yet another potentially unsearchable variant since gstreamer is using srt/libsrt since a while and just feeding any search engine worth its name with "srt protocol" produces non-misleading links. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On 26/03/2018 17:37, Sven Dueking wrote: protocol requires libsrt (https://github.com/Haivision/srt) to be installed Signed-off-by: Sven Dueking Signed-off-by: Luca Barbato --- From a quick search across engines: - "srt protocol" leads to the right thing. - gstreamer references srt/libsrt in their components and in their documentation. If there aren't other non-cosmetic issues I'd merge it with the libsrt namespace and be done with that. I might ask you help so we can have some additional information about how to properly use the protocol in the wiki. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Mon, Mar 26, 2018 at 10:16:06PM +0700, nablet developer wrote: > On 26-Mar-18 22:14, Diego Biurrun wrote: > > On Mon, Mar 26, 2018 at 11:37:49AM -0400, Sven Dueking wrote: > > > --- a/configure > > > +++ b/configure > > > @@ -4710,6 +4714,7 @@ enabled omx && require_header > > > OMX_Core.h > > > +enabled opensrt && require_pkg_config libsrt "srt >= 1.2.0" > > > srt/srt.h srt_socket > > Why do you call this thing opensrt when it calls itself libsrt? > > > names srt and libsrt were found confusing and misleading, because of > similar acronyms used for other multimedia related things which are > pretty well-known and wide-spread already (e.g. SRT subtitles or SRTP > protocol). as result, maintainers/reviewers asked to change name to > avoid confusion, and Haivision recommended to use "opensrt" naming in > order to distinguish from other similar acronyms. The problem is that Haivision does not use "opensrt" as name, they use "SRT/srt" and libsrt. Using a different name inside libav does not really help in reducing that potential for confusion. If Haivision recommends "opensrt", why don't they change the name of their library? Better yet, why don't they change the name of the protocol? Notice that what I gathered from the discussion was people complaining about the bad naming choice, not suggesting "opensrt" as the alternative. I have asked this before: what is your relationship to Haivision? Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On 26-Mar-18 22:14, Diego Biurrun wrote: On Mon, Mar 26, 2018 at 11:37:49AM -0400, Sven Dueking wrote: --- a/configure +++ b/configure @@ -4710,6 +4714,7 @@ enabled omx && require_header OMX_Core.h +enabled opensrt && require_pkg_config libsrt "srt >= 1.2.0" srt/srt.h srt_socket Why do you call this thing opensrt when it calls itself libsrt? names srt and libsrt were found confusing and misleading, because of similar acronyms used for other multimedia related things which are pretty well-known and wide-spread already (e.g. SRT subtitles or SRTP protocol). as result, maintainers/reviewers asked to change name to avoid confusion, and Haivision recommended to use "opensrt" naming in order to distinguish from other similar acronyms. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Mon, Mar 26, 2018 at 11:37:49AM -0400, Sven Dueking wrote: > --- a/configure > +++ b/configure > @@ -4710,6 +4714,7 @@ enabled omx && require_header OMX_Core.h > +enabled opensrt && require_pkg_config libsrt "srt >= 1.2.0" > srt/srt.h srt_socket Why do you call this thing opensrt when it calls itself libsrt? Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Thu, 22 Mar 2018 14:42:40 +0100 "Sven Dueking" 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" 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 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 it
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Thu, Mar 22, 2018 at 02:03:03PM +0100, wm4 wrote: > On Thu, 22 Mar 2018 13:17:16 +0100 > Diego Biurrun 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. Where exactly is the confusion? The file name(s)? Getting similar hits when doing git-grep? Some other thing? Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
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
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> -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" 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 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. > ___ > libav-devel mailing list > libav-devel@libav.org > https://lists.libav.org/mailman/listinfo/libav-devel ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Thu, 22 Mar 2018 14:24:08 +0100 "Sven Dueking" 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 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. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> -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 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 ? > ___ > libav-devel mailing list > libav-devel@libav.org > https://lists.libav.org/mailman/listinfo/libav-devel ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Thu, Mar 22, 2018 at 02:03:03PM +0100, wm4 wrote: > On Thu, 22 Mar 2018 13:17:16 +0100 Diego Biurrun 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. Do you see an alternative? It's not like I came up with the (sort of) duplicate name myself.. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Thu, 22 Mar 2018 13:17:16 +0100 Diego Biurrun 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. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
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. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> -Ursprüngliche Nachricht- > Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von > Diego Biurrun > Gesendet: Donnerstag, 22. März 2018 12:24 > An: libav development > Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol > > 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. > > Diego We will change the name back to opensrt in all places. > ___ > libav-devel mailing list > libav-devel@libav.org > https://lists.libav.org/mailman/listinfo/libav-devel ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
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. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On 21/03/2018 16:03, Sven Dueking wrote: -Ursprüngliche Nachricht- Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von Diego Biurrun Gesendet: Mittwoch, 21. März 2018 15:54 An: libav development Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol 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. Diego Haivison calls the packet OpenSRT and I think that´s a good idea to avoid any conflicts with SRT (subtitle). Then OpenSRT/opensrt is good for me as well. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> -Ursprüngliche Nachricht- > Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von > Diego Biurrun > Gesendet: Mittwoch, 21. März 2018 15:54 > An: libav development > Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol > > 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. > > Diego Haivison calls the packet OpenSRT and I think that´s a good idea to avoid any conflicts with SRT (subtitle). > ___ > libav-devel mailing list > libav-devel@libav.org > https://lists.libav.org/mailman/listinfo/libav-devel ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
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. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On 21/03/2018 11:46, Diego Biurrun wrote: On Wed, Mar 21, 2018 at 08:41:30AM +0100, Luca Barbato wrote: From: Sven Dueking protocol requires libsrt (https://github.com/Haivision/srt) to be installed Signed-off-by: Sven Dueking Signed-off-by: Luca Barbato --- Here the patch with all the changes folded in, I'll push it tonight if nobody has further comments. Did the new formats checklist get out of fashion lately? https://www.libav.org/documentation/developer.html#New-codecs-or-formats-checklist It isn't a format or a codec. What is it? libsrt or opensrt? You have an opensource implementation of the protocol SRT. I prefer to call it libsrt as configure option. Do you have to escape '&'? I don't remember offhand. IIRC @ is the only symbol that needs escaping in texinfo. 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. Sven what sounds better for you? lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
On Wed, Mar 21, 2018 at 08:41:30AM +0100, Luca Barbato wrote:
> From: Sven Dueking
>
> protocol requires libsrt (https://github.com/Haivision/srt) to be
> installed
>
> Signed-off-by: Sven Dueking
> Signed-off-by: Luca Barbato
> ---
>
> Here the patch with all the changes folded in, I'll push it tonight if
> nobody has further comments.
Did the new formats checklist get out of fashion lately?
https://www.libav.org/documentation/developer.html#New-codecs-or-formats-checklist
> --- a/configure
> +++ b/configure
> @@ -1371,6 +1372,7 @@ EXTERNAL_LIBRARY_LIST="
> libspeex
> +libsrt
> libtheora
> @@ -2522,6 +2524,8 @@ librtmpt_protocol_deps="librtmp"
> mmst_protocol_select="network"
> +opensrt_protocol_select="network"
> +opensrt_protocol_deps="libsrt"
> rtmp_protocol_conflict="librtmp_protocol"
What is it? libsrt or opensrt?
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -655,6 +655,145 @@ To play back the first stream announced on one the
> default IPv6 SAP multicast ad
> avplay sap://[ff0e::2:7ffe]
> @end example
>
> +@section srt
> +
> +Haivision Secure Reliable Transport Protocol via libsrt.
> +
> +The supported syntax for a SRT url is:
URL
> +@example
> +srt://@var{hostname}:@var{port}[?@var{options}]
> +@end example
> +
> +@var{options} contains a list of &-separated options of the form
Do you have to escape '&'? I don't remember offhand.
> +
> +or
> +
> +@example
> +@var{options} srt://@var{hostname}:@var{port}
> +@end example
> +
> +@var{options} contains a list of '-@var{key} @var{val}'
> +options.
> +
> +This protocol accepts the following options.
> +
> +@table @option
> +@item connect_timeout
> +Connection timeout. SRT cannot connect for RTT > 1500 msec
Connection timeout;
> +@item fc=@var{bytes}
> +Flight Flag Size (Window Size), in bytes. FC is actually an
ffs? loool ;)
> +internal parameter and you should set it to not less than
> +@option{recv_buffer_size} and @option{mss}. The default value
> +is relatively large, therefore unless you set a very large receiver buffer,
> +you do not need to change this option. Default value is 25600.
This sounds like it should not be a user-tunable parameter, but that
the implementation should take care of it instead. Oh well ..
> +@item inputbw=@var{bytes/seconds}
> +Sender nominal input rate, in bytes per seconds. Used along with
> +@option{oheadbw}, when @option{maxbw} is set to relative (0), to
> +calculate maximum sending rate when recovery packets are sent
> +along with main media stream:
with the
> +@option{inputbw} * (100 + @option{oheadbw}) / 100
> +if @option{inputbw} is not set while @option{maxbw} is set to
> +relative (0), the actual ctual input rate is evaluated inside
ctual?
> +@item maxbw=@var{bytes/seconds}
> +Maximum sending bandwidth, in bytes per seconds.
> +-1 infinite (CSRTCC limit is 30mbps)
> +0 relative to input rate (see @option{inputbw})
> +>0 absolute limit value
> +Default value is 0 (relative)
> +
> +@item mode=@var{caller|listener|rendezvous}
> +Connection mode.
> +caller opens client connection.
> +listener starts server to listen for incoming connections.
> +rendezvous use Rendez-Vous connection mode.
The values should have @option markup.
> +Default valus is caller.
s/valus/value/
> +@item mss=@var{bytes}
> +Maximum Segment Size, in bytes. Used for buffer allocation
> +and rate calculation using packet counter assuming fully
a packet counter
> +filled packets. The smallest MSS between the peers is
> +used. This is 1500 by default in the overall internet.
> +This is the maximum size of the UDP packet and can be
> +only decreased, unless you have some unusual dedicated
> +network settings. Default value is 1500.
> +
> +@item nakreport=@var{1|0}
> +If set to 1, Receiver will send `UMSG_LOSSREPORT` messages
> +periodically until the lost packet is retransmitted or
s/the/a/ I assume
> +
> +@item oheadbw=@var{percents}
> +Recovery bandwidth overhead above input rate, in percents.
> +See @option{inputbw}. Default value is 25%.
> +
> +@item passphrase=@var{string}
> +HaiCrypt Encryption/Decryption Passphrase string, length
> +from 10 to 79 characters. The passphrase is the shared
> +secret between the sender and the receiver. It is used
> +to generate the Key Encrypting Key using PBKDF2
> +(Password-Based Key Deriviation Function). It is used
Deriv_ation
> +only if @option{pbkeylen} is non-zero. It is used on
> +the receiver only if the received data is encrypted.
> +The configured passphrase cannot be get back (write-only).
s/get back/recovered/
> +@item recv_buffer_size=@var{bytes}
> +Set receive buffer size, expressed bytes.
> +
> +@item send_buffer_size=@var{bytes}
> +Set send buffer size, expressed bytes.
expressed in
> +@item rw_timeout
> +Set raise error timeout.
rw?
> +This option is only relevant in read mode:
> +if no data arrived in more than this time
> +interval, raise error.
> +
> +@item tlpktdrop=@var{1|0}
> +Too-late Packet Drop. When enabled on rec
