#193 JPEG screenshot/movie
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
jpeg screenshot/movie
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.
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...