bilderbuchi: say why then guys who play resolume, also turn all thier clips to pic? And about that info on codec, is comment of guy author of resolume, think it’s NSK jpeg originally. But anyways, if codecs related to GPU stuff, belive me that not the one that rocks!
io: you can do pic-mj 3 ql 17 for such res if you don’t want lags.
i did 4096/4096 max video texture with 23-25 fps but i use standalone iCores with RAIDS. But my laptop plays 2x1280X720 for videomixing normally.
hu… what a technical topic !
is there any codec enabling fast triggering inside images keys of a video, enabling slow motion and speed full controll in real time ?
actually i m just doing it with AVI wich makes files very big
antokhio: maybe because they use Resolume 2, or value better interoperability with other softwares more than the speed boost of dxv?
which GPU codecs rock, then, if dxv doesn’t?
btw, i’m still on picvideo mjpeg, too, haven’t converted my libraries to dxv (yet).
Concerning playing (not scratching) video,
I have been working on a audio/video player plugin based on VLC (and nVLC, a .net wrapper for VLC), that renders the video’s straight to a texture, which will hopefully make ‘just playing some video file in vvvv’ much easier.
It also takes care of multiple DX devices on different monitors (unlike using Filestream->VideoTexture).
It will have the possibility to ‘preload’ the next video in the background (1 inputpin=filename, 2nd input pin=next filename), so that you can switch instantly to the next video, even with different codecs, framerates, frame sizes etc… And you can use most of VLC’s functionality like effects (for instance deinterlacing), speed control, resize on the fly if you don’t need huge textures and want to gain speed, or use it to play your webcam, an internet stream etc.
It is not ready for publishing yet, since starting and stopping in VLC is slow, so I still need to get that done in a separate thread, in order not to delay vvvv’s mainloop when loading a new file.
Also, the current VLC versions 1.1.x have a bug so they don’t play a file from the very beginning, but they are working on resolving that issue for release 1.2.
What I would like to add in a future version is:
Anyway, with a bit of luck, I can come up with a version that’s ready for others to see (and use) by Christmas.
ft: is this the thing we saw in the KeyNode?
Well I went for a “Cinemapack” codec, encoding to avi with Virtualdub a series of still frame rendered in Blender.
Something to point out is that Virtualdub 64bit edition won t recognize most of the codecs you may load in your machine cause they are written for 32bit
well… yes… it’s like that, but all the 32 bit codecs will still work in 32 bit apps like VD and VVVV. And if you do an mjpeg it’s no matter what are you using 64 or 32 picvideo or ffdshow… that’s what i like about that.
ft, vux did pretty much the same as a plugin, he showed it at the node10 keynode. he was using the ffmpeg lib, but said he will also switch to vlc… or was it the way around… don’t remember… so, you should maybe contact him.
Yeah got a plugin which does the same thing ish. Using spreaded textures too so you can play multiple videos at the same time with one single node.
Still bit buggy, was using Quicktime decoder but found was fairly low perf for HD. Vfw was better but got a codec hell on my laptop so can’t have it work properly.
The one I was looking at is ffmpeg indeed, which is one of the decoders that vlc uses, and my plan is to use this decoder.
Code is in c++ (engine) and c# (node) by the way. Video loading/decoding is already threaded.
@ft: What output module you use in libvlc? vmem? tried that but didnt found it was very flexible. Also wonder if you do some buffering for the texture copy? on hd vids it can become fairly glitchy otherwise.
Well I needed a video plugin that wouldn’t cause problems with renderers on 2 different screens, and it had to work in october, so when I found out about how easy it was to write plugins for vvvv since 24.1, and found out about the nVlc library, everything kind of came together so I decided to start writing my own implementation, since I wasn’t aware of any other development in that area. The same questions about problems with filestream etc. kept popping up on the forum over and over again.
So the first version just played video or audio files and simple images and webcam or other directshow input devoces, and offered speed- and volume-control, allowed play/pause and seeking. It also allows to decode to a smaller (or bigger) texture size, if you don’t need the full resolution in your textures.
The reason I like Using LibVLC is that I can allow the user to make use of VLC’s builtin filters like deinterlace, crop, etc. etc. (example simply set filename to c:\video.wmv | deinterlace=1) will take care of this. A user can decide he only wants to play the audio from a video file, and no decoding of the video will be done, or the other way around. (example c:\video.wmv | aout=none).
Anyway, I use 2 textures per device (front and back) AND 2 memory-planes for decoding the video (so at this time, everything is somewhat memory hungry :). When decoding to memory-plane A, I can copy memory-plane B (in another thread) to the back-textures for every device, and when that is done, I flip the front- and backtextures, and start decoding to memoryplane B, and use A for copying.
(I have been thinking about using 3 textures, so that I would only need to copy the data to another texture, when there is more than one device.)
I have a first version that is stable I think, that doesn’t ‘preload’ another video yet. And it slows down vvvv when media_player_start or media_player_stop is called, because these calls take quite some time.
The newer version, which preloads video2 in the background AND also controls VLC in a separate thread (so that even the calls to media_player_start and stop etc. don’t slow down vvvv’s mainloop) is almost stable, but since debugging threaded apps can be quite complicated it might take me another few days to get that fixed. Also I think I still have a memory leak somewhere.
And I need to make in spreadable, but I don’t know if/how I can do that with the current PluginInterface yet. If it’s possible, please let me know how.
I am getting somewhere, but when it’s stable there will probably be a lot that can be improved performance wise.