On Thu, 2007-09-27 at 17:52 -0700, Brandon Lewis wrote:
> I've been editing the wiki section on the intermediate data format. I
> have a few questions:
>
> http://www.pitivi.org/wiki/Design_Docs_File_Load_and_Save#The_intermediate_data_structure
>
> * does it make sense to explicitly represent the sources list in the
> intermediate format? Every timeline source contains a reference to a
> unique source factory. Pickling handles flattening this data for us, and
> so could any future file format. i.o.w. having an explicit list of
> sources in the intermediate format is redundant.
If I understand you correctly (entirely possible that I don't), IMO, it
would make sense to have the timeline-source reference a project-source.
Basically every source that is added to the project is resident in the
media bin, which may not always be on the timeline. When an source is
added from the media bin to the timeline, the timeline-source should
reference the media bin source. In this way, you can easily handle
off-line editing by using low-res proxy files for editing, but when
you're ready to export the final cut, you can replace all of the media
sources with the high-res/online footage, and export, and the
timeline-sources update automatically.
> * Does it make sense to serialize object factories? Perhaps we should
> abstract the notion of a factory to a "source definition", that would be
> simpler, and more general. We can just store the URI of the source, and
> maybe whether it's audio, video, image, effect, etc, (do we really even
> need that?) and let the discoverer worry about what kind of object
> factory to create. That simplifies the code in objectfactory.py, the
> base class, objectFactory, is the only one that needs to directly
> implement Serializable.
I think it makes sense to not export the factory, because it is
redundant. Likewise, exporting the factory as part of the project could
make it troublesome if a new/improved factory was written in a later
revision, but which is ignored because of the version stored in the
intermediate. The only problem would be media that isn't detected, and
then having to specify what type of media it is each time the project is
opened, unless as part of the definition included which factory was
ultimately used to read the media, especially if it is user assigned.
As part of the "definition", make sure to include all of the data that
the factory would otherwise detect, such as frame/sample rate, bit
depths, alpha channels, aspect ratios, etc. It's very annoying having a
media format claim the aspect ratio is one thing, when it should be
something else, and having it change back again each time the project is
opened.
To me, it makes sense that different base types would have different
factories, which are handled independently. Ie, if an "effects" section
is found, then those entries are sent to the EffectFactory. Sources to
the SourceFactory, etc., as opposed to a single factory that tries to
handle everything.
> * how to handle parameters to plugins and transitions in a general way?
> I was thinking along the lines of combinations of general data types: we
> can allow any number of keys that can be one of int, real, color, and
> str. The only thing i'm not so sure about is how to handle a
> controller-type parameter where it defines how data chagnes over time.
> Maybe we can also define an "interpolation" data type that contains a
> list of keyframes(timestamps) and options which define how to
> interpolate between them. For example
>
> volume = [("linear", (0.00, 1.00), (1000, 5.0),)])
>
> Would define a linear increase in volume, starting at 1 when time T=0
> and increasing to 5 at time t=1000. You could also have interpolation
> modes of "square", and "bezier"
I got a number of thoughts on this, but I'm no python export. This is a
classic case for each class having its own serializer/factory, but I
understand your interest in having a generic system. In order to
accomplish you, you would need something like a map/dictionary, where
the key is your parameter name, but the value can be any primitive type,
as well as lists or maps of any of the same types (primitives, lists,
maps).
I wrote a similar beast in Java at a previous job. Very ugly, but very
generic, and *very* flexible. Basically, you could reference any
parameter using dot-notation: get("volume.type") = "linear" or
get("volume.keyframe[1000]") = 5.0.
In the case of keyframes, you'll probably have better luck storing them
as a map, with the keyframe as the key, and any parameters at that
keyframe as a sub map. For example:
primaryCC.description = "Primary Color Correction"
primaryCC.keyframe[1000].fromType = HOLD
primaryCC.keyframe[1000].toType = LINEAR;
primaryCC.keyframe[1000].shadow.angle = 265.0
primaryCC.keyframe[1000].shadow.intensity = 0.750
primaryCC.keyframe[1000].midtone.angle = 35.0
primaryCC.keyframe[1000].midtone.intensity = 0.130
primaryCC.keyframe[1000].highlight.angle = 315
primaryCC.keyframe[1000].highlight.intensity = 0.053
primaryCC.keyframe[1000].gamma = 1.875
primaryCC.keyframe[1000].saturation = 1.875
primaryCC.keyframe[1000].gain = 1.000
> * perhaps we should add a "validate" method to the serializable
> interface which does some sanity checking on the input data.
Definitely, but this should be done by the individual concrete classes.
I don't want you're project validator telling me my colorCorrection
values are invalid before I get around to seeing them for myself.
The only question is, how do validation errors get remedied, since
loading is a non-user-interactive state. Does each plugin try to coerce
bad data, ignore it, or can it complain to the user, to the application,
etc?
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pitivi-pitivi mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Pitivi-pitivi mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
