Video filestream trouble shots feedbacks

vvvv beta question
1

hi everybody !

since a long time i didnt post here.

i have some time actually to post this statement about video files players in VVVV.

first, i m using VVVV since quite a long time (2009), and i m around 2 or 3 big shows each year requiring video players, and precise timing in diffusion (not sync, but precision).

i m using mainly filestream(directshow) as a player, with WMV files

it is strong, and quite reliable, until version 30.1.
From version 30.1 from time to time, depending of the computer (VRAM and gfx card different) and the duration of the file (big files are giving some time hard time): video frame rate is not at all respected; this can be temporarely fixed by reloading from node inspektor the filestream player. Its happends me quite regulary, and i had to retrograde to beta26 to avoid this trouble.
(quite a lot of time spended on this trouble in fact)

one of the other leak with this node, is to need a kind of first play to load the access of the stream completely in memory.
if you dont play it completely, you may experience a freeze in the playing of the video. this for all versions of vvvv.
one of other leaks is the impossibility to work with it on the speed if it is not an avi raw

VLC options
i was looking really strong about VLC. From the first plug in written.
its hability to read multiple files, and has speed support very well done.

Actually VLC plug in looks like nice, but in fact its quite VERY buggy, and opening very big memory leaks, resulting on closing simply vvvv (yes, no warning panel about exception …)

  • first, on all add ons collections i have tried, VLC is running only onx86 version

  • second, depending of computers, you can experience the very first 3 or 6 seconds of your files being GREY. i never founded from where it can come. no codecs troubles, no gfx configuration. VLC player salone is working ok.

  • third, with avi in RGBA you may crash vvvv quite easely

  • using damper somewhere in the logical chain tool also ( by the hell when damper is not working its giving all the time bad values likes -EA7681a for example)

voilà, i hope this will serve discussions and developpement of VVVV, because i think there is really BIG AMELIORATIONS to do fo our beloved video software(isnt it ?). A videoplayer should just working fine…

yours, christoph

2

hey man,
welcome back!
VLC: I still have this issue open
https://discourse.vvvv.org/t/12296
and yes sometimes appcrash

3

hei karistouf good to see you back.
lets discuss one thing at a time. better start a separate thread for vlc. here is about filestream dshow9:

you say there is a change of behavior wit 30.1 but there is no beta30.1. which do you actually mean? and have you tried this with latest b33.3 as well? also could you provide a simple demopatch plus video that shows this problem if it still persists in b33.3?

4

hello joreg !

hum, sorry i had a lot of work so i didnt get time to come back as i should after this feedback !
and sorry i wasnt precise for the 30.1 thing ! (29.2 ?)

ok just getting back about filestream Dshow9 player,yes frame rate works PERFECTLY with 33.3
i have tested it on last production on a 25minutes videos working with an external audio source. it works pretty good !
this with wmv files. yes 33.3 is working really better.

about my feedback:

-there is still a remanant image while running the player a second time: the image it was displaying when set to 0.
(see video player included, it is remoted by 1 channel in artnet, and > node is used to save ressources). Im avoiding frame delays node (switching to a blank texture ?) because frame delays may cause serious memory leaks on certain laptops (especially low prices/good GPU ASUS ones).

- about pre rolling:
depending of the computer ( i have made tests with 2 exactly same computers, and with differents other machines) i need to pre read a wmv video file before play.
this pre rolling depends of the computer and vram.
some computers needs to preroll just 30seconds, others the complete file.
wich can be annoying if you have files very long (30 / 50mn).
setting up the show may became… complicate ?
otherwise if i dont pre roll i have jitters/mini-freeze in the play exactly at the sames timings (it changes from computer to computer).
i precise this happens with SSD also.
i m using VEGAS 10.0 to edit my videos, and files are only FULL HD ( no 4K videos or what else)

voilà !

:)

yours, christoph

LecteurVideo.v4p (23.0 kB)

5

hei karistouf,

again i have to ask you to be more precise, i still have no understanding of your problem. now you say it runs perfectly but then you say there is a “remnant image”. but when do you have that? what are you doing to see that? are you trying to play the video in a loop and you’re saying that at the loop point you see a little freeze? the patch you included does not explain anything.

regarding pre-rolling: i can understand this is necessary and frustrating but also it is out of our hands since vvvv is only using directshow there and such issues most likely come from it directly. this is then were we’d have to point to other playback solutions like vlc or Player (EX9.Texture) which should at least have different problems…

6

hello joreg !
nice to read you :)

well, i will try to be more explicit ( grrr you forget i am always VERY clear ;) )

filestream Dx9 works really great in 33.3 reguarding the feedback i was doing about framerate stability. on this side it is now ok.

coming back to the filestream DX9:

PREROLLING AND PHILOSOPHICAL QUESTION:

