> I would keep it out of the framework and simpler to start. When I had > done some thinking on this in the past, I was thinking about merging > some of the logic of the framebuffer producer into the loader > producer, trying to generalize it, and adding support for audio. Then, > it could can use hints placed on the frame by something like telecide > filter where it indicates a repeated frame. (It will only work when > using filters attached to the encapsulated producer and not when > planted in the multitrack field.) You might need a way to tell this > producer to attach additional filters to the encapsulated producer, > maybe through the query string on the argument/resource URL. Or, > instead of attached filters, it uses your producer chaining idea. > Currently, a producer can be specified through a scheme prefixed to > the URL. Maybe for each additional scheme at the front it creates an > encapsulated producer recursively. > > In case you do not know, almost all producers are produced via the > loader producer, which is actually like a factory and does not > actually return its own object. It is used by the framework because > mlt_environment(MLT_PRODUCER) defaults to "loader". Make a copy of the > loader producer, say loader2, and try to do your work in there. You > can tell MLT to use by setting env var MLT_PRODUCER=loader2 until we > find it to be a suitable replacement.
Ok. I'm on board with focusing on the loader rather than creating a new service type. I'll do some research on the loader. I can imagine a set of built-in (not pluggable) producer encapsulators that get created automatically by the loader based on the required normalization and maybe affected by some hints from the user. > Let's take a step back here. Reflect for a short moment about what > loader producer does and what framebuffer producer does and how it > works. As an app developer, I would like to be able to change the > speed and direction of a clip by not having to put "framebuffer:" in > front of it. As a users, I would like to be able to change the speed > and direction of a clip by simply adding query string speed parameter > to the URL. However, producers like avformat also process query string > parameters. Therefore, we will namespace prefix ours with mlt_ and > call it mlt_speed. I can picture all of that quite easily by simply > merging framebuffer into loader. > > How about a way to generalize that? What if mlt_filter=yadif2x > attaches the yadif2x filter to the child producer? How about > mlt_filter=telecide&mlt_guide=1 to attach telecide and set its guide > property to 1? Use "mlt_" to filter query string params. "mlt_filter" > is keyword to attach filter; anything else sets a property on most > recent filter, and order is important. Can mlt_speed be handled as a > filter or is that special because there needs to be framerate > normalization in the loader2 producer? I can tolerate the query string idea. But query strings are not as friendly as good old fashioned properties. I think the cut producer is a great model that we can extend. Just like "in" and "out" are reserved properties that apply to all producers - and are applied appropriately by the loader, why can't "speed", "deinterlace" "telecine" also be reserved properties that are applied to all producers by the loader. Here is a new proposal: In "core", create the following producers: cut, speed, deinterlace, telecine. These producers all take another producer as an argument. The loader can interpret the producer properties, intercept the "in", "out", "deinerlace", "speed" and "telecine" properties and then nest the producers as appropriate before returning the final producer (which may just be the original, or may be multiple nested producers). > Later, what can be done about audio? Forget about what to do on speed > changes, but for things like reverse telecine and bob deinterlacing, > it sucks that audio cannot be retained. It should be possible to divide the audio up among the new frames. In the case of bob deinterlacing, you would take the samples from the original frame and divide them evenly among the two new frames because they have double the frame rate. For speed, one could resamble the audio to speed it up and slow it down. ~Brian ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
