(08-29-2009 09:33 AM)mudlord Wrote: Nach, any thoughts?
Yes, several actually.
I believe a method along these lines is the best way to encode.
1) It eliminates any platform specific video encoding libraries.
2) It eliminates needing to write any code to interface with those libraries which can get messy quickly.
3) It's easy to make cross platform.
4) It allows a user to easily set his own encoding options, and save them as a preset.
5) Programs can be swapped at any time to use whichever works best (MEncoder, FFMPEG, or anything else).
6) We get free support of any of the newest encoding methods without any reprogramming done on our part.
7) The code is rather easy, and the programmer doesn't need to learn any API beyond standard C if done correctly.
However, I don't necessarily agree with using a named piped (FIFO file). How to create a named pipe changes per OS, and some OSs have whacked out restrictions on named pipes like only on particular file systems or other nonsense.
Most of these command line operated encoding programs don't just works with files, but would accept input via stdin. So I prefer launching them via popen() which is standard C, and writing to them in a normal method, which gives maximum portability.
That's what I did in ZSNES. However I wrote specialized versions of popen() for Windows and Linux which returns a null pointer if it could not launch the executable.
The method should be user configurable to specify which program to use, how many passes to run, which commands to pass the program for each pass, and commands at the end to clean up the binary (such as running mkvmerge, or hexedit into an AVI new timecodes).
ZSNES begin of dump code: https://zsnes.bountysource.com/svn/!sour...vie.c#1984
Begin Dump: https://zsnes.bountysource.com/svn/!sour...vie.c#2263
Write Frame: https://zsnes.bountysource.com/svn/!sour...ovie.c#236
Finish Dump: https://zsnes.bountysource.com/svn/!sour...vie.c#2203
Embed logo in video prior to dumping the video (see http://tasvideos.org
for use of this) https://zsnes.bountysource.com/svn/!sour...vie.c#2173
Modified popen() for Windows: https://zsnes.bountysource.com/svn/!sour.../safelib.c
Modified popen() for Linux (and other UNIXs): https://zsnes.bountysource.com/svn/!sour...elib.c#262
Creating user config file from developer's end: https://zsnes.bountysource.com/svn/!sour...src/md.psr
What user sees when editing config file: http://nach.pastebin.com/m3b752734
Custom config for FLV: http://ia340931.us.archive.org/0/items/Z...zmovie.cfg
Some guy who tweaked his own settings: http://www.mortenblog.net/2009/02/23/rec...-mencoder/
Since I want to include encoding like this in other projects, I was thinking of making a completely emulator independent C++ class which handled dumping like this, with support for user settings, begin dump, write frames, finish up dump.
(08-29-2009 06:45 PM)spacy51 Wrote: Hm, I am not sure wether I should record at 60 Hz or at 59.737 Hz. GBATEK states that 59.737 Hz is the time needed to refresh every display line once. Does VBA-M emulate it that way? How long is one frame of audio?
You should write it at whatever speed VBA-M goes at. In the case of audio, if need be, resample it as I do in ZSNES.