Using more C++ features about uvgrtp

[db-tech]

Hi there,

unfortunately that sound to me like "that" discussion that was discussed in the past a million times.
For me that often sounds like "why use new stuff if old stuff works" (no offense).

I don't said that C-style Code is by itself bad, but meant that new C++ features can be very beneficial.
As I said, reasons for that where discussed a million times all over the Internet so I won't start to list the benefits of certain features.
Of course we should only change what brings benefit.
I agree with @altonen that might would be an option to branch out the C++ compatibility stuff.

Fact is, this project was marked as C++17 in the CMake file and that is the primary reason why I decided I will probably spend a lot of time contributing if it is welcomed.
So I guess, It has to be decided at some point :-/

[lhp-git]

The C++17 mark was added in the CMake file with the 2.0.0 release.

When I started using uvgRTP, the 1.0.0 CMake file didn't have such a mark. C++17 wasn't a build requirement.

I agree with @altonen that uvgRTP cannot be stuck with C++11 compatibility forever.

I just ask for a smooth path

[altonen]

Hi,

my only concern is exactly that I don't want uvgRTP to be tied to C++11 forever. When that version is no longer supported, I don't know. Probably a very long time until we actually need to deprecate it.

And I agree that given that this is a C++ project, the code should utilize C++ features if they are useful. On the other hand, I can also understand the viewpoint that why fix something if it ain't broken (especially if the "fix" breaks something).

You both bring up important points but as I said, my only concern is that uvgRTP is tied to some version of C++ and that the version is dictated by some Linux distribution's software update cycle. I don't think that's fair either. I think @polusto and @fador should also chime in on this.

[fador]

Hi,

So a little background, we are a team working in Tampere University, Finland. I can be considered "head of technology" of the team and @polusto is the expert on the audio/video call systems. @altonen was the one who did the implementation while working for our team, he is no longer paid for that, but luckily he still finds some spare time to give support which I really appreciate!

uvgRTP was made because the "industry standard" live555 had it's problems with Kvazzup, it was hard to build with visual studio etc. We figured that we cannot be the only team working in this field having such problems.
It's actually great to hear other people might actually use this!

• The uvgRTP is publicly released on GitHub, with a license that allows it to be used in industrial projects. Do the owners of uvgRTP want it to be used in this kind of projects?

Yes we often work with industry and since this was made to replace live555, it makes sense that most of the people using it could use our implementation.

My fear is that a new C++ construct breaks the uvgRTP build with a C++11 compiler

I try to make sure we have some kind of support for C++11, since it causes this much discussion.
(I think we added C++17 mainly because of "easy solution" for the crypto++ headers, and we had no idea there were some users that might find this as a problem)

Anyway, I don't want to limit to C++11 forever either, but maybe we can find some solution for this problem. Also because we don't have any dedicated developers for uvgRTP at the moment, all the external support is valuable (although @polusto does need uvgRTP and is working on this at the moment).

Just some ideas, we are not limited to these:

• Not a fan of duplicate code but we could have two versions of some modules, where CMake could be used to compile one
• Same thing with macros, but the code readability is worse
• Separate branch for "to be deprecated" C++11, which we could still support somewhat
• Only new functionality (payload formats etc.) would use C++17 and those would be not compiled in when C++11 only detected

[db-tech]

Hi,

then I will give a little background on myself also and why I am involved in this discussion.

I am working in a "relative" big company as the head of development of our C++ team.
We are currently faced with the challenge of rebuilding a software from the ground up.
The main functionality (the core of almost everything) is the RTP functionality.

So we have two options

1. Creating our own library
2. Using something that already exists

I was looking at a lot of libraries (including but not solely live555) but non of them did fit our needs.
This had many reasons but the biggest one was code quality and code bloat.

This library stood out because is has a relatively clear code and the feature set would be a good start(and it was marked as C++).
Because a lot will depend on that part of the software, we would not only use the library but really working on it
to help making it stable, high quality and feature rich. (adding unit tests, spending work hours on it and so on)

We are currently still undecided because, although uvgRTP is really cleanly done and has good documentation, there are still several issues that have to be addressed (really not meant to be offensive, I like uvgRTP :-) ).

That's why I try to figure out where this library is heading before I spend a lot of time on it.

In Regards of your Ideas.

Not a fan of duplicate code but we could have two versions of some modules, where CMake could be used to compile one

Also not a fan and although this is possible, this might get hard to maintain. I guess it depends on what "some modules" are exactly

Separate branch for "to be deprecated" C++11, which we could still support somewhat

