Preparing for 6.0.0 release #960

paulpv · 2024-01-11T05:33:15Z

Tweak libndi-get.sh
Tweak CMakeLists.txt
Tweak readme
Bump OBS-NDI version to 6.0.0
Rebrand from Stéphane Lepin stephane.lepin@gmail.com to OBS-NDI Project obsndi@obsndiproject.com
Add Discord link in app
Major cleanup of strings
Update to NDI SDK 6.0.1
Update Config logic to match obs-websocket
Add a --obs-ndi-verbose command-line option to print out 'a' and 'v' for audio and video packets respectively

Also making Config code similar to `obs-websocket`'s code

...and not legacy NDI 4 `ndi_hwaccel`. According to their docs and forum posts there is supposedly no way to un-set this.

The current code either packages a .msi **or** generates a .zip. Many users prefer the zip (and it has the benefit of mitigating code signing warnings). This change always generates the .zip file. If `-BuildInstaller` is also specified then is **also** builds a .msi.

Also having urls launch a much more consistent way in output-settings, obs-ndi-filter, and obs-ndi-source. Commenting out currently unused obs_log(...) method. That method allocates and frees a formatting template every time it is called. All just to prefix the plugin module name in a `blog` output. obs-ndi `blog` already exhaustively prefix the module name, so this convenience function is unnecessary for now. If logging consistency ever gets out of hand then this could be uncommented and used.

Also making Config code similar to `obs-websocket`'s code

...and not legacy NDI 4 `ndi_hwaccel`. According to their docs and forum posts there is supposedly no way to un-set this.

The current code either packages a .msi **or** generates a .zip. Many users prefer the zip (and it has the benefit of mitigating code signing warnings). This change always generates the .zip file. If `-BuildInstaller` is also specified then is **also** builds a .msi.

Also having urls launch a much more consistent way in output-settings, obs-ndi-filter, and obs-ndi-source. Commenting out currently unused obs_log(...) method. That method allocates and frees a formatting template every time it is called. All just to prefix the plugin module name in a `blog` output. obs-ndi `blog` already exhaustively prefix the module name, so this convenience function is unnecessary for now. If logging consistency ever gets out of hand then this could be uncommented and used.

paulpv · 2024-05-10T19:18:28Z

For anyone reviewing this:
I think we are fine here, but just to be safe, please look out for any master code that I might have unintentionally reverted in this PR (ex: due to a possible merge mistake).
The only one that comes to mind is https://github.com/obs-ndi/obs-ndi/pull/954/files, but that looks fine to me in this PR, but I just wanted to be sure I didn't accidentally miss or revert anything.
This is a little complicated (but actual usual coding IMO) because some things on master I have already improved on this develop branch, but it is possible some more recent desired changes on master might have been reverted in this branch...ie possible logical conflicts.

I am 100% aware that this PR is non-trivial (I hesitate to call it "large"; I have seen some crazy large PRs way bigger than this) and there is a reason why PRs should be small.

Sorry for the below "rant"...

I also am not a big fan of the branching strategy used here that is probably all my fault.
Almost everyone opening PRs targets the default master branch (understandably because that is the default branch).
That complicates things when another branch, develop, is intended to be the leading edge next release.
This requires the usual day-to-day task of merging master back into develop.
This is not a big problem, but does open up the possibility of accidentally reverting changes on master if they conflict with similar changes on develop.

My main gripe about our branching is that I am of the personal understanding/camp/belief/religion that everything on our master branch should be [reasonably] immediately ready for release.
That may sound a little odd/backwards/misguided to many people smarter than me, but let me explain.

For the record, I work at a company that does the opposite: our master is leading edge code that may not be ready for release; when it finally is ready for release we create a release branch and then increment the master version number to the next release version number; we only ever release a build from the release branch.

master = 1.2.0

create 1.2.0 release branch

increment master to 1.3.0

if 1.2.0 needs a patch, branch a 1.2.1 release branch from 1.2.0 and work and release that.
This seems similar to how OBS does it: https://github.com/obsproject/obs-studio/branches/all

My understanding of how many Open Source projects on GitHub work (but perhaps not OBS Studio) that get lots of contributors is that most of them only ever release from master.
In fact, GitHub calls this GitHub Flow: https://docs.github.com/en/get-started/using-github/github-flow

fork repo
on fork, branch feature from master
work feature
open PR to upstream master
merge fork feature to upstream master
This process repeats until eventually a release tag is created and a release is built and released
Simple (but rarely are things always that simple)

This tells me that master should always be in a shippable state.
(Maybe there is a [not so] subtle difference between "should always be in a shippable state" and "should always be [reasonably] immediately ready for release"...the latter implies that all version numbers defined in the code are set/incremented correctly)

