On Thu, Dec 19, 2013 at 5:33 PM, Brian Matherly <pez4br...@yahoo.com> wrote: >> 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). >
OK, first of all, I am not trying to co-design this with you in detail. I just threw out ideas that I had thought about in the past. Now, with that said, I agree properties are cleaner than query string parameters. You just need to keep in mind that properties are not available/set at init time, and producers need to be able to fail on init to indicate they cannot handle the resource/argument given. So, if you need some parameters at init time, we really only have URL parts: scheme, query, and fragment. If you do not need the parameters at init time, then use properties including prefixed properties that target encapsulated services. In the context of some smart producer, you might want something on the URL to indicate whether to do something extraordinary before choosing to do something new and fancy versus following an existing tried and proven path of logic. If a smart, super producer that no longer resembles the old behavior of loader for the simple cases is to become the new default for MLT_PRODUCER, then it needs to be really solid, which means it may be sitting in some incubating stage for a while to become trusted for the new default. I hope that was clear; it was a bit difficult to explain. :-) >> 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 > -- +-DRD-+ ------------------------------------------------------------------------------ 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
