#193 JPEG screenshot/movie


This patch add JPEG screenshot and movie capabilities.

- 'jpeg code' uses some function from 'png code', so the '#include <png.h>' moved to the include section
- we do not need the png_data array, because we can use rgb_data1 (so we do "rgb_data1 -> rgb_data2 ->rgb_data1" instead of "rgb_data1 -> rgb_data2 ->png_data")
- adds 'screenshot_jpeg_write()' to save screenshots

- adds some settings to controll jpeg compression

- new menu definitions for jpeg screenshot, movie and options

- new callback functions for jpeg screenshot, movie

- definition for jpeg movie menu entry

- definition of screenshot options

- adds code to do jpeg movie

- adds code to check jpeg library


  • Gergely Szasz

    Gergely Szasz - 2009-02-02

    jpeg screenshot/movie

  • Gergely Szasz

    Gergely Szasz - 2009-02-02

    This patch also adds code to 'widget':
    - some code to widgeting UI works

    and changes screenshot.c:
    - chaged rgb32_to_rgb24 in order to handle grayscale (if bw_tv) jpeg creation
    File Added: fuse.jpeg_03.diff

  • Fredrick Meunier

    In my opinion we would be better to have a reasonable interface to plug into normal multimedia APIs like Quicktime and platform equivalents rather than having the stand-in SCR/PNG etc. movie writers for subsequent conversion to a real movie file.

  • Gergely Szasz

    Gergely Szasz - 2009-02-02

    Taking an SCR screenshot is ineffably quicker than encoding a frame with Quicktime :)

    So i do not think we should drop SCR, or we should use Quicktime to catch a single JPEG screenshot (and PNG may out of the scope of Quicktime?), and the present 'movie' code is not so complicated, it just takes screenshots repetitively...

    Yes, it migth be better if we can take 'playable' movie at 'realtime', but than we need a big processing power... O.K. i know nowadays it is not a big problem on desktop, but with the 'SCR' code (or with the SCR like 'FMF' code patch #1721290) i can record 'pre'-movie with a 500MHz AMD-KII without notice any slowdown. To take 'PNG' movie on a 2.4GHz Celeron slow down fuse about 50% realtime. The 'FMF' movie capturing (with sound -> A-law conversion and screen data compression with Zlib) cause only ~40% CPU utilization. May an MP4 encoding slowdown fuse more then PNG shots...

    I think to have an interface to 'high' level multimedia APIs like Quicktime or even ffmpeg (libavcodec/libavformat) is badly needed, but i do not think we have to drop SCR/PNG code...


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks