[kinovea-dev] Re: C# 3.0 in Kinovea sources
- From: Hugh <greatview@xxxxxxxxx>
- To: <kinovea-dev@xxxxxxxxxxxxx>
- Date: Fri, 19 Aug 2011 15:59:43 +1000
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
Other related posts:
