Individual stripes in motion videos and motiongrams

[alexarje]

There are some occasional stripes in the exported motion video images. It may be related to #18.

This also shows up as stripes in the motiongrams.

Strange. Will test some more.

[alexarje]

I can also see that the program adds a line on the right side of the previewed video during the analysis (and this line is not in the original video, so something weird is going on).

[alexarje]

I am running the analysis on both OSX and Windows next to each other here, on the same file, and this line can only be seen on OSX. Strange!

[aleksati]

So this line in the motion videos, motiongram and video preview window is only an issue on OSX?

[alexarje]

Yes, as far as I can tell.

[balintlaczko]

It is really strange that it happens randomly throughout the video and not at the start or the end. Hmm, hmm, will test this.

[aleksati]

Yes, I tested exporting all with 7 different videos and this line/color-artifact is only present on the "dance.mp4" video in the test_videos folder. This seems to be consistent, at least on my OS 10.13.6. I also tried with other .mp4 videos with h264 and AAC codecs but was unable to recreate the same artifacts.. Wierd.

[alexarje]

If we cannot reproduce it with any other videos, I don't think it is worth spending a lot of time on it. Strange, though. This dance video has been my standard test video since 2005...

[aleksati]

Indeed. But let's keep this issue open a little longer in case we experience it, or related bugging, while doing more tests

[aleksati]

Now I was suddenly able to reproduce this problem on a large scale. Although, I don't what I did. They all look like this now, pretty consistently, in both batch and file export. I have some ideas about what it could be so I will do some more testing.

[balintlaczko]

Oi! That looks very mysterious... it looks like as if there were a lot of dropped frames during the render, but I don't exactly see how that could be possible with the framedump method..

[aleksati]

I suspect my early-2011 macbook computing power and low battery.. But need to test some more to be sure.

[balintlaczko]

But that should only be a factor if the framedumping is happening in the scheduler thread, but it is not. Hmm, hmm...

[aleksati]

So found out that the culprit here is most likely the CPU load of running through high res videos. When exporting (or viewing a demanding movie in real-time), there seems to be something that the MacOS is doing which results in a great deal of lagging frames to compensate for something.. Therefore, we get these glitches because the patch is designed to do just this(!) when the same frame is pushed through over a longer period of time then expected. And also, this is a new problem! This was fairly fine until very recently so maybe were pushing the programs capabilities to the max (pun intended), at least for my 2 older macs for 2011. It seems to work fine on Balints windows machine. And also, it seems to work just fine on not too demanding videos.

I guess this just speaks to the need for issue #13 in a future installment of the app. There might be other things we can do to make it more resource-friendly. What do you guys think about this, @balintlaczko and @alexarje ?

On the other hand, there might other reasons. I will at least continue to look for this some more.

[aleksati]

Aah, I think I spoke too soon last night and was a little pessimistic. Im on to something now. Will update momentarily.

[aleksati]

Okay, so I figured out this puzzle and it turns out that both my assumptions were right. The thing is, this flickering has actually always been there but due to the previous processing chain, I have never seen it. When we select to invert a video we invert the image back to normal via the mgt.motion. However, the key is to invert the images back again AFTER the jit.means, not before.

This will produce this result:

instead of this: (both really low res photos btw)

So the flickering is still present, meaning there IS and always has been a problem with exporting high-res stuff on some machines, but we just don’t see it as well when we invert back after the jit.means. Buts its a major improvement to the user-experience, at least. I just had to implement the [VA_invert_colors_if_check_in_menu] in some other key places rather than in [VA_motion_image] (before the many jit.means).

Also, NOT inverting back the inverted videos going into mhi-first and last produces better mhi-first and last, I think. Which look like this:

rather than this:

But please correct me if Im wrong.

[alexarje]

I still see the stripes on OSX (10.11), but only in the dance example video. Haven't been able to see it in others. Can keep this thread open, and see if we can reproduce on other systems and with other files.

[aleksati]

Yes, absolutely. Let's keep this open.