It's really hard to say if this is feasible, I guess I would need to spend some hours first to really dig into it, make some refactoring just for testing where there could be problems building with C++11

Only new functionality (payload formats etc.) would use C++17 and those would be not compiled in when C++11 only detected

That one would be bad news for us probably, because I think new features would be to dependent on old code. So my fear would be that we would be forced to create all new features in an older style to make it compatible and that would it make even harder to switch at some point.

Another thought is, the longer you wait for changes the more difficult it's going to be to change anything old.

My Ideas would be:

• Create a branch for the release that is still compatible with C++11
• For every bugfix that will be fixed in master, try to merge/cherry pick that fix in C++11 branch
• New features, enhancements should be done in master for C++ up to 17. If this feature/enhancement is C++11 compatible, merge it to the branch

Just some thoughts...
I will talk to my coworkers next week, maybe they have additional/better ideas.

[fador]

Nice to know a bit of your background too, things start to make sense!

I was looking at a lot of libraries (including but not solely live555) but non of them did fit our needs.
This had many reasons but the biggest one was code quality and code bloat.

So basically same as us, but we were already using live555 (or the live666 fork) and found it to be terrible in many ways, multithreading also caused some random problems for us..

My Ideas would be:

• Create a branch for the release that is still compatible with C++11
• For every bugfix that will be fixed in master, try to merge/cherry pig that fix in C++11 branch
• New features, enhancements should be done in master for C++ up to 17. If this feature/enhancement is C++11 compatible, merge it to the branch

This could work for us, even if it's a bit more work just to keep the C++11 supported, I think we have resources to handle it. Considering this "popularity" I might have to ask our professor if we could put some more effort into uvgRTP ;)

Does @lhp-git have anything to say to this, would it be okay to have this separate branch?

..and I cannot decide things on my own, but if @polusto also agrees, that should be enough from our side and we can think on how to actually manage this. Maybe we would have a new 3.0.0 dev branch as master and the old 2.x.x would be the C++11 compatible one.

[jrsnen]

I prefer C++ style code over C style code and I personally have no need to support C++11, but I'm open to supporting it if it is not too much of a hassle. I can see that @db-tech and I have many goals in common with uvgRTP and that makes me happy.

I will give my detailed comments tomorrow when I have more time to think about my answer.

[jrsnen]

That's why I try to figure out where this library is heading before I spend a lot of time on it.

Here are some of my background and my thought on the library's future. As @fador stated, uvgRTP was created for use in Kvazzup, a HEVC video call application (hopefully conferencing soon) mostly developed by me. @altonen was tasked few years back in solving RTP issues with Kvazzup, since that was the type of stuff he wanted to work on and he decided to create uvgRTP as a solution.

I took a pretty hands off approach myself to @altonen's efforts since I feel that kind of approach best suits academia.

As was stated @altonen left our group very recently and although he still contributes on his free time, I feel it has become my job to make sure uvgRTP is up to my own standards and the standards of potential users. This is because uvgRTP is an Ultra Video Group project created for the needs of Kvazzup. That being said @altonen's contributions are greatly appreciated and his opinion is valued highly when it comes to the future of uvgRTP.

The current state of uvgRTP is a mixed bag. The performance and documentation are excellent at the moment, which I really like. Unfortunately, enough testing has not been done to ensure that uvgRTP is bug/issue free.

The source seems really "C-ish".

When I started looking at the code last week, I noticed the same. I myself am much more familiar with C++ than C style code.

My own task in the group is to make Kvazzup into a working video conferencing application that is competitive with at least the open-source alternatives (buggy and bloated) and also preferably the commercial alternatives as well (or at least this is how I see it). One aspect which is critical for these goals is making Kvazzup bug free and the current state of uvgRTP stands in the way of this goal.

This is why I started working on uvgRTP last week. My goal was to first refactor as much as I can and and reduce bugs that way (no direct plan, just doing things that make sense to me like removing duplicate code) and then fixing rest of the bugs that were not fixed by refactoring. I also started considering converting the C style code at least partially to C++ (at least using smart pointers), so I'm definitely not against someone else doing this.

I am a lone developer who also other responsibilities (mainly Kvazzup) so my time I can work in uvgRTP is limited. It seems I was planning on doing similar things that you @db-tech were planning, but on a smaller scale. I have no direct need for new features at this point, but I'm definitely not against including them if the don't make the code too messy.

I need uvgRTP to:

