video received vs low refresh rate (low specs machines)

[jonjamcam]

I use Jamtaba very often on a very old machine with refreshrate set to 1 and it works very nicely. Very low cpu use until remote video is received. There are two issues here:

1.- lowering refresh rate has an impact on the video frames received. Looks like all frames are shown using the low refresh rate so video is slowed considerably, as in slow motion

2.- all the cpu improvements of low refresh rate are reversed.

I think there should be an option to avoid video rendering of remote tracks (json?). ATM I'm using a hack for this purpose and manually turn off the receive button on video tracks, which solves the issue.

[jonjamcam]

@elieserdejesus One question. Is this the code that renders remote video on ninjam tracks?

// video if (!decodedImages.isEmpty()) { quint64 now = QDateTime::currentMSecsSinceEpoch();

quint64 timePerFrame = 1000 / videoFrameRate; quint64 diff = now - lastVideoRender; if (diff >= timePerFrame) { // time to show a new video frame? lastVideoRender = now - (diff % timePerFrame); auto &currentImages = decodedImages.first(); if (!currentImages.isEmpty()) { updateVideoFrame(currentImages.takeFirst()); } else { decodedImages.removeFirst(); // avoid show the last received frame forever } } }

[elieserdejesus]

yes @jonjamcam , this is the code. But if you just comment this code the "Current Images" will store all decode frames without render, using more and more and more RAM. To work without side effects is necessary remove the frame from "currentImages" and just skip the "updateVideoFrame" function.

[jonjamcam]

A solution is to set a minimum resfresh rate to 10. Values less than 10 will distort video. PR https://github.com/elieserdejesus/JamTaba/pull/1383 created

[jonjamcam]

Solved in https://github.com/elieserdejesus/JamTaba/pull/1383