Kyle Mallory wrote:
> 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.
The idea was to have each source in the timeline point to a source
definition, but not explicitly include a list of source definitions with
the intermediate format. Rather, let the file export module handle
extracting that. For the case of cPickle, it makes sense not to build it
at all. I'm not sure that this approach would have adverse consequences
for off-line editing.
>> * 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.
All the factories derive from one parent. The discoverer looks at the
uri and figures out how to create the appropriate factory. So, all we
really need to keep is the uri. We don't serialize the factory
completely, but currently each factory does "serialize" itself in the
sense that it implements "serializable" and builds a representation of
itself in the intermediate format when asked. It doesn't seem to be a
complete representation, but edward wrote that part of the code, so i
don't really know what his thoughts are on this.
>> * 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 sent out a second email with some corrections to this section, so I
apologize for that. It was supposed to look like:
....
volume: [...]
I.e. we're still dealing with an intermediate python data structure. One
of the keys of an effect/transition is called "parameters", which would
store all of the effect/transition specific keys/values.
In python, mappings (dictionaries) are fairly easy to work with. Most of
the intermediate format is composed of dictionaries.
I think the main difference in your approach is that you're mapping
keyframes to lists of parameters, whereas I was suggesting mapping
parameters to lists of keyframes. I think Edward can maybe comment here
on which is the better approach to take. I'm leaning towards the latter
because it is my understanding that we'll have separate "controller"
objects for each parameter we want to change over time, rather than one
controller that handles a monster list of parameters.
>> * 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.
That is precisely why validate should be added to the serializable
interface, it forces any "serializable" class to include a method for
validating data.
> 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?
>
I'm just suggesting doing some sanity checking on input to prevent
dangerous things from happening. So, yes, unusable data would be
ignored. At least minimally users would be warned, and where possible
given a choice about how to handle problems. This kind of scenario would
be ideal...
The project points to a file that doesn't exist. The user should be
given a choice as to whether they want to
1) leave the project unchanged (maybe temporarily insert a blank source
to allow editing)
2) replace he original source with a blank source,
3) cancel loading the file.
...but for now, I don't want to get too carried away with sanity
checking. Minimally, I just want to be able to do some semantic
validation and be able to gracefully fail when something goes wrong.
-------------------------------------------------------------------------
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
