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 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>
>>                   <mailto: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>
>>               <mailto: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
>>            <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
>>
>>
>>
>>
>> --
>> 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

Reply via email to