What this does not tell me or the uninformed reader/developer is how to actually release.
When a feature PR is merged to master, that contributor most likely did not increment in their branch any version number defined in the code on master.
So now the master still says it is the old version (ex: 1.2.3), but now it has new code in it and is still the old version number.
So now the version number on master needs to be incremented.
So now you [should] need to create a feature branch from master to increment the version number to 1.2.4 and then merge that back to master and THEN you can release the code.
I personally find this unintuitive, highly confusing, and non-ideal.
My understanding is that this is how most simple Open Source projects on GitHub work.
I would be wrong.

Speaking of I could be wrong, I think that is how the OBS-NDI repo has historically worked before I got involved.

When I started to get involved I unfortunately approached using this repo with a type of GitFlow mindset.

Simplified:

branch develop from master
branch feature1 from develop
work feature1
merge feature1 to develop
branch feature2 from develop
work feature2
merge feature2 to develop
prep develop for release
merge develop to master
release master

I am not going to get into any [religious] arguments about the pros or cons of GitFlow, I am just saying factually that I did try, right or wrong, to start using it in the OBS-NDI repo...and I kind-of regret that.

I now believe that GitFlow does not work very well in an Open Source project where most code contributors don't know to follow GitFlow. GitFlow would only work if everyone follows it, like at a small team at a company where everyone understands their Way Of Work and there are no outside contributors. If someone on a GitFlow team starts branching feature PRs from master (instead of develop) and merging them to master (instead of develop) then that entirely breaks GitFlow.

One way to mitigate this in an Open Source project might be to make the develop branch the default branch, but that might still confuse people; human nature seems to be that most non-professional developers instinctively just want to branch from master by default and may even intentionally go out of their way to change their PR from [the default] develop back to master.
I thought there once was a repo setting that allowed you to enforce GitFlow and define your branches, but I don't see that anymore.

People are going to be people. People are going to ignore GitFlow.

So, this is a big long rant to say that I am open to future healthy constructive conversations about a better git branching/releasing strategy for OBS-NDI, but unless I hear any better ideas I am going to stop using a develop branch and go back to using a basic GitHub Flow with its awkward [to me, unless I am probably missing something obvious] release steps.

Perhaps we may eventually go to a more OBS-Studio type of flow (and what I also use at work) of also having a release branch (RB), and when that RB is created then the master is incremented to the next version that will be eventually be released in the future.

Apologies again for the rant! :)

Trouffman · 2024-05-10T22:47:02Z

Tbh, if we want ppl to submit to a specific branch we have to really make it clear.
Example, even myself though that you were using the develop branch mostly for you, so contribution were sometimes sent to master instead.

I have no specific preference, as long as it is clear / documented on how to contribute.

Trouffman · 2024-05-12T04:35:15Z

Some update :
After reading through the changes support and suggestion.

I believe we should keep master for : whatever is the latest OFFICIAL tagged release. And push dev PR to the develop branch as initially expected. (to-do ; document in the dev wiki)

