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 <jpdelp...@csir.co.za
<mailto:jpdelp...@csir.co.za>> 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
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
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
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
