[jit.movie @output_texture 1 @texture_name N ] vs [jit.gl.hap @out_name N]
Hi all,
I have a quick question,
I thought setting up [jit.movie @output_texture 1 @texture_name N ] was making jit.movie run on the GPU side, not converting a matrix to a texture
Like so:
[jit.movie]
|
[jit.gl.texture]
----
[jit.gl.hap] seems to do this. The player is entirely in GPU.
----
why I ask ?:
Because I've been comparing both methodes with a jit.fps.gui. and Hd videos
and I always win a 20fps with jit.gl.hap!
thank to anyone to shedding light or confirming this
phiol
reporting back for an update on my testings/findings
I kept on testing with jit.movie in different colormodes and using a 4k video.
Here are my conclusion notes using a 4k H.264, (3840 x 2156) mp4 video
(youtube: https://www.youtube.com/watch?v=0vrdgDdPApQ)
Downloaded using free app: 4K Video Downloader
--------
-gl.hap has a CPU of 175% in activity monitor/solid fps 59fps
-jit.movie with @mode uyvy @texture_ouput 1 @texture_name N == fps 36 / CPU 54%
-jit.movie w. @mode rgba @texture_ouput 1 @texture_name N == fps 36/ CPU 70%
Best == jit.movie @mode uyvy but if you want to use [spigot~],
you'll need to use the qt engine making the CPU performance rise to 151%
@C74 Any chances in getting spigot~ working with the avf engine in future releases ?
I get we can always use the [groove~ ](right outlet) method , but spigot~ is fast :-)
Below is the dead simple patch I used for testing
My Computer :
mbp 15" retina (late 2014)
os 10.9.5
Memory 16G
processor: 2.8 GHz Intel Core i7
Gpu :NVIDIA GeForce GT 750M 2048 MB
bump !
Could anyone of you add clarification
on the first post of this thread.
Thanks so much in advance :-)
phiol
hi phiol, i'm not sure what your question is.
Hi Rob
Context of my understanding: [jit.gl.hap] vs. [jit.movie @texture_output 1 @engine avf]
-gl.hap loads the movie entirely in GPU.
QUESTION:
-[jit.movie @output_texture 1 @texture_name bla] is == jit.movie
OR
is making jit.movie @output_texture 1 == jit.gl.hap.
Meaning everything is GPU?
----
I thought that [jit.gl.hap] was the best situation
but the 2nd post of this thread showed my interesting results.
Making [jit.movie @engin avf @colormode uyvy @output_texture 1 @texture-name bla] THE WINNER!
in fps and in CPU.
Although, this is not true when switched back to @engine qt.
Hope this is more clear.
thanks Rob
phiol
jit.movie @output_texture 1 @engine qt is more or less equal to jit.gl.hap playing back non-hap encoded files. they use the same basic software library when not playing hap-files.
jit.movie @output_texture 1 @engine qt is not equal to jit.gl.hap when playing back hap encoded files.
jit.movie @output_texture 1 @engine avf (the default) is not equal to jit.gl.hap. different technology entirely.
the two most efficient options a jit.gl.hap playing hap encoded files, and jit.movie @engine avf @output_texture 1 @colormode uyvy (if not using alpha) playing prores files.
Thanks so much Rob,
This is very useful info and I hope it will be of benefit for others as well.
I didn't know that @colormode uyvy did not permit alpha.
-I did convert a few .mov to hap codec and turned a 1G file into 14G file size.
Crazy.
-It would probably explain why when I put .mov files in gl.hap I guess a CPU% of 150%.
The conversion is being done in real time. <
thanks for you info Rob.
much appreciated
phiol
type-o that I keep for this forum ;-)
Phiol, thanks for sharing this great walkthrough
I am playing a 4K video in a windows 7 machine i7 core, 16GB ram with a dedicated SSD.
The video runs ok but I can notice very small frame jumps.. do you have any solution for this?
Right now I am using appleprores codec, already experienced HAP in windows but didn't got satisfying results.
This is the patch I am using, it's very similar to yours:
you could try a different codec, like photo-jpeg.
however, i'd be surprised if on Win-32, jit.movie @output_texture 1 with a prores or photo-jpeg encoded file performs better than the jit.gl.hap object with a HAP encoded file.
I removed the @output_texture message and now I have a solid 30fps with a very smooth frame reading.. it is a pitty that HAP is not working good for me, so I will have to stick this solution for now
Just a question, so if you set jit.move @engine viddll and @output_texture 1 and play hap encoded files, what is actually happening then?
I tried this and my CPU sky-rocketed to 200-400% CPU, while using jit.gl.hap it says nicly at 60% more or less.
I'm having issues with playback with jit.gl.hap, every time I select a new file all playback stops in other videos playing making a very nasty stutter. So I figured I should test the jit.movie with hap files and the viddll engine. But, that was not a good option.
Could I also ask, does it matter what type of coded your files are before converting them to HAP codec? Will that influence playback? Stupid question, probably, but I've tried everything, and cant get ridd of the stutter when loading new files.
here is a test. Press 1 to change file in one of two hap objects. Se how the other playback "stops" momentarily while this happens.
currently jit.gl.hap will play Hap encoded movies more efficiently then jit.movie @engine viddll.
the FFmpeg Hap decoder does not decode directly to the GPU like the jit.gl.hap object does, and therefore takes more CPU. whether that translates to a better performing patch is of course dependent on a variety of factors specific to hardware setup and patch.
the best solution i can give you for stutter reduction is to use the jit.movie @engine avf with "asyncread". I've also heard reports that if using this in conjunction with jit.world, you should disable displaylink rendering (jit.world @displaylink 0). jit.movie @engine avf plays very nicely with prores, h264 and photo-jpeg encoded files.
as always, with and jit.movie engine, best results require @output_texture 1
alternatively, preload all you movies using a poly~ abstraction.
hard to keep up with all the various solutions. @Rob is a possible upgrade to viddll's HAP playback coming in the future, or is it locked into to the FFmpeg decoder? It's honestly been very good for my uses, but i always see you saying that avf + prores/h264 might be better in circumstances, so i'm just wondering if that is temporary, or if viddll's HAP limitations will always exist. Thanks.