• Be bug free
• Work on MSVC, GCC and MinGW compilers (C++17 version is enough). I can see myself dropping support for MinGW if it becomes too much of a hassle.
• Have high performance for something like 8K real-time video calls and maybe something like 4K video conferences.
• Support current features.
• Work well with ICE and Kvazzup in general.
• Be easy to use and update.
• I don't want uvgRTP to constantly deprecate its public API, but I could see justifications for one big change with a version change.

As @fador stated, we as a group are very open for industrial collaboration and we frequently have projects with industry and also collaborate with them on research. Our professor is the best person to contact on these matters.

As for the C++11 question:

The C++17 mark was added in the CMake file with the 2.0.0 release.

I don't think there is any deep thought or decision behind the C++17 flag. There was the __has_include that I think needed it and that's why it was added. Then after that @lhp-git wanted uvgRTP to support C++11 and did a pull request for that support, which I accepted, since it didn't seem too large of a code duplication and was making one user of uvgRTP happy.

How I see uvgRTP is that it was started in 2019 and I don't feel we should be obligated to support compiler that came long before it. Of course we want to be accommodating to our users on older systems and maybe a separate branch would be a good option. I can see how a separate branch would work, but I have no experience on such development methods in practice so I will probably need to discuss this a little bit more with the team and @fador.

[db-tech]

From what I am hearing, I agree that we might have the same mindset regarding development in general.

I don't want uvgRTP to constantly deprecate its public API, but I could see justifications for one big change with a version change.

I agree that it would probably the best to to one big refactoring change so there are not those big changes over a long period of time.
We are experienced c++ developers and have the blessing to be able to use the newest C++ standards at work, even C++ 20 features (which are awesome by the way :-) ).
So we certainly could help with getting things clean.
But we are by no means experts in RTP. We have a lot to learn in this regard, so it might also be beneficial for us to know some experts in that field :-)

If we decide to use this library for our project, we could talk to our superior to officially spend dedicated working ours for this lib.
At least for the period of time until the lib is stable, bugfree, tested and has the features we need.

It might even be helpful and nice to have a realtime online meeting to discuss some topics directly.

[jrsnen]

Any help with uvgRTP is greatly appreciated.

It looks like we are heading in the direction of c++11 being its own branch when the time comes to start adding c++ 17 features. Probably its easiest if we first focus on improving non 17 aspects of uvgRTP and after that point we can handle porting at least the bug fixes to the c++11 branch.

Online meeting is certainly possible. I wouldn't call myself an expert, but I have done some work with RTP before. We could also ask @altonen, if he wants to join the meeting since he seems to have personal interest on progression of this project. @fador might also want to join.

As an additional note, there exists a paper on uvgRTP, which might be of interest. We have also successfully entered an open-source competition with uvgRTP at a conference held next month.

[db-tech]

Probably its easiest if we first focus on improving non 17 aspects

Agree, if I have the time I would maybe start by changing some raw pointers to unique pointers and adding some RAII functionality. We'll see how well this does work and how easy we can refactor stuff.
First I would like to create tests, but I will create a separate issue for it.

Online meeting is certainly possible

Ok, not sure how to reach you. You could just grab my mail from biber-tech.com or contact me via https://whatsyourfavorite.net/
And while I'm at it throwing links ;-)... If you are interested in some new C++ features you could check out our hobby project https://codingcards.org

As an additional note, there exists a paper on uvgRTP, which might be of interest

Yeah thanks, I will definitely check that out.

[lhp-git]

Sorry I couldn't answer earlier, but I don't have much free time at the moment.

This discussion is very interesting.

The project I work on is a live capture and streaming application.
I used live555 at the beginning but this library offers only a pull model to fetch the data to stream (no push_frame()), and it is an RTSP server, which is not bad by itself but I didn't want the stream receiver to know the server IP adress, only the multicast adress of the stream.

I found two potential replacement library : uvgrtp and GStreamer. I retained uvgrtp because it is easy to use, supports what I need (H265 payload), has a push model and runs on CentOS7 (at least the 1.0.0 version), which is the OS my application shall run on. I didn't switched to GStreamer because of its hard learning curve.

From the above comments, I am ok with @polusto when he said : "Probably it's easiest if we first focus on improving non 17 aspects of uvgRTP and after that point we can handle porting at least the bug fixes to the c++11 branch."

I understand that uvgRTP is a young project, and supporting an "old" compiler isn't very exciting.
Some industrial developments use "industrial" OS that are very stable but are very late compared to the latest OS available today.

Thank you for not rejecting my request

[jrsnen]

My email seems to be found here: https://www.tuni.fi/en/joni-rasanen for anyone wanting to contact me.