Re: [osg-users] Playing smoothly a big video
Hi Bruce, We've tested the same code I posted (the Main.cpp) without modifications. About the cards, we're using 2 NVidia GTX 285, with the latest drivers from the NVidia website. Cheers, On Sat, Apr 10, 2010 at 10:34 PM, Bruce Wheaton br...@spearmorgan.comwrote: Thanks for reporting back Serge - glad that's working for you. Sorry I didn't have time to test on my Linux rig. Was the technique the same as your Main.cpp example, as posted, or did you have to do any extra tricks? Also, what graphics cards and drivers are you using? That makes a big difference in Linux. Regards, Bruce Wheaton On Mar 29, 2010, at 5:17 AM, Serge Lages wrote: 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 serge.la...@gmail.comwrote: 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 jpdelp...@csir.co.zawrote: 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 serge.la...@gmail.commailto: 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 mailto: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 mailto: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
Re: [osg-users] Playing smoothly a big video
Thanks for reporting back Serge - glad that's working for you. Sorry I didn't have time to test on my Linux rig. Was the technique the same as your Main.cpp example, as posted, or did you have to do any extra tricks? Also, what graphics cards and drivers are you using? That makes a big difference in Linux. Regards, Bruce Wheaton On Mar 29, 2010, at 5:17 AM, Serge Lages wrote: 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 serge.la...@gmail.com 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 jpdelp...@csir.co.za 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 serge.la...@gmail.com mailto: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 mailto: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 mailto: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
Re: [osg-users] Playing smoothly a big video
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 serge.la...@gmail.com 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 jpdelp...@csir.co.zawrote: 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 serge.la...@gmail.commailto: 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 mailto: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 mailto: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
Re: [osg-users] Playing smoothly a big video
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 serge.la...@gmail.com mailto: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 mailto: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 mailto: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
Re: [osg-users] Playing smoothly a big video
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 jpdelp...@csir.co.za 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 serge.la...@gmail.commailto: 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 mailto: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 mailto: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
Re: [osg-users] Playing smoothly a big video
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.zawrote: 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.zamailto: 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
Re: [osg-users] Playing smoothly a big video
Serges, I do something similar - at least with the multiple GPUs, and multiple videos. I have a machine here with very similar spec running Linux, I could maybe try your code tomorrow. On a side note, we had problems with frame rate fluctuations on our previous (heavily threaded) pipeline design when sending to multiple GPUs, and that's why I'm looking at OSG. I'm about to try to change over. Fairly early on the list will be removing/making optional the CPU colorspace conversion that is probably slowing you up a bit too. Assuming your videos are MP4, like that sample, and probably 4:2:0, that could also have the effect of halving your texture transfers. Regards, Bruce Wheaton PS - our fluctuations were 2-8 frames, occasionally, not what you're describing. On Mar 23, 2010, at 10:51 AM, 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. 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
Re: [osg-users] Playing smoothly a big video
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.zamailto: 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
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 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
Re: [osg-users] Playing smoothly a big video
Hi JP, Thanks for your answer, and we don't need sound. By a fast disk, what do you recommend ? Your ffmpeg reader is based on the current OSG plugin or is it a custom one ? 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. Cheers, On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport 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 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi Serge, On Wed, Mar 10, 2010 at 4:11 PM, Serge Lages serge.la...@gmail.com wrote: 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. Why do you need four textures? Modern graphics cards can handle pretty large texture sizes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi Robert, We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. On Wed, Mar 10, 2010 at 5:17 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Serge, On Wed, Mar 10, 2010 at 4:11 PM, Serge Lages serge.la...@gmail.comwrote: 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. Why do you need four textures? Modern graphics cards can handle pretty large texture sizes. Robert. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.com wrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Thanks for your advices Robert, anyone had some success on configuring and sharing graphic contexts on Windows 7 ? We'll also try the 4 images based on one big image and let you know how it goes. Cheers, On Wed, Mar 10, 2010 at 5:43 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.comwrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Serge, One other item that hasn't been explicitly mentioned yet is pixel packing. You want to make sure that the graphics card does as little with the source image as possible to get it into the OpenGL pipeline. Make sure that your on-disk pixel format is something that is on the fast path. Storing data as 24-bit RGB is not a good choice as it is not aligned. BGRA is your best bet as it is about the fastest pixel format on nvidia hardware. Chuck On Mar 10, 2010, at 8:43 AM, Robert Osfield wrote: Hi Serge, On Wed, Mar 10, 2010 at 4:29 PM, Serge Lages serge.la...@gmail.com wrote: We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Do you need 4 contexts? If you have one card I would typically try to run it with a single context across all outputs. With two graphics cards you wouldn't be able to do this, but still I'd opt for two graphics contexts, one per card. This does assume that your OS of choice actually supports driving the graphics cards efficiently... Perhaps one solution you could go for is to have four textures that each have their own osg::Image, but each osg::Image points to a different point in the larger osg::Image. If you place render the video as four images down, one wide, rather than four wide and one down then you'd be able to use a simple pointer offset into the osg::Image that ffmpeg is writing to. Using this approach you could avoid major cache misses, and avoid the need for sharing a single big texture. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
Serge Lages wrote: Hi Robert, We've tried with only one texture and the fps drops to 15 approximately with a modern computer (GeForce card). Maybe the problems comes from having one texture shared on 4 contexts and only one card, on the final setup we'll have 2 graphic cards. Four screens with one card? Does that mean you're using a Quadro NVS? If so, those cards aren't really designed to push a lot of pixels, and the 15fps rate wouldn't really surprise me. I'm guessing that when you switch to 2 cards (assuming they're decent 3D cards), you'll have better results, even with the multiple contexts and one large texture. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Playing smoothly a big video
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
