FileStream (DShow9) воспроизводит следующие форматы файлов (если нужные кодеки установлены в системе):
Пин Filename не спредабле - можно воспроизводить только один файл.
Есть два нода видеотекстур.
Простое преобразование, работает со всеми версиями WindowsXP.
Работает только для WindowsXP ServicePack 2 или более поздними версиями. Включает де-интерлейсинг и должен работать быстрее в некоторых случаях.
For Quicktime playback in vvvv you need quicktime alternative 1.81 installed. this version of quicktime alternative was the last that had directshow filters included. later versions had those removed for legal reasons. this means though, that quicktime codecs released later than may 2007 (the release date of qt-alternative 1.81) probably won't play..
For the playback of .amr files you need the Quicktime Plugin by MediaLooks (and vvvv > beta13.1).
It should also be possible to use the QTSource plugin for AviSynth.
Switching between videos can be done without stuttering. I have achieved smooth switching of video clips by attaching a Switch(string) to the filepath inlet of Filestream. This works with the codecs Mjpeg and Xvid.
i've tried setting up an iobox (string) with different file paths, and connecting to a filename, then to the filestream (which goes into the video texture), but this doesn't seem to work (the video doesn't play).
beware that the FileStream is not spreadable. it only accepts one filename at a time. use a GetSlice after the IOBox to route only one of the filepaths to the FileStream at a time. Switching between videos will very likely cause the output to stutter. If that's annoying the only thing you could do is make one large movie an loop between different start/endpoints in the file.
Another method you could try, is to use AVI-Synth to join the movies via script. theres a package that automates the whole process. download here: http://vvvv.org/tiki-download_file.php?fileId=1646AVS AVI Joiner.zip (7.64 Kb)</a>
This seems to happen when your cpu is running near 100% of load.
DirectShow video playback under windows has a very low priority by default. So if someone is consuming too much cpu, video playback gets jerky. Using all available cpu is obviously the way to go with rendering realtime graphics. Setting the 'waitforframe' pin tells vvvv to wait for the windows up until it has delivered the next frame.
The value on the pin is measured in milliseconds. So if your video has 25fps each frame gets shown 40ms. So it makes sense to wait up until 40ms for the next frame to arrive.
Alternatively you could create a MainLoop node and decrease the value of 'foreground fps'. Note that is usually does make sense to have rendering framerate and video framerate matching, but if your patch consumes to much cpu there is not much you can do.
to make it looping you have to set the StartTime and EndTime pins. both default to 0. To loop the whole video you can leave the StartTime at 0 and set a vey high value at the EndTime pin, like 999999, Filestream will loop at the end of the video then. To loop just a part of a video, set the pins accordingly.
Everytime a video is looping it stops a short moment before it starts to replay. How to avoid this?
You can optimize the looping by using a codec which is optimized for random access - we had pretty good results with the picvideo motion jpg codec. For other codecs it might help setting the amount of keyframes to a higher level.
The Filestream node always streams the data from disk - this is a time consuming process. Also the Windows multimedia architecture is not really build for creative use of video. So the best strategy for getting high quality looping is avoiding the avi-file format altogether.
For short clips the playback works best with a spread of textures: Create a directory full of still frames, use a dir node for getting the file names in alphabetical order. Connect a filetexture to load allmages as a spread. Connect the output of the FileTexture via a GetSlice (Node) to a quad (or whatever object you use). By changing the index input of the use a framecounter, counter, or a + / framedelay-loop for changing the index.
Note that you are not getslicing the filenames here, but the textures itself.
Next step is preloading all textures: Usually vvvv tries to optimize the video memory load of the graphics card by automatically loading and unloading all textures which are currently invisible. You can familarize yourself with the preload process by opening a Renderer (TTY). Loading from disk will obviously massively degrade performance when cycling through textures.
For now, preloading can be done only with a small hack: create another quad, set the quad to an unused render pass (like 4444) and connect it directly to the output of the spread of all textures. vvvv now thinks all textures need to be drawn each frame and keeps them in memory. make sure you set the render pass, otherwise all quads actually get drawn - of course this could massively degrade performance.
By changing the index of the getslice you should get an instantenious and precise playback of all frames without any delay. Modern graphics cards have up to 256MB video ram - so you can actually preload an impressive amount of images. use the Memory (Debug DX9) to get an estimates of the free memory on your card (ask microsoft about the details). Modern cards can also access the main RAM (google for AGP aperture size) - this is much slower then using the video ram, but usually also fast enough. With a higher number of textures you might come to another border: windows start swapping ram to the hard disk – this will also kill performance. The harddisk led shouldnt light up when playing back your loop.
If you have only 64 very small frames you can do an old video game programmers trick to get even more speed: Arrange all frames in an 8x8 grid on one large texture. Use GridSplit and a Transform (2d) to calculate a texture transformation baed on the coordinates of the current frame. GridSplit allows you to set diffent grid sizes, so you can use any grid you like. Surpisingly enough the current beta has a help patch for GridSplit - press F1 over the GridSplit node.
Both methods also allow you to play videos on many objects at different framepositions - this will typically not be satisfying when using multiple filestreams
you could use the Queue (Texture) to preload an avi.
FileStream -> VideoTexture -> Queue -> GetSlice
now play the file and DoInsert in the queue in every frame. when the film is finished stop DoInsert in the Queue. now the queue is filled with textures and you can use GetSlice as described above to loop through the movie.
of course the same videomemory boundaries apply to this solution since the queued textures will be placed in videomemory.
I´m afraid though that to my knowing Queue (Texture) only works on ATI cards due to a driver bug in the recent nvidia drivers.
at 50hz. you'll want to wait for every (1) frame.
anonymous user login