Valentin

I have a patch which functionally does what I want, but I can't figure out how to fix one aspect which affects CPU usage.

The patch reads a qt movie in uyvy mode, then does the conversion to RGBA on a slab. Problem is that I have a shared context where I want to take the same movie and display it as a thumbnail within a larger pwindow.

I have it working, but I can't figure out how to do the thumbnail as a portion of the larger pwindow AND do the uyvy to RGBA conversion on the slab. Something about how I'm patching it up only works if I do the conversion using jit.uyvy2argb which hogs way more CPU than I want to use.

The patch will make it all self-explanatory I think:

The patch reads a qt movie in uyvy mode, then does the conversion to RGBA on a slab. Problem is that I have a shared context where I want to take the same movie and display it as a thumbnail within a larger pwindow. 

uyvy-conversion-question-slab-vs-cpu

I guess I'll have to try another approach - doesn't seem to be any interest on the forum with this question - lol

how about this? (btw, do you really need 200fps with qmetro 5?)

btw #2, you're better off using a jit.window instead of a jit.pwindow for your preview as well. pwindows are very inefficient. i've got the qmetro set at 60hz. with jit.pwindow i get 30fps, with jit.window 60fps.

Thanks for the patch and info - I'm in a session now, but I'll def. check it out =)

As far as jit.pwindow vs. jit.window, I will need to be able to track mouseover and mouse click etc. - i.e. there is a lot of user interaction with the pwindow. I forget, can I do the same with jit.window, including tracking mouse coords within the window?

I'm sure there's an equivalent in GL land that will work on jit.window, just don't know which, haven't used such a thing.

I checked out your posted patch. The problem is that with 2 videoplanes on different layers in the preview window, I lose one of the important aspects of my original patch.

When I write to the sub texture in my patch, every time I move the thumbnail, it updates the portion of the texture that it is sitting over. So the texture ends up with the thumbnails getting updated as I move them around. Your patch using 2 video planes, doesn't update the portion of the texture, so when I move the thumbnail, the underlying video stays as it was. i.e. the top "layer" doesn't affect the bottom layer.

I need to have the thumbnail updating the actual texture using the subtex messages.

This is what was confusing. I can get that to happen, but only if I do the uyvy conversion prior to sending to the GPU. If I do the conversion on the GPU, I can't get the subtext message to work to create a thumbnail.

Thanks for the idea though. Hopefully there is a way to do what I am trying to do

Ah ok, I overlooked that. It relates to this, right? 

https://cycling74.com/forums/jit-gl-texture-and-dstdimstart-dstdimend

How about not doing uyvy conversion at all, just reading in the movie in rgba? I bet working out how to do it with a window instead of a pwindow will gain you much more than sending uyvy to the GPU.

Ah ok, I overlooked that. It relates to this, right? https://cycling74.com/forums/jit-gl-texture-and-dstdimstart-dstdimend

How about not doing uyvy conversion at all, just reading in the movie in rgba? I bet working out how to do it with a window instead of a pwindow will gain you much more than sending uyvy to the GPU.


I'll check out the possibility of doing the window instead of pwindow, but there's a lot more going on in my main patch, so I'm trying to keep as much on the GPU as possible, and saw a big boost in performance when I went from RGBA to uyvy and converting on a slab.

I'd really like to try to keep the patch the same, but get the subtexture working here.

why don't you just use something like a scaled down jit.gl.videoplane to display your thumbnail?

That's what I patched for him but that doesn't do the feedback/compositing part.

Exactly . The idea is not just to get a thumbnail video to sit in position over the other layer of video, but to have it replacing the "underlying video as it runs, wherever the thumbnail sits.

The original patch I had posted works functionally as I need it to, but I'm looking for a solution that also does the uyvy conversion on the GPU.

dtr, I did get the mouseover functionality to work just fine using jit.window instead of jit.pwindow - That was actually pretty easy as it uses the idlemouse attribute much the same as the pwindow. Thanks!

Still searching for the solution to the original problem. =)

you can make this work by using jit.gl.node to capture the two layers (static backgroud and dynamic thumbnail)

then a third videoplane on the pwindow context too display the captured texture.

for the feedback, you also send the gl.node captured texture back to the background videoplane layer.

also, you should use jit.window/jit.pwindow @shared 1, rather than the deprecated gl.render @shared_context.

you can make this work by using jit.gl.node to capture the two layers (static backgroud and dynamic thumbnail)
then a third videoplane on the pwindow context too display the captured texture.

also, you should use jit.window/jit.pwindow @shared 1, rather than the deprecated gl.render @shared_context.


Thanks as always for the help. I think this will work very well!

I did notice that on my setup, the patch you posted has a flicker that happens every few seconds on the thumbnail.

Does it do that on your setup as well? Is there a way around it?

uyvy conversion question - slab vs CPU