I m saying that prerolling is necessary to have (without loop point) a fluent video stream, without jitter.
This jitter happens at a special moment, always the same inside the play of the video.
This jitter position depends generally of the computer.
Its not the same point when you test it with different computers. On a computer jitter will occure at 1mn10 and on another at 3mn or 10mn.
Anyway, this little jitter, is really noticable from any audience if i dont preroll

Pre rolling is for me: play completely the file, or play a certain amount of seconds, depending of the computer, wich will ask me to play first 30 or first 10 seconds of the file to avoid the jitter.
If i take 2 exactly same computers, the time of pre rolling necessary to avoid the jitter is the same.

Philosophically:

I m obliged in my cuelist to have a bundle of memories to be played before the entry of audience a certain amount of time, depending of the computer.

Wich means for my shows, that i m physically always pre rolling my videos 1h30 to 2hbefore the audience enter the theatre. it becames quite a lot of time, sincerely…

i can t rely actually on VLC. Sincerely the grey effect at the beginning of the playing is quite a mess, and seems not to appear on all computers with same installed packs and software. so for me this bug is really something i wont let my show running with.

REMANENT IMAGE:

if you use the subpatch i have included previously: I m using alpha input to control:

  • apparition of the image with the alpha
  • play of the file stream
  • ON/OFF of the quad, to avoid ressources consumptions.

lets say i m sending cut the video file on stage, and so the alpha input is a toggle

if i just open the computer and windows, and launch VVVV, i will display CUT my videofile without troubles (except the preroll thing, of course).
the first frame to be displayed on stage will be the first frame of my video.

if i have run my video file wich is making 3mn length, and made a stop (alpha input at 0) at 1mn position, the node will keep the image in memory.

When i will make CUT ON my video file again, with audience, there will be the remanent image of the file at the 1mn position that will appear a couple of 1/10 th of seconds.

wich is kind annoying, because i m not vjeying, i m videoing theatre and danse

i would like really to avoid this thing and that the videotexture node, or the quad node (?), thats displaying this image is reseted and clear when alpha is zero.

i have tryied previously framedelay without great success except some unexecpeted pointers boundaries violation on complexes projects. so i m the more possible avoiding it.

i would really be happy if we can have a solution on this point.

voilà :)

yours

7

  • prerolling:
    from what you write that you have different results on different PCs it sounds to me like a disk-fragmentation issue. not sure if in 2014 something like this really still exists, but you could try: get an empty SSD, put only one video on it. use that SSD on one PC and see what prerolling you need. then use the same SSD on different PCs. if i am right the prerolling time needed should now be the same on all PCs.

  • remnant image:
    still a bit hard to follow, but if i get you right you just need to patch it the right way: the patch shows that you Do Seek the filestream only after the alpha > 0.13.

so you clearly first fade in the old image, then jump to the new one. instead jump to the new image when alpha is exactly 0 or even not the moment you’re returning to play but the moment you’re going into pause.

8

hi joreg.

about pre rolling:
for me its not a pre fragmentation issue. it happens on brand new computer with just the show installed on them, and also ssd.
if i understand well: you know this problem exist and we cant resolve it. is that right ?

remanent images:
Do seek should be 0.0, and is usually 0.0 in my patches.
here inclosed a zip with a video file.
the beginning of the file is black.

just play, stop, and play again, you will see the remanent image.

remanent image.zip (5.4 MB)

9

  • prerolling:
    i don’t have any particular experience with that problem but can imagine it exists and don’t have any idea of how to get rid of it out of the box.

  • remnant image:
    jes, as i said, it is a question of patching, see attached. here i seek on TogEdge Down (instead of Up) and leave the Quad enabled so the video can seek (which it can’t when the quad is disabled in the same frame).

LecteurVideo.v4p (23.0 kB)

10

argh damned me… since 2 years i never think to tog edge down …
ok. i owe you a beer… thanks !
edit

putting a slider in place of the toggle still shows remanant image.

about pre rolling this feature doesnt happens with vlc. so i presume this is not a trouble coming from defragmentation.

stil remanant.zip (4.0 kB)

11

putting a slider in place of the toggle still shows remanant image.

12

*prerolling
“this feature doesnt happens with vlc. so i presume this is not a trouble coming from defragmentation.” we don’t know how vlc or directshow handle this internally so i’d say such a conclusion is not allowed here.

“it happens on brand new computer with just the show installed on them, and also ssd.” i didn’t argue that it would not happen at all, only argued that it should show the same behaviour on different PCs if you’re using the same clean SSD with only the video on it.

*remnant image
still a question of patching. read what i mentioned above: “the patch shows that you start playing the filestream only after your alpha > 0.13.” so of course you’re showing the old image for 0.13s.

13

“we don’t know how vlc or directshow handle this internally” > ok i understand.
would be great to avoid this preroll in real life, quite painfull for basic usage

patching: oh damned me and DOUBLE beer for you joreg.
ok great, togedge down is now listened :)

thanks a lot joreg

14

if u have alpha channel in ur vid that might be a codec related problem