The main reasons are :
-> the github default repo Page will ALWAYS have the latest stable infos (Important! as this is what people will see first, and if we have a "massive" rework then, this can be done "easy peasy" in the develop branch without impacting regular (non dev/contrib) users.

Other main argument :

we refer to the install script directly from the repo (master branch) > If this was to change based on the "flavor of the moment", then that would be a pain.

And YES there might be time where we might have to update master branch even if this is not a full release. But this is an extrem use-case.

Correcting typos & nitpicking.

data/locale/ca-ES.ini

data/locale/en-US.ini

data/locale/fr-FR.ini

paulpv · 2024-05-13T06:12:58Z

@Trouffman please review my recent translation updates.
Thanks

Trouffman

The proposed translation works as well - (seems to be more consistent with previous translations)

that was for the translation only - still have 2 files to review

Trouffman · 2024-05-14T13:25:38Z

data/locale/en-US.ini

+NDIPlugin.SourceProps.LatencyMode="Latency Mode"
+NDIPlugin.SourceProps.LatencyMode.Normal="Normal (safest/recommended)"
+NDIPlugin.SourceProps.LatencyMode.Low="Low"
+NDIPlugin.SourceProps.LatencyMode.Lowest="Lowest (unbuffered; Alpha channel not supported)"
 NDIPlugin.SourceProps.Audio="Enable audio"
 NDIPlugin.SourceProps.PTZ="Pan Tilt Zoom"


This is confusing when displayed in the UI.
Should be : PTZ control

Trouffman

Seem that the basics are working.
I have tested getting & sending on

MacOS - Apple Silicon

Left to test : win10-11 & linux

PTZ could not be tested.

paulpv and others added 24 commits November 14, 2023 01:25

Add obs-ndi plugin version to NDI Output Settings dialog title

fbf7c7d

Check for Qt >= 6 during obs_module_load

7740931

Tweak readme a little

69bdbe8

Fix title in NDI Output Settings

cf36163

Add --obs-ndi-verbose command-line

3d78040

Also making Config code similar to `obs-websocket`'s code

Add missing verbose a/v logging for non-framesync

bb7a1c8

Update hw_accel to use NDI 5 ndi_video_codec metadata

61f4d05

...and not legacy NDI 4 `ndi_hwaccel`. According to their docs and forum posts there is supposedly no way to un-set this.

Fix [lack of] char* casting error

e92ff52

github: update FUNDING file

c1217de

[FIX] Transparent background for NDI latency mode low is back.

c489aad

[UPDATE] Added disclaimer to latency mode 'Lowest'

2e848bf

[UPDATE] update version number

33d9226

Add obs-ndi plugin version to NDI Output Settings dialog title

919ca70

Check for Qt >= 6 during obs_module_load

a38855b

Tweak readme a little

22929ea

Fix title in NDI Output Settings

d4621ac

Add --obs-ndi-verbose command-line

18b027e

Also making Config code similar to `obs-websocket`'s code

Add missing verbose a/v logging for non-framesync

64dcdd8

Update hw_accel to use NDI 5 ndi_video_codec metadata

7c6dce7

...and not legacy NDI 4 `ndi_hwaccel`. According to their docs and forum posts there is supposedly no way to un-set this.

Fix [lack of] char* casting error

3dea004

paulpv force-pushed the develop branch 3 times, most recently from 23d2148 to 36330b5 Compare January 13, 2024 04:03

ci: Fix formatting build break

c44d97e

paulpv force-pushed the develop branch from 36330b5 to c44d97e Compare January 13, 2024 04:10

Merge branch 'develop' into develop

715ca40

Trouffman added help wanted macos critical needs-testers Seeking Testers PRs with this label will package the plugin so that others can test windows linux (supported) labels May 10, 2024

i18n: cleaning up translations a little

2c27364

paulpv force-pushed the develop branch 3 times, most recently from b78f822 to e29a7b0 Compare May 10, 2024 20:35

obs-ndi-source: document hardware acceleration enable semantics

d238bac

paulpv force-pushed the develop branch from e29a7b0 to d238bac Compare May 10, 2024 20:36

Correcting typos libndi-get.sh

0336a05

Correcting typos & nitpicking.

Trouffman reviewed May 12, 2024

View reviewed changes

data/locale/ca-ES.ini Show resolved Hide resolved

Trouffman reviewed May 12, 2024

View reviewed changes

data/locale/en-US.ini Outdated Show resolved Hide resolved

Trouffman reviewed May 12, 2024

View reviewed changes

data/locale/fr-FR.ini Outdated Show resolved Hide resolved

i18n: Updating translations

9a79399

paulpv requested a review from Trouffman May 13, 2024 06:13

paulpv self-assigned this May 13, 2024

Trouffman previously approved these changes May 13, 2024

View reviewed changes

Trouffman reviewed May 14, 2024

View reviewed changes

Trouffman reviewed May 15, 2024

View reviewed changes

Trouffman added this to the 6.0.0 milestone May 16, 2024

paulpv mentioned this pull request May 21, 2024

New Feature: Check For Update #1028

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Preparing for 6.0.0 release #960

Preparing for 6.0.0 release #960

paulpv commented Jan 11, 2024 •

edited

paulpv commented May 10, 2024 •

edited

Trouffman commented May 10, 2024

Trouffman commented May 12, 2024

paulpv commented May 13, 2024

Trouffman left a comment •

edited

Trouffman May 14, 2024

Trouffman left a comment

Preparing for 6.0.0 release #960

Are you sure you want to change the base?

Preparing for 6.0.0 release #960

Conversation

paulpv commented Jan 11, 2024 • edited

paulpv commented May 10, 2024 • edited

Trouffman commented May 10, 2024

Trouffman commented May 12, 2024

paulpv commented May 13, 2024

Trouffman left a comment • edited

Choose a reason for hiding this comment

Trouffman May 14, 2024

Choose a reason for hiding this comment

Trouffman left a comment

Choose a reason for hiding this comment

paulpv commented Jan 11, 2024 •

edited

paulpv commented May 10, 2024 •

edited

Trouffman left a comment •

edited