Page 1 of 1

VLCKit 3.6.0 / 4.0 status

Posted: 01 Mar 2024 23:29
by doodlyboop
Hey folks!

I'm just wondering if there is any information about the roadmap for a final VLCKit 3.6.0 release and any upcoming 4.0 alpha/beta releases. 3.6.0b10 seems very solid in my testing and seems like it could be considered a final version, and it doesn't seem like there have been many Apple-specific commits since it was released.

I'm also eager to mess around with building a player for visionOS so I'm also wondering about any updates to the 4.0 branch (this thread indicated that it's got foundational changes required for this support).

Thanks in advance!

Re: VLCKit 3.6.0 / 4.0 status

Posted: 02 Mar 2024 10:42
by fkuehne
Yes, for 3.6.0, I was waiting for one bug to be fixed for macOS, that was finally resolved last week, so we should be able to do it within days from now. I just to check one last thing regarding Chromecast integration.

For 4.0, I will do another alpha soon, but without visionOS so far. There are a few things to do to make it happen. Contributions would be welcome.

Re: VLCKit 3.6.0 / 4.0 status

Posted: 04 Mar 2024 17:50
by doodlyboop
Thanks for the info! Great to hear that 3.6.0 is on the verge of being final (and fixing that NSLayer thread bug!)

Can you elaborate a bit on what things need to be done to make visionOS support happen on the 4.0 branch? It feels like it'd essentially be a tweaked version of the iOS-specific implementation, since 3.6.0b10 does work fine in visionOS when run within an iPad-compatible bundle.

Re: VLCKit 3.6.0 / 4.0 status

Posted: 21 Mar 2024 00:11
by doodlyboop
Thanks for all the work you've put in towards the v4 branch in the past few days @fkuehne! I was eager to give it a try, so I manually downloaded the v4a4 archive referenced in the master branch podspec. I see it's not yet available via official cocoapods yet, possibly because of some issues with how it's packaged. In case it's helpful, here is what I had to do in order to get a basic project to build:

1. Update all modulemap files to reference the proper umbrella header of VLCKit instead of MobileVLCKit
2. For the mac-specific framework, in VLCMediaThumbnailer.h ensure this import not gated: #import <CoreGraphics/CoreGraphics.h>
3. For the mac-specific framework, in VLCKit.h remove the imports for VLCVideoLayer.h and VLCVideoView.h

Despite this fixing general compilation, I could not get it running on any devices possibly because the hashes of the files had changed (a runtime issue would be reported of missing libraries).

In other news, 3.6.0b11 is working great in my brief testing! Thanks again!

Re: VLCKit 3.6.0 / 4.0 status

Posted: 21 Mar 2024 06:03
by fkuehne
Thanks a lot for detailed feedback. It is weird that you had to remove VLCVideoLayer.h and VLCVideoView.h as those are Mac-only classes. However, it is possible that I don't distribute those headers... I'll check!

I'm not sure why modified files would prevent playback for you to be honest.

The 4.0.0a4 is available through CocoaPods. You just need to specify this version specifically.

Re: VLCKit 3.6.0 / 4.0 status

Posted: 21 Mar 2024 06:27
by fkuehne
Can you please try the next build here when it becomes available in a few hours? https://artifacts.videolan.org/VLCKit/d ... CKit-main/

Re: VLCKit 3.6.0 / 4.0 status

Posted: 21 Mar 2024 14:49
by doodlyboop
Thanks for the quick changes! This works on macOS, but I had to explicitly allow it in system settings -> security because of how it's signed. This might be related to how I'm just adding it as a standard framework reference as opposed to loading it via Swift Package Manager or Cocoapods, not sure.

Looking forward to testing out a cross platform version! My project is actually set up to use Swift Package Manager, so I use this particular solution: https://github.com/tylerjonesio/vlckit-spm. I believe the way that you're creating this new v4 framework is close to being usable in SPM since it's all in a single fat framework.

Re: VLCKit 3.6.0 / 4.0 status

Posted: 21 Mar 2024 15:11
by BroadcastTV
I haven't come across any solid roadmap details for VLCKit 3.6.0 final release or any upcoming 4.0 alpha/beta versions. From what I've experienced, 3.6.0b10 seems pretty sturdy. If you're itching to explore visionOS, it seems like the action is over at the 4.0 branch where they're making those changes.

Re: VLCKit 3.6.0 / 4.0 status

Posted: 21 Mar 2024 16:51
by fkuehne
There are milestones on the VLCKit project that should give you an idea on what we plan to do. We did 3.6.0b11 this week to do an actual release synchronized with VLC 3.0.21 for desktop, probably next week.

For SPM and visionOS, this will come in version 4. Both features will not come to the 3.x series.

Re: VLCKit 3.6.0 / 4.0 status

Posted: 22 Mar 2024 19:06
by doodlyboop
Thanks for the outline @fkuehne! It's easy enough to use the script that tylerjonesio provides to create an SPM package for the 3.x series, so no worries there.
The 4.0.0a4 is available through CocoaPods. You just need to specify this version specifically.
Wondering how these two will differ in the 4.x versions. Should all 4.x specs be removed for MobileVLCKit?

https://github.com/CocoaPods/Specs/tree ... bileVLCKit
https://github.com/CocoaPods/Specs/tree ... f/4/VLCKit

Re: VLCKit 3.6.0 / 4.0 status

Posted: 22 Mar 2024 20:43
by fkuehne
I'm not sure Cocoapods allows us to remove releases that we already pushed. However, alpha builds will never be recommended to third party users. We are not 100% decided yet whether we will only ship one large framework for all platforms or whether we will continue to do per platform releases. If we decide to do the latter, the TV and MobileVLCKit podspecs will continue to be updated. Otherwise, they will be deprecated in favor of a generic spec (with a developer visible warning that this happened).

Re: VLCKit 3.6.0 / 4.0 status

Posted: 22 Mar 2024 20:54
by doodlyboop
Makes sense to potentially keep frameworks separate, as these static libs are quite large and many devs may only want a framework for one platform. I could envision an approach that packages a global x86_64 / arm library solely for the shared lower level libvlc code, and then wrapper frameworks per-platform that share that library and bridge to higher level platform API's, but that certainly gets complicated at a tooling level and is possibly not feasible/doable.