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. 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 <serge.la...@gmail.com> 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 <jpdelp...@csir.co.za>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 <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 >> > > > > -- > Serge Lages > http://www.tharsis-software.com > -- Serge Lages http://www.tharsis-software.com
Main.cpp
Description: Binary data
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
