about bpp and performance

  • Sinan Nalkaya

    Sinan Nalkaya - 2005-12-26

    hello, i want to capture my screen and multicast it to network , anyway my desktop movie records play very very fast, i read the all faq documentation and applied tweaks, i tried with celeron (2 ghz) and c3 (1ghz) cpus. i think both cpus should be enough for program ?
    also i am noticed that my video files records with 24 bpp depth, even i drop my depth to 16,8 (in xorg.conf or XF86Config-4) but does not make any sense. My question is,if i manually change the xwd functions in source which returns the default depth variable ,do my recorded movies play normally? thanks

    • Karl H. Beckers

      Karl H. Beckers - 2005-12-27

      cannot comment on whether celerons should be sufficient ... the demo videos were done on an Athlon 1800+ ... however, I've noticed xcompmgr seems to kill performance even on my P4 3GHz with Xorg 6.9 and radeon driver, exa and all. Need to investigate here.

      xvidcap should definetely not ignore your setting in xorg.conf. How did you test your videos were captured with the wrong depth? Do colours look OK and the video is just slow? Or is the image also broken?


    • Sinan Nalkaya

      Sinan Nalkaya - 2005-12-28

      hi again,
      i tried first xfree86 4.3.0 (or 4.4 not sure)(debian sarge - celeron 2.0) and xorg 6.8.2 with special via openchrome drivers. i lowered my depth from XF86Config-4 and xorg.conf as i said, when playing the mpeg file, colors are seems ok but i am noticed that the mpeg file is 24bpp, then i tought maybe there is something wrong when feeding libavcodec functions from xwd source ? and when doing this depth converting proccess, it consumes high cpu - usage

      • Karl H. Beckers

        Karl H. Beckers - 2005-12-28

        don't think you're looking at the right data to judge what is being captured. If you're talking about what mplayer shows when it replays the video then that's certainly not what you got when you were capturing. To encode to video at some stage you need to convert to yuv 420 format at some stage anyway (you only get some extra conversion if you're using 8bit palette or 32bit depth on a big endian machine).
        All in all, if your video displays correctly (except for timing) then xvidcap does the right thing as far as colour depth is concerned. Otherwise the picture would look messed up (or actually I doubt xvidcap would run ... would be seeing segmentation faults all over).
        If you want to make absolutely sure, you should  add a line to config.h like "#define XVD_DEBUG 1" (without the double quotes) and recompile. This will make things REALLY slow and dump every captured frame to a file /tmp/pic.rgb.pnm, every converted frame to /tmp/pic.yuv and also output information about the captured image to stderr. You should see a line "depth: xxx" there.

        That aside, I think it boils down to the usual performance problems due to the lack of hw acceleration.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks