Hi all,
Some news on this topic, we've tested on Linux : same hardware (2
GTX285 and 4 screens), same video, same code, an ubuntu 9.04
configured with 4 screens, with VSync enabled we've got a solid
60fps... Without VSync it goes between 150 and 300fps.
So we've got our solution, we'll make our setup on Linux. Multi-
screen support in OpenGL is really crappy on Windows... :/
Cheers,
On Thu, Mar 25, 2010 at 2:44 PM, Serge Lages <[email protected]>
wrote:
Hi JP,
Thanks for your reply, we've tested to share the contexts but it
wasn't much better.
Cheers,
On Thu, Mar 25, 2010 at 9:24 AM, J.P. Delport <[email protected]>
wrote:
Hi Serge,
Serge Lages wrote:
Hi all,
Still having problems playing my big video. Here is our current
state :
- On a single screen setup (with only one GT 220 GeForce), with a
composite viewer and 4 windows (450x800 each window), it plays
smoothly at 60 fps with a fluid video, no problem here.
- On the destination setup : Intel QuadCore + 2 GeForce GTX 285 + 4
screens in 1360x768 (2 screens per cards), a composite viewer with
one view per screen, it plays between 10 and 20 fps... We've made
our tests on WinXP and Win7 with the same result.
The technique we're currently using is the one from Robert, having a
big osg::Image updated by ffmpeg, and having 4 images for the
textures pointing at the correct location on the large one. The
video's size is 768x6532.
Have you tried sharing the context for the two views per card? Also,
you are now uploading twice the data needed to each GPU, because
each one is only viewing half the data. I'm sorry I can't help
further currently, I would love to test on Linux, but don't have
time...
jp
You can find attached the current code, any idea on what can be
better ? Or any other idea on how to handle this problem ? And any
chance for someone to test on Linux ?
You can also find the test video here :
http://labs.tharsis-software.com/outv.mp4
Thanks !
On Thu, Mar 11, 2010 at 9:53 AM, Serge Lages <[email protected] <mailto:[email protected]
>> wrote:
Hi all,
Thanks for your advices. About the current setup, we're using only
one screen with a 9800GT card (and 4 windows) for our tests, but
the
final setup will be composed of 2 9800GT cards and 4 screens.
I'll let you know how our tests goes.
Cheers,
On Thu, Mar 11, 2010 at 8:28 AM, J.P. Delport <[email protected]
<mailto:[email protected]>> wrote:
Hi,
Serge Lages wrote:
Hi JP,
Thanks for your answer, and we don't need sound. By a "fast
disk", what do you recommend ?
We have a raid0 setup that can sustain 150MB/s.
Your ffmpeg reader is based on the current OSG plugin or is
it a custom one ?
It's a custom one, but not complicated. It basically pops the
output of ffmpeg decompress into an osg::Image, set's PBO on
that and lets OSG upload it. We are using only monochrome
images
though (GL_LUMINANCE).
About our file, with some codecs and adjustments on the
bitrate, we're able to play it with VLC without problems,
so
I think the reading part can be handled by the ffmpeg
plugin
with only one file, but then we need to dispatch this image
on 4 textures. We're currently trying to do some tests.
I'm still not sure where your problem area is. If it's not
decoding it can only be upload to GPU or final rendering. You
should be able to check this by varying the complexity of the
rendering.
jp
Cheers,
On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
wrote:
Hi Serge,
Serge Lages wrote:
Hi all,
We currently need to play a big video (approximately
5500*800)
on 4 screens within an OSG application (we use a
composite
viewer), so we've tried :
- Cut the video in 4 parts, but it seems really
hard to
synchronize the 4 streams.
- Decode directly the big file, resulting with a
very big
texture split on 4 quads (with appropriate texture
coords), but
even with a powerful computer, it's very slow.
Any idea on what's the best approach for this
problem
? We're
currently making our tests using the ffmpeg plugin,
but maybe
another plugin would be more appropriate ?
Thanks in advance for your help.
some ideas/questions. We do something similar - stitch
four high-res
camera videos into large texture. We have custom ffmpeg
reader that
just reads from 4 video files and we step them manually
(and in
sync) one frame at a time. We use raw video (no
compression) to
avoid cpu decompress, but now one needs fast disks. We
don't have
sound, do you need sound? For large sizes one needs to
avoid copying
around data in cpu mem as much as possible. There is
still one copy
in ffmpeg raw read that I need to get rid of.
rgds
jp
Cheers,
-- Serge Lages
http://www.tharsis-software.com
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-- This message is subject to the CSIR's copyright
terms and
conditions, e-mail legal notice, and implemented Open
Document
Format (ODF) standard. The full disclaimer details can
be
found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous
content by
MailScanner, and is believed to be clean. MailScanner
thanks
Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-- Serge Lages
http://www.tharsis-software.com
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-- This message is subject to the CSIR's copyright
terms and
conditions, e-mail legal notice, and implemented Open Document
Format (ODF) standard. The full disclaimer details can be found
at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content
by MailScanner, and is believed to be clean. MailScanner
thanks
Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-- Serge Lages
http://www.tharsis-software.com
--
Serge Lages
http://www.tharsis-software.com
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and
conditions, e-mail legal notice, and implemented Open Document
Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html
.
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean. MailScanner thanks
Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
--
Serge Lages
http://www.tharsis-software.com
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
