Would something like this work: Notes: · location is always a position in the video · render calls buffer for image which gets it from itself and gets required items from decoder · render creates image in the background the when ready swaps them to the visual surface · render holds a list of tools to do changes to the image · classes can be overloaded (so different decoders or renders can be used) public class Decoder { // Construction, loading public Decoder(); public result LoadVideo(stream/location); // Loads video from stream or given location public properties GetProperties(); // Returns a structure with video properties public int SetProperty(name, value); // Set a property // Extraction public frame[] GetFrames(start, [optional] end); // Returns frames in the range public frame[] GetThumbs([optional] number = 1, [optional] start offset); // Returns thumb frames public int FillBuffer(buffer, start, end); // Checks buffer and passes required frames to the buffer PutFrame (one at a time to put frame as async method as they are decoded, not a group like getframes) } public class Buffer { // Construction, loading public Buffer(); public LoadDecoder(decoder); // Passes a decoder to use public SetSize(ahead, [optional] behind = ahead); // Sets buffer size before and after location public result GetSize(); // Updating public int UpdateBuffer([optional] current location); // Checks buffer and fills up as required using the decoder (returns if update was performed) public bool UpToDate(); // Passes true if buffer is full and to the right location public result GetStatus(); // Passes number of empty frames ahead and behind public SetLocation(location); // Sets location in the video without update public result GetLocation(); public Clear(); // Empties the buffer // Extraction public frame GetFrame(location, [optional] update buffer = 1); // Gets the frame and moves buffer (will also need to get from decoder if missing) public int PutFrame(location); // Lets decoder place a frame into the buffer at location } public class Render { // Construction public Render(); public LoadBuffer(); // Passes a buffer to use public SetSurface(hwnd); // To screen public bool SwapFrame(); // Places rendred frame onto surface (back buffer to screen). Checks frame is ready to be drawn and returns true on sucess // Load next frame public bool Render(location); // Gets image from buffer and starts drawing onto it (done in background memory then when is finished SwapFrame can move it to the visable surface // Tools public id AddTool(tool); // Adds a tool to render onto the frame (like drawing, filter etc) public RemoveTool(id); // Removes a tool ... } From: kinovea-dev-bounce@xxxxxxxxxxxxx [mailto:kinovea-dev-bounce@xxxxxxxxxxxxx] On Behalf Of Joan Sent: Thursday, 18 August 2011 2:08 AM To: kinovea-dev@xxxxxxxxxxxxx Subject: [kinovea-dev] Re: C# 3.0 in Kinovea sources Thinking about it again, this is probably the wrong level of abstraction. The player screen should not have to know all this stuff about buffering, etc. It just wants a frame to render. There is also a need to support more file formats than what FFMpeg can offer, specifically a reader for animated GIFs and a reader for a sequence of individual images. The abstraction thus needs to be a level higher. All file readers must implement common services that other parts will use. (getting thumbnails, moving to next frame, moving to a given spot, etc.) The fact that the FFMpeg-backed reader will use a buffer is probably an implementation detail of this particular reader. The animated GIF reader may on the other hand load the entire content in memory righ away. So, before diving into asynchronous decode, the abstraction layer for file readers must be in place with a clean interface. Ideally the extra readers would be loaded dynamically in a plug-in fashion. I'll probably start a branch for this because it will break everything ! Le 16/08/2011 15:05, Joan a écrit : Regarding threading: Trying to organize thoughts I wrote a small page on the wiki with tentative system. http://www.kinovea.org/wiki/doku.php/codeasyncdecode It is a bit more complicated than what I wrote in the last mail because it also account for dropping in the decoding thread. If you have some time please review it and tear it appart :-) Especially scenario 2 which has some blurry zone. When the decoding is not ready at the right time, should we present the frame later on if we don't have anything more recent, or drop it anyway ? Thanks