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
