Apple contributes to OBS to support screen capture using ScreenCaptureKit | Hacker News Reader

Apple contributes to OBS to support screen capture using ScreenCaptureKit

github.com

722 pointsfrankjr188 comments

This commit in the PR

https://github.com/obsproject/obs-studio/pull/5875/commits/8...

provides an excellent example of why commit messages matter. This is more than 1000 lines diff to the build system (and thus potentially very dangerous because of possible supply chain attacks) which has the commit message of

"CI: Update build scripts and Github actions workflow"

Never say what you ware doing (it's obvious this commit is updating build scripts). Say why you are doing it, especially when your commit feels unrelated or at most very tangentially related to the objective of your PR.

I'm all for well presented PRs/commits but I'm not sure how a good commit message mitigates the risk of a supply chain attack in this case.

It might help the reviewer to not flat-out reject the PR because it gives them a fame of mind as to what the intention of the change is.

> Never say what you ware doing (it's obvious this commit is updating build scripts)

DEFINITELY say what you are doing. And then say why.

This blog post is a good description of the most prevalent convention in how to write good and useful messages (e.g. this is what the Linux Kernel does and given the history of git there's some flow down): https://cbea.ms/git-commit/

The key thing that means you should start with what is having a short one-line summary of what you're doing so you can look at a simple log and see which commit you're interested in.

Also, if your commit message has parts that say "also, this", "also, that", don't be lazy and break those alsos into separate commits!

Not necessarily. It sounds like all of the things mentioned in the commit message are interconnected (updating build scripts and updating gitignore to remove the new build directories). It would be pointless to break these into separate commits, you can't revert just one without reverting the others.

The commit message is lazy, but breaking these into separate commits because of some "also" rule of thumb is just blindly following a rule for the sake of it.

> breaking these into separate commits because of some "also" rule of thumb is just blindly following a rule for the sake of it

Agreed, cargo-culting is always bad!

But, without knowing how OBS development team works, sometimes it does make sense to split commits like this, mainly if you have a larger repository where different people are responsible for different areas in the codebase.

For example, build-scripts sometimes gets managed by other people than the ones writing some core algorithms, who are also different from the people writing public APIs to be consumed by users. In those cases, it makes reviews a lot easier when you can split out to review different commits to different people, instead of having everyone navigate the same commit.

But again, not familiar with the internals nor the development cycle that OBS keeps, so maybe this doesn't make sense in this case.

As others have mentioned many times here.

This commit is based off a branch that was adding support for Apple Silicon.

So the entire PR is not going to look clean until that branch is merged first.

Yes, makes a lot of sense. Sorry if I gave the impression that I think somehow this PR is wrong or similar. I was just replying to the fact that sometimes splitting up commits makes sense, outside of this PR.

My exception to the "also" rule of thumb is that if the split changes would cover separate areas of the code such that each piece could be easily picked out by "git add -p", then splitting them out isn't required as long as they are all associated to one logical larger story.

> ...you can't revert just one without reverting the others

That's often true in a split out patchset anyway, so I don't think that on its own it stands as a justification for doing things one way or the other.

Dubious. I prefer that style myself, but there's a lot of value in squashing multiple commits around a feature into a single, "this commit implements this feature" commit. Is it valuable to retain the entire development history of a feature, or just the feature itself? What if during the development, it was rewritten a dozen times? What if there's a dozen commits where the author meandered and only in the last three commits got to the point?

Ruthless interactive rebase is one way to fix that last point, but if you take the final result and squash that into a single changeset, there's a point to be made about that as well.

Agreed, it's a matter of preference, but I prefer logically separate changes to be in separate commits at least within the PR, where it may make reviewing the PR easier. It's basic empathy towards the reviewer(s).

Of course, when merged, it often makes sense to squash some commits together, just like you say - long-term, many of the feature development details are not important.

It's not an either-or proposition.

Small nit: Maybe not say what YOU are doing, but what the COMMIT, when applied, will do. Git is not a personal work log, it's a source code change log. A commit may be a collaborative effort; it may be a squash of a thousand smaller commits; it may be a merge, it may be generated by a tool (like the dependencies), etc.

The commit should summarize what IT does, not what YOU did. In ten years, nobody will care who you are or what you did, but they will care what the code does and why.

That's the main reason we are using present tense in commit messages, not past tense. It's the commit that is applying the changes at that moment.

> That's the main reason we are using present tense in commit messages, not past tense.

As a linguistic note, commit messages (at least, English commit messages) almost always use an infinitive verb and therefore may be considered to have no tense at all, though to argue that infinitives have no tense you do need to draw a distinction between tense and aspect.

I believe it’s the imperative (enable widget) not the infinitive (to enable widget) that is generally used.

> I believe it’s the imperative (enable widget) not the infinitive (to enable widget)

You're confusing a bare infinitive with an imperative. Infinitives are often, but not always, marked with to. Commit messages are not commands and are not capable of licensing imperative forms.

Here are some examples of bare infinitives in English, with the infinitive form italicized:

1. This organization will help you apply for a loan.

2a. Q: What does he do?

2b. A: Check over the paperwork to be sure everything's right.

A commit message is doing exactly the same thing as occurs in example 2b.

> This blog post is a good description of the most prevalent convention in how to write good and useful messages.

https://microsoft.github.io/code-with-engineering-playbook/c...

> DEFINITELY say what you are doing. And then say why.

My favored github PR template has 3 sections:

  - What does this PR do?
  - Why is that valuable?
  - Link to bug tracker.

We have a similar template at work, and since we made it the default (on Bitbucket you can pre-fill it), it's saved a ton of back and forth asking questions:

* Description: (What this does, and why)

* Ref: (Ticket/task link)

* To test: (Specific instructions to make sure things are working as expected)

* To deploy: (What specific servers/services to restart, and operations to perform)

Ironically, the referenced article on how to write good git commit messages (https://cbea.ms/git-commit/) gives no "why" for most of its points. It lists 7 rules, of which 2, 3, 4, 5, 6 are simply declared without rationale.

so true.

my personal observation: because writing down „what“ is hard. Writing down „why“ is even harder.

Question from a naive kiddo; When the PRs are this big, what are the steps taken to "get it in" the master ? Just blindly accept based on CD/CI jobs, or break it down to walk through every change ? "Ref: supply chain attacks"

If I was in the position of having to review that PR, I would probably flat-out reject it and ask for just the minimal changes required.

I don't see how adding an additional capture framework backend would require meaningful changes to the build system.

With some likelihood, in this case, Apple probably won't have the resources to rework their PR and thus the PR will stay un-merged until somebody of the project has time to merge/reimplement the relevant parts.

Which of course is a total shame and I wonder why Apple didn't have "mergeability" in mind when they decided to create their PR. They must have known that "rework the build system" can't be part of a PR adding a capture backend if they wanted any chance of this being merged.

It is not that uncommon to have make changes to a build system in many places in order to support a new architecture. Especially if there was previously only support for a single one.

No, the PR is based on another PR [0] which adds Apple Silicon and Universal Binary builds, the mentioned commit is part of that PR.

[0] https://github.com/obsproject/obs-studio/pull/5155/commits

The Apple developer's commit builds upon another pull request which contains the build system work by OBS developers, the build system changes are not part of Apple's commit.

A million comments and this is the only valuable one. Amazing that everyone accepted the premise that Apple proposed refactoring some other project’s CI.

>Apple probably won't have the resources to rework their PR //

Aren't Apple the richest corporation in the World, how would they not have resources; am I missing a joke? Maybe you meant 'will choose not to'?

I didn't get where I am today by employing engineers with my profits...

Before three was Dallas, there was The Rise And Fall Of Reginald Perrin, in the main arc a dark parody of 70s corporate England. If you could find a better audio-visual exposition of the transatlantic difference at the end of the nineteen seventies, you will struggle to find a funnier one.

http://www.leonardrossiter.com/reginaldperrin/CJisms.html

https://www.google.co.uk/search?q=reggie+perrin+i+didn%27t+g...

In this case it looks their work is based on another branch not yet merged (https://github.com/obsproject/obs-studio/pull/5155 which adds support for Apple Silicon) - and the commit is from there.

Looking forward to that: I'm going to be needing to use OBS on Apple Silicon.

I honestly thought it already was running natively, it already runs super smooth in rosetta

Rosetta is incredibly impressive. And I guess it needed to be. The switch to ARM was going to be a hard sell without a fast x86 translation layer. I'm hoping though that devs don't use it as an excuse to never release ARM builds of their software. It would be good to have ARM builds across all the major operating systems.

I fully expect devs to drag their feet.

This happens with every transition in Apple history. It takes pulling the rug out completely before many devs will do it

Look at the Python transition, the carbon to cocoa transition, even the original Rosetta transition.

Github can point the PR at that branch and those commits won’t show up anymore.

That branch is on a different fork (PatTheMav's), so they wouldn't be able to do that in this case.

TIL. Thanks.

Yes, and the author was asked to base the PR on 5155:

https://github.com/obsproject/obs-studio/pull/5875#issuecomm...

And it looks like they're just going to set the PR to a draft until after 5155 is merged, so it will get cleaned up and be easier to review then:

https://github.com/obsproject/obs-studio/pull/5875#issuecomm...

HN is usually better about sussing out the real story.

Just to chip in what should the commit message say: it should express the intent of the change and the reason of the change (latter could be reference to ticket). I don't think expressing how the intended change is achieved is important, that's what the diff is. If it's not clear in the diff how the intended change is achieved, try adding some comments.

Doesn't the gigantic pull request description [1] already provide ample description of why the changes are being made?

[1] https://github.com/obsproject/obs-studio/pull/5875

None of that is part of the Git repo, so any mirrors won't have the context.

It's in the commit message: https://github.com/obsproject/obs-studio/pull/5875/commits/5...

That doesn’t get stored in git, you won’t be able to see that information on the clone of the repository you will be developing on locally.

Just to expand on that, I always say there are three audiences for the commit message:

1. The reviewer

2. Someone scanning commit logs for patches of interest

3. Archaeologists

Archaeologists are people a year, five years, 10 years down the road who are trying to figure out how the code got to be the way that it is, so they can feel confident changing it. (See also "Chesterton's Fence"[1].) Those people should not have to dig out the conversation from some random PR to figure out what's going on.

[1] https://news.ycombinator.com/item?id=30070757

> Those people should not have to dig out the conversation from some random PR to figure out what's going on.

Not knowing to look to an associated PR thread for a commit would be the equivalent of modern day archaeologists not knowing what "carbon dating" was.

A fairly common occurrence when looking at old commits is that any URLs mentioned are now 404s, and ticket numbers are for an issue tracker that no longer exists.

Isn't the PR exactly where you'd go to see that information, if you're an org that uses PRs to store that information?

Unlike commit msgs, which are immutable and stored with the code, Jiras/Githubs etc. are transient.

It's in the commit message, so it will get stored: https://github.com/obsproject/obs-studio/pull/5875/commits/5...

Seems pretty fucking clear based on the message to me.

We have a rule internally that a PR can’t be more than 1,000 loc. I personally find a 1,000 loc PR almost unreviewable. It takes me multiple days and a stack of notes, and still almost always ends up with effects I didn’t anticipate.

Trying to understand the changes and their full implications is nearly impossible. 100 loc is a better top end imho.

Last place I worked (big company, not FAANG) I remember a PR for our main app that affected 500 files and occasionally dozens of places in some of them. All the reviews were "LGTM".

I forget where I first saw it, but there's a joke of "ten lines, ten issues; 1,000 lines, looks good". There's a human limit to how much you can hold in your head when reviewing code.

I think it's a double edged sword - people are also way too nitty for small commits, which only incentivizes behavior like this.

Looks like the programmer's version of: "If you owe the bank $100, that's your problem. If you owe the bank $100 million, that's the bank's problem.”

https://www.goodreads.com/quotes/214064-if-you-owe-the-bank-...

When you refactor a commonly used structure, it's easily possible to hit situations that you described. In those cases, having nicely organized commits are super important. You need to make sure that the commit that does the refactor only does the refactoring. Nothing else, then you can review the PR commit by commit and it becomes much more manageable.

When people start doing multiple things in a single commit with 1000's of changes, it does become mentally exhausting to review. Unfortunately, it requires either being extremely diligent when making the commits or being familiar with git rebase -i.

Of course, sometimes it's just thousands of lines of new code and impossible to review :).

10 lines of code = 10 issues. 500 lines of code = "looks fine."

Parkinson’s Law of Triviality

about days and a stack of notes :

this is why we have line printers, custom reading tables with balanced soft lighting (print proofing lamps) and more recently, rostrum cameras operated by foot switch.

review with fanfold might be a habit only acquired by formative experience, but once you physically manage the printout, and are comfortably seated with several hundred well spaced lines that aren't directly emitting typically exhausting spikey spectrum light forcing your brain to perform extremely complex colour management to balance your vision, which is the primary factor in concentration depletion in every attempt at testing we've tried over the years, and you mix in modern handwriting recognition and a pico projector display of feedback comments if necessary, I have only witnessed very high productivity. Anyone who is subject to audits will know the satisfaction of dumping fanfold boxes on the auditors desk. Or should.

Code reviews are interesting to watch. Especially when the author awkwardly pauses and says, "I'm not sure what this code does".

Note that those commits seem to have been added by an OBS contributor on top of Apple's patch. The fact they touch the entire build system, in a PR that is 100% macOS focused, is much more concerning than the commit messages.

Yes, a good commit message should be a few concise paragraphs.

The subject describes what is being affected (think easily greppable keywords)

Then, then body should go into detail about the contents and rationale for the changes.

Use specific terms like “add” or “remove” and avoid subjective descriptions like “prepare” “clean” and “fix”

For example this patch says:

> Clean up consistency of tabs/spaces in include_directories.

Well, what does clean up tabs/spaces actually mean? Saying “remove tabs in favor of spaces” is much clearer.

HN: big tech companies should contribute more to open source!

Also HN: no, not like that!

There's nothing weird about both of those being true.

in the description of the PR, there's almost 1000 words of text describing in detail what is being done. I don't see the problem.

Never say what you ware doing (it's obvious this commit is updating build scripts). Say why you are doing it

Don’t say what you were doing, say what the commit does. A good commit message completes the sentence “when merged this will …”.

Adding a more detailed description on the second line including why things were done is also not bad, but I have a strong opinion that design notes do not belong in the commit log but in code comments or markdown files that are in the repo, so that they can be found more easily and updated.

Before / after side by side comparison video:

https://user-images.githubusercontent.com/65677710/151421432...

(This and 2 other videos are linked in PR conversation tab: https://github.com/obsproject/obs-studio/pull/5875)

The weird thing to me is that it's not just lower CPU/GPU for OBS, but lower GPU for the game. Maybe just a coincidence, since the CPU fluctuates so much between the two.

Heavily speculating but it's not unreasonable that the recording process impacts the game fps. Eg if you had 2 processes trying to max out your CPU it'd be less efficient than doing them one after the other because they're fighting for resources, doing context switching (losing cache etc).

It's a bit strange to open a pull request from "Developer-Ecosystem-Engineering" instead of an individual account. I wonder if every interaction from this account has to be approved by a board or something.

It's a valid point, however shall we at least celebrate a bit the fact that a Big Tech is actually contributing in the project?

TBF I don’t know how much “we want $popular project to take advantage of our platform” is to be celebrated.

It’s better than bitching about bad support without doing anything. But at the most fundamental of levels it’s really the company working for their customers, through a third party’s project.

Is a company working for its customers to have a good experience with an open source package something we should discourage instead?

I’m perfectly happy to celebrate win-win outcomes.

> Is a company working for its customers to have a good experience with an open source package something we should discourage instead?

You are aware that there are more than two options?

Of course. Apple has many options and their choice to contribute to OBS allows me many options as to how to react; I choose applause.

I don’t know, this feels to me like applauding a car driver who uses their turn signals correctly.

“Hooray, you did the thing you’re supposed to do. Good job you”.

Why would Apple be supposed to do this? Without any other argument on the table, taking that statement to its logical conclusion, it would imply Apple is supposed to help make every single project run well on their hardware.

Even when restricting that to “open source projects that (cl)aim to run on latest MacOS”, I think that’s not something a vendor is “supposed to do”.

So, if Apple only “is supposed to” support some projects, what objective criteria should it use to pick them?

I think it’s completely fine if Apple wouldn’t support any open source. I also think it’s completely fine if developers would choose not to write software for their OS because of that.

I think situations where literally all parties involved are better off than they were before should be celebrated, even if the intentions behind it aren't just philanthropic.

So you celebrate every time somebody makes a purchase of something they needed and had the means for?

If those goods were produced by people paid fair wages and using materials sourced sustainably/ethically, sure.

So in practice, not very often

Is that rare? I would have thought many FAAG employees contribute to open source projects relevant to them as part of their work. After all that seems like the easiest way to influence the projects.

And contributing changes back to an active project is much less effort than maintaining a fork in perpetuity.

Facebook.. Yes... Amazon... Yes Apple... Not so much. Netflix.. A little Google... Yes...

Amazon...it depends

There's a good post on HN about what it cos Apple to make OS X a certified UNIX. Due to the secrecy of the project they had to use non-corporate accounts for committing bug fixes. The amount of changes was pretty big, but nobody excepts the authors can say it came from Apple.

Of course they will commit to open source projects if it suits their needs (if they use those projects). But people have different opinion on what Apple's needs are.

You probably mean https://news.ycombinator.com/item?id=29984016

There's a pretty big distinction between FAANG employees contributing on their own time to things tangentially related too their job, and FAANG employees contributing on behalf of the company (i.e. being paid to do so as an official part of their day job).

Judging by the Engineering account being used to submit this patch, this is likely to be an example of the latter.

_as part of their work_ means during their billed work time.

In that case, no, almost no FAANG employees do that. I would have had to file paperwork and receive legal signoff for each individual patch to any open-source projects that weren't owned by the company.

What does exist is specially "blessed" FAANG teams who are cleared to contribute to specific open-source projects that are critical to the business. Amazon has a team who contributes to the linux kernel for hypervisor support, for example.

From experience in a big company (not Apple) likely direct manager then senior manager then legal department. The justification and hoop jumping would take much more effort than the coding.

Well done to who ever it was.

Contributing to a new open source project requires Senior Vice President approval at Apple.

Jesus

Not accurate. There's multiple levels of contribution approval depending on the frequency, size and extent of the contributions.

I am aware of several projects that Apple has existing relationships with that have streamlined processes, but to my understanding the “ask a SVP” remains the standard policy for getting permission to contribute to an open source project.

It is not. You only need the SVP permission if you are doing larger contributions and frequently. Smaller contributions or one offs don't go up the chain as far, and can just require manager+legal approval

Don't Apple have a policy that their developers aren't supposed to contribute to Open Source without explicit permission (https://news.ycombinator.com/item?id=22935263)? I imagine this is the result of that policy - if Apple wants to contribute to something as a business there isn't really anyone who would be able to use their individual account to do it without lots of people questioning why that person can when others can't.

Most companies have this policy it’s actually quite important to protect both the company and the project, it wouldn’t surprise me if big projects even mandate it on their side too.

It usually comes in two flavors - individual contribution as you doing something on your own time and equipment and official contributions when the company itself contributes to a project.

This looks to be the latter rather than the former so it would make sense it would come from an Apple account.

> It usually comes in two flavors - individual contribution as you doing something on your own time and equipment and official contributions when the company itself contributes to a project.

My understanding is that Apple's policy is highly unusual in that "individual contribution as you doing something on your own time and equipment" are pretty much not allowed at all.

> My understanding is that Apple's policy is highly unusual in that "individual contribution as you doing something on your own time and equipment" are pretty much not allowed at all.

I am not sure exactly but I suspect this is employee-specific and may be only for those working on sensitive projects.

I worked at Apple years ago and it was never in my contract or mentioned to me. And there are plenty of more recent developers e.g. Holden Karau who were contributing to open source projects in their spare time whilst working at Apple.

Nope, rather, Apple engineers having side projects is employed-specific and usually requires some sort of special case for them to let you continue working on your thing. This has been a standard part of the contract for a while, and it’s nothing like a decade or two ago where you might have a DTS engineer make a side app or two for fun or give their own, unofficial opinions of the SDK on their personal blog without approval.

I can confirm that. It was a reason why close acquaintances refused to join.

It’s more complicated than that. Apple’s blanket policy towards such contributions is that anything you do in your own time needs SVP approval, because it might potentially compete with Apple’s business interests. And as a general policy it likes to deny such requests. Other companies have various policies: Google, for example, is for the most part “we’ll let you do whatever but we own the code, and if you want to own it we will make it about as difficult as Apple does”. The whole “you compete with us if you do anything” is a big tech thing, by the way, because they work on so many things that they can scare their engineers with competition threats on any grounds in California. The best that smaller companies can do is restrict you from working on the limited thing they work on, such as developer tooling or a social network.

Meanwhile Microsoft lets their employees do whatever they want after hours, so long as no company provided resources are used.

I know of developers who made quite a bit of $$$ being first out the door with applications utilizing SDKs that they wrote. MS is perfectly happy with their own developers showing off shiny new features.

Because that’s the law in Washington state.

And not in california? Its interesting that Apple is seen as hip and cool yet operates a tight leash obviously because it can, legally. Microsoft is... other things... yet is operating a looser leash, albeit also in compliance with law.

Interesting but not surprising I guess.

Microsoft is also "older" on the software side of things, and is probably the source of why that law came into being in Washington state.

Which law are you referring to? Noncompetes are enforceable in Washington but not in California, for example, and Microsoft has enforced noncompetes for upper management in several high profile cases, but I am not aware of any enforcement against engineers.

I am not talking about non-competes, I am talking about moonlighting.

On the day of employee orientation, they specifically talk about moonlighting and HOW to do it.

"Do not use any hardware we provide for you, and do not use any software you installed from the corporate network, buy your own copy of development tools and licenses, you can use the free Azure credits we give you but not the ones linked to your employee login, make sure you use the credits on your personal account."

They do require you not write software that directly competes with existing Microsoft software, for obvious reasons, but other than that it is fair game.

But this doesn't even cover the whole of it. At multiple times, Microsoft has actively encouraged their employees to write software as a side hustle! They've launched internal competitions "We have a cool new SDK, write some software and put it on the MS Store! Best rated software wins some prize!"

The entire "developers first" culture there extends to how they treat their own employees.

Heck MS has a long tradition of employees leaving to start a new company and MS buying that company up a few years later. I suspect that during the 90s/early 2000s it was seen as a good way to innovate, similar to incubator labs within companies now days.

At Microsoft at least at my site we are encouraged to contribute to open source and it even brings perks/recognition so really not sure about “most companies” here

It's company wide, so yes, Microsoft has a pretty sane policy regarding that (as well as clear guidelines for dealing with OSS code)

We (FAANG) have a list of open source projects that we are not allowed to contribute to without prior permission. Anything else is fair game from what I can tell.

Could be related to the decision to remove individual names from the product about boxes back when Jobs came back to better control leaking of internal information and cut down on poaching. I would think that Apple does not want anyone to know who is working on the screen capture APIs as this PR would probably come from one member of that group

"When Steve came back, one of his company-wide edicts was that the names of individuals must be removed from about boxes."

https://bitsplitting.org/2014/01/24/cant-take-that-away/

> when Jobs came back to better control leaking of internal information and cut down on poaching

He also went further than that by illegally colluding with competitors to lower wages for employees. [0] [1]. What a great man.

[0] https://www.businessinsider.com/emails-eric-schmidt-sergey-b...

[1] https://9to5google.com/2012/01/27/court-filings-show-steve-j...

Well, given the amount of publicity this PR is getting it probably makes sense to not just let a random software engineer post whatever they feel like.

For those of you who have contributed to a Github (or similar) project in your capacity as an employee, do you use a work account separate from your own?

yes.

Depends on the company, usually. Currently, I make my contributions with a personal account.

It’s very team dependent - look at llvm and webkit for instance.

It could also be that someone would rather not be out in public, which is also understandable.

HP tried to do something similar when working with openstack. It was done for very bureaucratic reasons / company visibility. (Author was preserved, commit was by something like the-project-name@hp.com) A slightly misguided idea by people who don't normally work with big open source. It was reverted since it messed with project statistics.

The pull request page might be more readable: https://github.com/obsproject/obs-studio/pull/5875

For others like me who had no idea what "OBS" in the title refers to:

It's open-source software for video recording and live streaming.

https://obsproject.com/

It's actually some of the best software I've used for streaming. Also, the feature to record a browser tab is a life saver when I'm double booked and don't want to miss content from a meeting.

Just an FYI you may want to double check the laws in your state and company rules on personally recording meetings.

< The __MAC_10_15 define may not exist on devices running < 10.15, resulting in this section not being appropriately avoided during compilation. Swapping to 101500 should work for all versions of macOS.

So they are mindful of people with old Macs. This is good!

Apparently not the first time from the activity of the user:

https://github.com/Developer-Ecosystem-Engineering?tab=overv...

https://github.com/obsproject/obs-browser/pull/310

Strangely, a lot of contributions to numpy.

Not too strange if Apple wants a competitive development environment.

Maybe I'll be laughed at, but right now I consider the most competitive Apple's development environment the Swift Playgrounds on iPad.

I just so wish to see this sleek and fast app replacing old cranky Xcode on macOS by adding missing features.

I find this PR an interesting opportunity to discuss different types of documentation.

I've internalized that there's a difference between the PR description, commit messages, and code comments. For me there's different intended audiences for all three, and their contents should thus be shaped accordingly. This PR basically combines all three into one and uses that as the commit message, and I'm not sure of what to make of it. Is this good practice?

Personally I find the contents of the "#### Summary of Changes" list to be super-neat and helpful. But should these not be more helpful as comments inside the code? On the other hand, it does explain what the code is doing at this snapshot in time: which makes it more precise than comments in the code -- since future changes might eventually make those comments incorrect.

What's your take?

Personally I like for the dev to do little commits that document each change to a file and then when the branch is merged in you do a squash merge and each commit msg becomes a bullet point.

I realize this is specific to having an interface that makes it easy, but I find it valuable to step through each commit in a larger merge review. I'm not a fan of how e.g. bitbucket doesn't make it easy to browse the commit contents .

> On the other hand, it does explain what the code is doing at this snapshot in time: which makes it more precise than comments in the code -- since future changes might eventually make those comments incorrect.

If changes are made to the code, the comments should be updated accordingly. Getting from code to a PR text is a non-obvious and difficult process and when parts of the code are updated, the trail is easily lost.

I share the same opinion. While perhaps more brittle, it’s also immediately apparent

Now I hope they improve the situation of virtual cameras. Now you need to code sign all kinds of applications in order for them to recognize your applications, which often breaks those applications.

I really want to use the virtual camera in FaceTime. But it's near-impossible to get it to work.

I've still got an old iMac running High Sierra just so that can use virtual cameras. It used to work beautifully.

If anyone watches "Meet Kevin" youtube channel, you would know the bad publicity Apple gets with him attempting to stream on his relatively new Mac Pro system. Any effort to improve that capability would be in Apple's best interest. Streaming is not going away.

https://www.youtube.com/channel/UCUvvj5lwue7PspotMDjk5UA

Seems like a money YouTuber, I've never watched him myself.

I found one of the timestamped video clips where he hits one of the streaming issues on his Mac... https://youtu.be/V5SYAHQhEx8?t=260

EDIT: ...and another one... https://youtu.be/HBXUy5fZNYU?t=890

Nice to see them contribute to open source!

For anyone trying to find the actual changes made, vs the build system that was modified, you can find them with this compare: https://github.com/PatTheMav/obs-studio/compare/universal-bu...

The branch on GitHub should change its reference until the build system is merged into the main branch.

I want to know if they’re using Rosetta on their M1 test machine or running it natively. Hopefully this patch leads to a proper darwin/arm64 release so I don’t have to use this weird fork[0] with a private GitHub Action to get a native build. The Rosetta version is considerably slower.

0: https://github.com/carlosonunez/obs-installer-for-apple-sili...

> I want to know if they’re using Rosetta on their M1 test machine or running it natively

Natively.

There's an open PR[0], #5155, to get OBS native on Apple Silicon. That's also what your weird fork uses.

Apple's PR is on top of that work: you'll see that there are 10 or so initial commits. Thus #5155 will need to be merged first, before Apple's.

#5155 is a huge PR and has been open for 5 months. Its release will also necessitate OBS get an M1 testing solution figured out. Here's a quote[2] from an OBS team member two days ago:

> [This PR is] top of our priority list once we release 27.2. We're keenly aware of how badly people want a native Apple Silicon build, and I can assure you that we will definitely be publishing official test builds of OBS with M1 support as soon as we are able.

I would nevertheless expect for all of this to take quite a while.

[0] https://github.com/obsproject/obs-studio/pull/5155

[1] https://github.com/obsproject/obs-studio/pull/5155#issuecomm...

Thanks!

I wonder if this will provide a way to hide the yellow dot that appears in the corner (to indicate mic access). It is a great idea in most cases, but quite annoying to see on screen recordings.

Does this mean I’ll finally be able to capture audio in OBS on macOS without third party tools like sound flower and blackhole?

This is just for display/window capture, not audio capture.

Maybe OBS will work on my Mac now. I struggled to get it working, everything recording as I wanted. Thought it was just "crappy open source" stuff, so gave up.

Some time later, I tried OBS on Windows, and it just worked, first time, no fiddling required. And I realised the problem was on the Mac side, not Obs.

I know, its just one anecdote.

Getting the audio to work on MacOS OBS is always a pain.

Personally I had luck with using Blackhole

It shouldn't require a third-party driver! It's basic functionality which should be provided by the OS in a userspace API.

Blackhole does its job, except your volume buttons stop working when you're on a multi-output device. Quite a pain.

How long ago was this? They've been making some big stability improvements over the last year or two.

Adding to the anecdote, OBS works great on Ubuntu.

Between one and two years ago, my team had serious issues getting OBS working reliably on T2-equipped Macs. We switched to an expensive commercial product and all our problems went away.

I couldn't duplicate the OBS issues on older Macs that didn't have the T2 chip.

In the PR description, if you expand the sections "Baldur’s Gate 3 Demo", "Shadow of the Tomb Raider", etc. it shows the performance improvement of capturing the respective games. Looks like a very significant improvement.

Should this allow OBS to not capture the actual OBS window itself? I'd think it would be nice to eliminate that from what is captured, for those poor people who only have a single monitor. :)

How does one go about reviewing such a PR? If the PR consists of smaller commits then it would probably be easier. But if a large commit is made, then what would be the flow to review it?

I am pleased to see Deus Ex: Mankind Divided in their testing.

How do we know this is Apple?

Makes me wonder how efficient Xorg vs Wayland capture is on Arch btw

I hope those changes were planned and agreed upon beforehand. I'd hate to review 274 changed files out of the blue

ScreenCaptureKit seems to Apple only, so this only helps Mac users.

While nice it seems to be a trend where Apple seems to contribute to open source projects now to improve its own performance only on their own devices (blender comes to mind). Maybe Im being a bit cynical.

Still a positive I guess.

While I see what you're saying, to be honest it seems pretty reasonable to me for Apple to contribute work that helps Apple.

Many OSS contributions are "scratching your own itch", no?

I mean, it's not a bad engineering philosophy for things as low-level as this to be provided by the OS as a framework. Capturing screen output at a high refresh rate without introducing lag may be better implemented with lower-level access to certain system components, in a way that may require certain privileges in order to make it work.

You can provide a nice higher-level API (like ScreenCaptureKit) to access such "privileged" capabilities from normal apps, so that arbitrary open-source software (like OBS) can hook into it.

It seems like Apple already made ScreenCaptureKit for their platforms, and wanted to help OBS by hooking it up to ScreenCaptureKit to take advantage of that work.

The alternative, which is to do all the private/privileged stuff directly in OBS, means that Apple would have to give the general ability for arbitrary software to do what ScreenCaptureKit is doing, which may be a security issue (spyware that snoops on what's being displayed on screen comes to mind.) Making something like ScreenCaptureKit as the supported interface to do this kind of thing, can ensure the app triggers the proper permissions dialog/etc so that screen recording doesn't happen without user knowledge.

> Maybe Im being a bit cynical.

If Apple, Intel, AMD, NVIDIA, Arm, Qualcomm, etc. would all contribute to open source to make everything work on all their devices with good perf, then that would be very good for all users.

Expecting AMD to make open source contributions to improve software on Apple's hardware or Arm GPUs is "naive", not cynical.

It would be like expecting Tesla to go to VW and help them improve their combustion engines for free.

You are indeed being too cynical.

The point of open source (not just a free binary blob) is that you can fix the parts that matter to you.

In the case of companies, they typically work on the parts that matter to them. This has been true since the free software movement started to reach into businesses, with companies like Cygnus (of course) but also Sun, SGI, IBM etc all working just on their own platforms.

That’s a fair point. I haven’t looked at their contributions, but it would be nice if they’d help out the project as a whole as well.

I also got a Linux preinstalled conputer, so I’m hoping (selfishly perhaps) that open source projects have great first rate open source OS support. It seems like open source is always resource strapped.

But you are right it’s not like IBM, SGI, Sun weren’t proprietary..

NeXT funded and performed quite a bit of open source software, quite a bit of which continued in the Apple transition.

Make no mistake: for all of these companies, this funding was in support of their commercial activities. They have no desire, say, to write a shell so if one is popular they'll go that way. One thing we taught then in the 90s was that stepping off the mainline simply added to your support cost; this lesson is why so many proprietary companies do contribute back.

Apple's case is interesting: they think more deeply than many about this. Thus they are enthusiastic about standards when they are weak in the domain: e.g. Apple was explicit up to the Jobs level that they embraced open standards like JPEG and MP3 when trying to dig the Mac out of a deep hole; once they had a solid foothold they felt comfortable trying out proprietary formats. They went USB-C (and handed over a majority of the work on its design to the USB consortium, or so a couple of friends who worked on the standard claimed to me) because it helps adoption of the Mac and iPad; but aren't afraid to make a MagSafe connector.

It's all about strength and weakness to Apple, an approach which frankly more companies should adopt (looking at you MediaTek, AllWinner and your competitors).

Having Apple contribute in the area of their expertise makes sense.

Are they supposed to contribute the Windows 11 screen cap?

Apple should be ashamed. Microsoft does so much for open source (VS code, typescript, .NET, Blazor and dozens other projects) and even Goolge does quite a lot. And only $Apple$ is an ego-driven company that only cares how to squeeze as much money as possible from customers.

Apple may have to be ashamed, but bringing up Microsoft as a good OSS citizen?

https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22

I love how this comment is here on a PR from Apple for an open source project…

WebKit, LLVM, Swift… these are pretty fundamental open source projects, in addition to a bunch of other stuff.

You can’t please everyone all the time, and society is too addicted to outrage these days.

Doesn't Microsoft compile Edge with Apple's open sourced Clang compiler?

LLVM was a thing before Apple and Apple are far from the only ones working on it

Clang isn't LLVM and Clang was created from the start by paid Apple employees and open sourced by Apple.

>One of the first uses of LLVM was an OpenGL code compiler for OS X

The LLVM project originally intended to use GCC's front end.

Apple chose to develop Clang, a new compiler front end that supports C, Objective-C and C++.

https://en.wikipedia.org/wiki/Clang#Background

Here's video of Apple's Chris Lattner giving a tech talk on the Google campus introducing Clang and LLVM 2.0 in 2007:

https://www.youtube.com/watch?v=VeRaLPupGks

    - #if __MAC_OS_X_VERSION_MAX_ALLOWED >= __MAC_10_15
    + #if __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500 // __MAC_10_15

ah, yes, clean code

The message for the PR (under the Conversation tab) justifies this as:

> plugins/mac-capture/mac-display-capture.m:621 - The __MAC_10_15 define may not exist on devices running < 10.15, resulting in this section not being appropriately avoided during compilation. Swapping to 101500 should work for all versions of macOS.

A conditional define might be a good alternative tho?

yes, it's the whole macos compatibility / availability layer which is terrible. In contrast a good system like Qt looks like

   #if QT_VERSION > QT_VERSION_CHECK(5, 15, 0)
    ... 
   #endif

and works also for Qt 5.1 or Qt 4 or 3 (i think that's when this macro was introduced, pretty much at the same time than os x 10.1 ?)

That’s just adding another layer of abstraction over exactly what the Mac case does. I prefer code that is so simple it doesn’t need to be abstract, as every abstraction layer is a potential bug layer.

Not even just “potential” in QT’s case, a quick search turned up https://forum.qt.io/topic/31071/moc-and-qt_version_check-bug and https://forum.qt.io/topic/37882/qt-4-8-qt_version_check-and-... as cases where folks have been bit by some tooling in a Qt4 environment not understanding the macro properly.

Windows Version check would disagree with you why this abstraction is required. I forgot the api but there is kernel api that will contradict with your view points.

> That’s just adding another layer of abstraction over exactly what the Mac case does. I prefer code that is so simple it doesn’t need to be abstract, as every abstraction layer is a potential bug layer.

I'm happy for you if you never typed 10150 or 01150 instead of 101500 or whatever but that's definitely not my case and I need any tool that the programming language provides to help me with that ; version macros are unambiguous and I don't remember fucking one up.

In C23 you can type it as 10'15'00 if you’d like.

Surely you see the contradiction in the system you describe as `terrible` being the exact same as the system you call `good`? In either case, macros are available in modern versions but attempting to use them in old versions causes problems (see the links above), so the practice is to not use them at all, if you may have to target older versions.

> Surely you see the contradiction in the system you describe as `terrible` being the exact same as the system you call `good`?

how is it the exact same ? Where is the generic MACOS_VERSION(sane, version, numbers) where MACOS_VERSION(11, 3, 0) also compiles on the macos 10.7 SDK ?

Just… write the macro? I don’t see the problem.

Interesting thing about "clean code" I just read today:

https://www.steveonstuff.com/2022/01/27/no-such-thing-as-cle...

The article says we need to use more precise words. In this case, the macro can create a bug, so is using the macro "cleaner"?

Reply on news.ycombinator.com