» Воспроизведение видео файлов
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Воспроизведение видео файлов

English | French | Italian

The original english version of this page is newer and may contain information this translation does not have! Click here to view the english version.

Воспроизведение нодом FileStream

FileStream (DShow9) воспроизводит следующие форматы файлов (если нужные кодеки установлены в системе):

  • .avi
  • .mov
  • .mpg
  • .rm
  • .wmv

Пин Filename не спредабле - можно воспроизводить только один файл.

Видео-текстура

Есть два нода видеотекстур.

Простое преобразование, работает со всеми версиями WindowsXP.

Работает только для WindowsXP ServicePack 2 или более поздними версиями. Включает де-интерлейсинг и должен работать быстрее в некоторых случаях.

Quicktime Playback

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.

AviSynth

see elektromeier-AVSAVIJoiner

Switching between different video files during a performance

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>

What if video plays jerky or stops playing in fullscreen?

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.

How can i loop a video?

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.

How to avoid skipping while looping

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.

Use many still frames

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.

Use tiled images

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

Preloading the Movie

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.

the short story about framerates and videoplayback:

  1. playback of video can only ever be smooth when the video plays with a multiple of the framefrate of the monitor. consider your video has 25fps then your monitor has to be set to 25, 50, 75 or 100hz vertical refresh rate.
  2. when playing back video let the mainloop nodes foreground fps at 120 because you'll throttle the overal framerate via the videotextures "Wait for every Nth frame". setting mainloop to filtered mode could be a good idea though (that is usually only annoying during patching).
  3. make sure that without playing back your video (mmh..means without the videotexturenode present in the patch - because as soon it is there it is already taking influence) the scences framerate is higher than the videos framerate. if it is not you'll have no chance to playback video smoothly.
  4. understand videotextures "Wait for every Nth frame" like this:
    • if you have your video at 25fps and the monitor at 50hz you'll want the renderengine to wait for a video frame every second frame it renders the 3d-scene.
    • if you have your video at 25fps and the monitor at 75hz you'll want the renderengine to wait for a video frame every 3rd frame it renders the 3d-scene.
    • if your video is at 50fps (like deinterlaced pal video) and your monitor is

at 50hz. you'll want to wait for every (1) frame.

anonymous user login

Shoutbox

~3d ago

cznickesz: @tonfilm thanks for the info. Can´t wait to give it a try!

~4d ago

tonfilm: @cznickesz #vvvv #vl #xenko integration is not ready for the public yet, it's still under heavy development... more updates soon.

~4d ago

cznickesz: Possibly dumb question: is there any release containing xenko-integration right now?

~5d ago

~5d ago

~6d ago

joreg: looking for latest #vvvv gamma preview? it is here: vvvv-gamma-2019.1-preview

~7d ago

udo2013: I just want to know why the camera does not work. should be easy to be answered.

~7d ago

udo2013: an answer, please. also there was a 4d julia set in dx9. that must have programmed one. haalllooo!!

~7d ago

udo2013: where are the people who have translated shadertoy's mandelbulb in hlsl ?? for vvvv