#193 JPEG screenshot/movie

open
nobody
None
5
2013-01-01
2009-02-01
No

This patch add JPEG screenshot and movie capabilities.

changes:
screenshot.{c,h}:
- '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

settings.dat:
- adds some settings to controll jpeg compression

menu_data.dat:
- new menu definitions for jpeg screenshot, movie and options

menu.{c,h}:
- new callback functions for jpeg screenshot, movie

ui.c:
- definition for jpeg movie menu entry

ui/options.dat:
- definition of screenshot options

display.c:
- adds code to do jpeg movie

configure.in/Makefile.am:
- adds code to check jpeg library

Discussion

  • Gergely Szasz

    Gergely Szasz - 2009-02-02

    jpeg screenshot/movie

     
  • Gergely Szasz

    Gergely Szasz - 2009-02-02

    This patch also adds code to 'widget':
    ui/widget/menu.{c,h},menu.c
    - 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