Re: JOGL video rendering.
Posted by Sven Gothel on Sep 11, 2012; 12:44pm
URL: https://forum.jogamp.org/JOGL-video-rendering-tp4026062p4026092.html
On 09/11/2012 01:26 PM, anandcta123 [via jogamp] wrote:
>
> Dear sir,
>
> Why I asked this above question is. I have done timing tests for single video
> and multiple videos playback. The display function of each GLJPanel instance
> is not calling as per the frame rate. Too much delay is there between two
> consequent display function calls (If nothing is drawing inside display
> function) and this will be fine for one video and as number of video GLJPanel
> instanes increases, this is not maintaing frame rate as per single GLJPanel
> instance. So I need to solve this issue first, otherwise I can't use JOGl in
> my application (Because I am using MDI window with embedded JInternalFrame).Even though I would use NewtCanvasAWT w/ a NEWT GLWindow,
which operates w/ less overhead when it comes to rendering
due to GLJPanel / Swing offscreen compositor and AWT threading restrictions,
you can use GLJPanel ...
The issue you describe here looks more like an unclear threading
and multi-buffering implementation.
[1] I would implement a movie player having one thread producing
2 or more Textures in a sequence and sending notifications to
the OpenGL display thread, your ordinary animator.
This would require you to use 2 shared OpenGL context.
[2] The Texture maybe YUV based and the OpenGL display thread may convert
them on the fly using shaders.
Note: Our FFMPEGMediaPlayer implementation of GLMediaPlayer is currently
single threaded not using the above optimization w/ 2 threads [1].
The Android based GLMediaPlayer impl. utilizes multi threading.
Both use YUV shader conversion.
Again - this problem has really nothing todo w/ JOGL,
but more w/ media player architecture and implementation.
See the demos ..
~Sven
>
> Anand
URL: https://forum.jogamp.org/JOGL-video-rendering-tp4026062p4026092.html
On 09/11/2012 01:26 PM, anandcta123 [via jogamp] wrote:
>
> Dear sir,
>
> Why I asked this above question is. I have done timing tests for single video
> and multiple videos playback. The display function of each GLJPanel instance
> is not calling as per the frame rate. Too much delay is there between two
> consequent display function calls (If nothing is drawing inside display
> function) and this will be fine for one video and as number of video GLJPanel
> instanes increases, this is not maintaing frame rate as per single GLJPanel
> instance. So I need to solve this issue first, otherwise I can't use JOGl in
> my application (Because I am using MDI window with embedded JInternalFrame).
which operates w/ less overhead when it comes to rendering
due to GLJPanel / Swing offscreen compositor and AWT threading restrictions,
you can use GLJPanel ...
The issue you describe here looks more like an unclear threading
and multi-buffering implementation.
[1] I would implement a movie player having one thread producing
2 or more Textures in a sequence and sending notifications to
the OpenGL display thread, your ordinary animator.
This would require you to use 2 shared OpenGL context.
[2] The Texture maybe YUV based and the OpenGL display thread may convert
them on the fly using shaders.
Note: Our FFMPEGMediaPlayer implementation of GLMediaPlayer is currently
single threaded not using the above optimization w/ 2 threads [1].
The Android based GLMediaPlayer impl. utilizes multi threading.
Both use YUV shader conversion.
Again - this problem has really nothing todo w/ JOGL,
but more w/ media player architecture and implementation.
See the demos ..
~Sven
>
> Anand
signature.asc (907 bytes) | Free forum by Nabble | Edit this page |