Aaaaaand if the player could output audio to VAudio, it would be even more awesome!
Alpha support and a playhead that allows to accurately scratch trough clips would be on top of my list. If one could write HAP files in realtime as well we could build AV samplers that can record long durations.
until this hap comes to vvvv (which btw I don’t think so will come from vux as he’s concentrating on flaretic which fundamentally can have a more efficient video management than in vvvv) everybody seem to forget the texture Player for EX9 which with a dds sequence is basically the same as hap
(offtopic: this forum is the best with saving post drafts, good job)
/ – kinda offtopic:
@microdee had no luck with texture player (with .dds) using 4k/50fps video. If I preload all frames I simply run out of memory, if I don’t preload all frames I run into massive framedrops as soon as the new frames need be be loaded :/
… h264/mp4 kind of works but won’t loop properly :/ Using openframeworks with ofxHapPlayer just works - unfortunately not the tool I wanna use for this job ;)
–/
you don’t need to preload all of the frames just create a spread of buffered frames like the next 10-20 or so. I have a video player patch on github in mp.dx which converts a video (any length any resolution) with ffmpeg to image sequence and plays them back with player. it uses jpg because I’m using it to seek reference videos only but can be a good starting point for dds based large-scale video playback too.
also on ofxHapPlayer doesn’t ofx has a spout implementation? ;)
Use Filetex Pooled, make sure you have generate mips off, keep in memory off a DXT5A compression for the dds, just dir, getslice (string) single filename to filetex pooled
Hi,
thanks but unfortunately this is just to slow in my case … results in 10fps max. And as far as I can see it’s not the disk IO (come from a pretty fast SSD) what’s killing it but rather the texture generation which just takes to much time (using a nvidia gtx1070).
Should be working like charm if you are on SSD make sure to use compression DXT1 or DXT5 and make sure you have NO MIPS 1, belive me your res is like quarter of what i’m working with right now…
1 Like
Hi,
never mind it’s working now … curious, I was using the Tooools/TextureConverter from @rrrr resulting in 4k dds images of 40mb per file. Now I’m using the dds converter from @u7angel and the filesize is down so 3.9mb :)
1 Like
Hi everybody!
So why don’t we make it happen in 2017? :)
I’ve just finished with making Hap playback solution for Unity (https://www.youtube.com/watch?v=SRSYF4atzTs), which is currently going through Asset Store review process. It’s plenty of work, but If we could collect the money needed for the development, it’s totally possible to do it for vvvv
The proposed solution will work with Hap, Hap Q, Hap Alpha and Hap Q Alpha without DirectShow/QuickTime shit, chunked and hardware accelerated of course
Let me know what you think guys!
4 Likes
if you already have a C# implementation then it’s pretty straightforward to port that to vvvv. vvvv’s plugininterface has similar mechanisms to Unity if you have a source code but no time community might jump on it actually
it was brought to my attention that there is actually someone working on a hap plugin for vvvv and a first prototype version is on github to test. the forces should join, obviously.
@lev i have a few questions regarding your development:
is your hap playback solution open source? this is an important question for future improvements, upgrades, bugfixes and support.
in what language is it written?
how is audio handled in your player? does it support a buffer callback or does it output on a system device on its own?
project funding has happened in the past, just a question of how people organize themselves. but what @microdee said, it’s totally thinkable that a community member does it on a free afternoon. the workload depends of course on how the playback is accessible with C#.
@microdee my implementation is mostly C++, while C# is only used for high-level Unity integration (P/Invoke and friends). However, the native C++ part is still highly Unity-dependent (Unity Native Rendering API, Unity Native Audio). So it’s not nearly a single-evening task to make a stable and feature-complete vvvv integration
@tonfilm C++ part sadly is not going to be open-source. There can be a discussable licensing option which allows to have the native-side code for those who really need it. C# integration code will be open-source, like I’ve done it in Unity case.
It supports the audio buffer callback, and can fill it using any sample format/rate required by the host application (i.e. vvvv). Would be happy to answer any additional technical questions regarding the plugin!
@tonfilm Regarding AE_HapTools.
It supports avi only, so it’s complete pointless at the moment (everybody seem to use mov). The overall stability is under a big question for me, see the limitations section on github. It’s a different kind of project anyway, since it’s completely written in C# (the performance is also under a question). It’s definitely a good starting, but I find my solution more promising by all means. Btw my plugin is used here for video playback, so it’s somehow industry-tested
@tonfilm I believe, essential bugfixes and support should be included in the project funding, since the plugin will be free to use for everyone for both commercial and non-commercial projects.
I also have an option of making a self-funded development with further plugin licensing for users, but that’s why I’d rather prefer not to:
— there is no plugin store for vvvv (unfortunately)
— transparent development process will give a product which is more aligned with the actual users needs
— free plugin for everyone! just get it from the contributions anytime
I think it’s good time to give an overall scope of what I propose to do, so people know what to expect:
— Hap formats: all listed here. I haven’t tested Hap Alpha-only yet, since I don’t have any test files, but I hope someone who needs it, could help me with testing.
— Containers: mov, avi
— Audio: yes
— Loop, seek, scrub: yes
— Multiple videos: spreadable node
— Render API: DirectX 11
— Architectures: 32-bit, 64-bit
yeah that’s not too straightforward then with the C++ part. however licensing-wise in vpm now the user have to agree to licenses which are actually webpages displayed with CEF (Chromium). there you can direct the user to a payment page too. currently the html page cannot talk to vpm but I’m planning to make that thing work so you can tie installation to a purchase for example, or you will be able to use results from the licensing webpage in the installation script (like install different packages based on user choice)
@lev thanks for your input!
situation is on the table, can’t give you a fixed date, but we’ll discuss it on one of our next meetings…
As much a store might be good, at the same time I think it makes takes away from the sense of community we have here. I’ve always like the spirit of free for the casual user, and charging your clients. If you look at the unreal or unity stores, even simple things can cost a few euro’s if you need many then the price becomes ever larger until you could buy a full package for less.
I’d love crowd funding to work better here though.
But I’m not a plugin developer, so maybe I’m biased ;)
2 Likes
a centralised store doesn’t exclude free stuff. it just makes payed stuff possible.