#193 JPEG screenshot/movie

open
nobody
None
5
2013-01-01
2009-02-01
Gergely Szasz
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

     
    Attachments
  • 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

     
  • 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...