Hi there ,
I’m actually having issues on a project.
I am getting what I would call stutterings ( or lags ) on my outputs.
The project involves mainly video in + video playbacks.
All my images and outputs are 1080p50, the patch runs at 50fps ( locked by vsync ).
I am using the “classic” DX11 renderer, with vsync & flip sequencial activated.
The problem is mainly visible on images moving horizontally.
If anyone has ideas, they are welcome…
Thanks.
Mehdi
Try the renderer (form) I think thats meant to fix tearing issues
@catweasel : I will try this. Thanks.
I think my problem here is not really tearing. It doesn’t look the same.
Is your display set to 50Hz and does it really support it ? Some displays report 50Hz via EDIT but internally the panel interpolates to 60Hz. Also the videos have to be encoded with 25 or 50 FPS (not 60 or 30 or 29,997).
Otherwise you are going to have “judder”.
and what are you using for videoplayback? is that framelocked?
@bjoern I’m using a Panasonic beamer ( 10000 lm laser, new ). I’m suspecting it to be “native” 60fps as Japanese. The problem appears also on a Blackmagic display.
@woei do you mean by framelocked > genlocked ? In this case no. My cameras don’t support genlock. But the problem appears even when displaying only one source. So I would consider that it doesn’t matters. I might be wrong on this point ?
Best
Mehdi
overread the video in part, thought you were referring to video file playback.
i was wondering if you’re video(file) source is handing out a new frame with every renderframe.
so does your videocapture deliver a new frame every frame rendered? or does this one already lag? is the capture at 50hz as well?
for debugging, try rendering only generative content, to see if you still have the stuttering, to maybe narrow down the source to videocapture.
or check perfmeter, if the lags are visible as cpu spikes. then it might be garbagecollection…
too many places to look for the culprit, too many ways to start searching… :)
Hey Mehdi, I see you’re still stuck at that point … Sorry!
I can only suggest to build the problem step by step. Does it appear on one screen that can support 50hz natively? then add a second one etc …
Hi, thanks for the interesting inputs.
To define more precisely the problem :
If I connect my camera directly to the beamer ( SDI 1080p50 ), or passing in an ATEM ( mixer ), the signal is perfect.
I think @bjoern is right in identifying it as being Judder.
With signal coming from v4, I have some judder effect.
I use 2 outputs on my GPU, both at 1080p50, HDMI converted to HDSDI by Blackmagic Teranex Mini converters.
These support 1080p50 natively for what I know.
The patch runs at 50 fps ( vsync “locking” it, perfmeter stable and showing allways GPU, wich is normal I think ), all my “playback” content is 1080p50, camera feeds are also 1080p50.
@eno : This problem is different than the original problems I had with the decklink plugin. But I could not identify or notice this judder problem before having a “clean” capture.
I am wondering if there could be something in the DX11 rendering that creates this effect.
Best
Mehdi
I am seeing activity in perfmeter in “preparegraph”.
This happens quite randomly. It’s not linked to anything happening specially in the patch for what I can say.
Has someone any advice on this point ?
I’ve been searching the forum about preparegraph, but I did not see anything very relevant.
As a side info, this is happening having two monitors, both having a dx11 renderer in full screen. The patch window is not visible ( under my control screen renderer ). The patch window is minimal ( 8 subpatches, no IO boxes displaying values ).
Mehdi
Are these two individual renderers and do they both have vsync on?
That must lead to framedrops, if the outputs are not clocked.
Try to create one desktop spanning both outputs and then using one renderer instead of two.
Hi there,
I finally found the issue…
Unevaluating a subpatch containing an UDP send ( to localhost, osc ) solved the problem. The lags were appearing even when not sending anything.
No more lags…
Hard to debug ! But we’re performing smooth now.
Don’t want to open a big discussion here, but it would be so nice to think about a way to give some kind of “priority” to the critical rendering parts of a patch. I know there can’t be any magic with vvvv knowing by itself what is critical for me…
Thanks for all the inputs anyway.
Best
Mehdi
See @joreg it’s always the UDP spoiling the performance. I had that so many times! And it only appears in critical setups, almost no way to reproduce that in a simple patch.
As a hint: VL UDP is clean.
1 Like
@eno funny and a bit sad to read…
I must say the issue is not so easy to detect, but if you want a perfect playback for hours on a 10m screen, and keep your eyes on it, the udp node was creating some little stutterings.
Mehdi
Men staring at rolling bars.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.