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