In the previous code, the threads were created and destroyed in the base
class constructor and destructor, so the threads could potentially be
active while the object is in a partially constructed or destroyed state.
The thread however, relies on a virtual function to process the queue
items, and the vtable might not be in the desired state when the object
is partially constructed or destroyed.
This probably only matters during object destruction - no items are in
the queue during object construction so the virtual function won't be
called, but items may still be queued up when the destructor is called,
so the virtual function can be called. It wasn't an issue because all
uses of the thread explicitly waited for the queues to be empty before
invoking the destructor.
Adjust the constructor to take a std::function parameter, which the
thread will use instead to process queue items, and avoid inheriting
from the GSJobQueue class. This will also eliminate the need to
explicitly wait for all jobs to finish (unless there are other external
factors, of course), which would probably make future code safer.
Valid values for png_compression_level are from 0 (no compression) to 9
(max compression). The default is 1.
v2: Use zlib Z_BEST_SPEED (1) and Z_BEST_COMPRESSION (9) defines.
This is the internal resolution which GSdx uses and recording at this resolution
is optimal, i.e. without any dumb scaling, with all relevant pixels and without
redundant pixels.
The resulting clip still doesn't have the correct aspect ratio set, but that's
just a property which can be set to the clip afterwards, which is where the DAR
becomes useful. Since it's usually anamorphic, when muxing later with the audio
use the DAR to set the playback aspect ratio.
The idea was to merge them later with ffmpeg or other external tool
It kinds of work but current fps is around 2 !!! So not really usable
The speed issue is related to PNG.
So either the code to store pixels data must be optimized. Or maybe it misses some MT loves :)
- Use float instead of int for the video framerate.
- Use 59.94 instead of 60 for the ntsc framerate.
This replaces a previous hackfix with a better one, but it's still not ideal.
The ideal solution for the video encoding side would be to use an actual fraction (60000/1001) and pass this fraction to the encoder.
The ideal solution for the gsdx side would be to deduce the real framerate from the timing parameters.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4925 96395faa-99c1-11dd-bbfe-3dabce05a288
Also added Valkyria Profile 2 Italy to the gamedb and GSdx crc list. By Leucos.
Thanks guys :)
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4618 96395faa-99c1-11dd-bbfe-3dabce05a288
- GSWnd is not implemented, no config dialogs either
- no output, just the null device
- threading classes were not tested (my first experience with pthread)
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4315 96395faa-99c1-11dd-bbfe-3dabce05a288
It was a series of very old bug.
1) After the passage to the WX system the CoInitialize was not anymore called on the GS thread causing the Filter enumeration on DirectShow to fail.
2) After the "MFC Free" commit of Gabest, if you selected the Uncompressed functionality a nullpointer exception trigger (as there is no filter for that)
3) Strangely there was no code path to connect the source with the mux when Uncompressed was selected (without an encoder in the middle). I added it.
Test it and report problem. I already know there is a problem with the closing of the sound recording, but that's a PCSX2 problem, not a GSDX one.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@2657 96395faa-99c1-11dd-bbfe-3dabce05a288
Added interface.cpp (plugin/pcsx2 interface) and savestate.cpp to SPU2ghz, to help clean up SPU2.cpp.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@463 96395faa-99c1-11dd-bbfe-3dabce05a288
Jonathan Li