On Fri, May 13, 2011 at 7:31 PM, Brian Matherly <[email protected]> wrote: >>> 1) Is there any way to apply the meta.attr.* properties to the playlist, or >> the entire timeline? The only way I can make it work is to add the meta >> properties to every producer. If someone wants the timecode to apply to the >> entire output, it is a bit cumbersome to apply the properties to each >> producer. >>> >> >> If you are using melt, see the -group option. Another way is to >> include a xml playlist file as a clip within another composition where >> the attributes are added. Otherwise, a tool that uses mlt can apply >> the properties automatically according to its rules taking away the >> tedium. >> >>> 2) Can you show an example of how to use the data_feed filter? I can't >> seem to get it to do anything. >> >> The data_feed is applied automatically to producers. See >> core/loader.ini as used by the loader producer, which is the default >> "super" producer. Likely there are ways to use data_feed more >> manually, but I do not know it so well. Just do not assume all >> services have a visible or audible effect. They can also coordinate >> things (loader) or do things with data/properties. >> >>> 3) It appears that MLT has properties for the file name - which I think >> would be useful as an overlay. How would I go about overlaying the file name >> for >> all files in the track? >>> >> >> Currently, the data_show only does things with meta.attr. properties >> and special keywords 'timecode' and 'frame'. Of course, some >> tool/script could process a composition or mlt object model and copy >> the filename to a meta.attr. >> >>> 4) Ultimately, I want to overlay the file creation date. That information >> is not currently a property that is available within MLT. The application (or >> user) would have to add the creation date to the producer for each file. This >> isn't too difficult for an application, but it is cumbersome to do by hand. >> Do you have any interest in having MLT get the file creation date and make it >> available within the framework? Or is that a task best left to the >> application? >>> >> >> That is something that could be added to a producer (avformat would >> cover most cases except still images), or it can be the responsibility >> of a tool. I dunno. The avformat and image producers are already very >> complicated, and I hesitate to give them more duties. A thing to keep >> in mind is that this list could grow, and one needs to also think >> about date strings formats. Mlt does not have a native date type to >> which it can convert to and from string. Another thought is one could >> learn to author comps in Python or other scripting language with mlt >> binding where you can use functions to lookup things and pass their >> result to an mlt object. In a bash-like shell you can embed a >> command's output into melt options with $(). It does seem like you may >> want move up to scripted generation of mlt xml and/or melt command >> lines. > > Thanks Dan. This is very helpful. I think I'm finally starting to understand > the philosophy. > > I had been looking at the XML output of Openshot as an example, and the file > is relatively bare. So I expected that the data_feed filter somehow added a > bunch of meta.attr properties automatically. But then I looked at the XML > output of Kdenlive, and I see that it adds a whole bunch of meta.attr > properties. So, I deduce that the generation of meta.attr properties is the > responsibility of the application (Kdenlive or Openshot) and not the > responsibility of MLT. With that in mind, it would be trivial to modify the > application to add two new properties to each producer: > meta.attr.filename.markup and meta.attr.filedate.markup. I think that is > fairly straightforward. Maybe I'll start looking into what it would take to > add that to Kdenlive or Openshot. >
Kdenlive uses the Mlt API and serializes XML through the xml consumer, which is why its output is verbose. OpenShot maintains its own model and generates XML. > There is still one thing I don't quite understand. In the example on the FAQ, > it shows timecode as an example: > melt foo.mp4 meta.attr.titles=1 meta.attr.titles.markup=#timecode# -attach > data_show dynamic=1 > > In this example, meta.attr.titles and meta.attr.titles.markup are properties > of the producer. This is counter intuitive to me. I would have expected them > to be properties of the filter - something like this: > melt foo.mp4 -attach data_show dynamic=1 meta.attr.titles=1 > meta.attr.titles.markup=#timecode# > Yes, I agree. All I can say is that is the way it was contributed that way in 2007, and I was too rusty to suggest a different way. > As a filter, I would expect data_show to have properties to modify the > filter's specific > properties for appearance, content and location. data_show gets its properties from a template in the form of a properties file, and it has a default one if you do not specify. Their entire purpose and design is to apply data to templates of Mlt services. If you don't like that then generate your own graphical overlay some other way and composite it. No one is saying this is your only option. > But I have to specify the content as a producer property. What if I want to > chain two > data_show filters together to produce a more complex overlay? I can't specify > different > content for the two filters. Enhance the template you are using, or make one template that reads certain metadata attributes and another that reads other metadata attributes. > Am I missing something? Look. I am busy. I did not write everything here from scratch. Do your own analysis and deduction. -- +-DRD-+ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
