Thanks. I'll continue to research the swig listener approach. One last question for you. Would it make sense for the consumer to have a simple .position() method, instead of requiring a listener and callback? Not sure if that makes sense, but just a thought. -Jonathan
On Sun, Feb 21, 2010 at 6:54 PM, Dan Dennedy <[email protected]> wrote: > On Sun, Feb 21, 2010 at 4:35 PM, Jonathan Thomas > <[email protected]> wrote: >> Thanks Dan! I took some time to play around with an event listener >> for the consumer "consumer-frame-show" event. However, I am not sure >> how to register an event listener with MLT. So, for example, if I had >> the following python method: >> >> def on_consumer_frame_show(*args): >> frame = args[0] >> consumer_position = frame.get("_position") >> >> How would I connect this method to the consumer, so it knows about my > > Properties.listen() > >> listener. I took a look at the mlt.i file, but it wasn't clear to me >> how it was working. > > It requires learning swig. Most of it just defines the classes we want > to wrap and which methods return references that need garbage > collecting. The bottom part for Ruby is to create a Listener object > bound to a Ruby function that you can pass to the Properties.listen > method. > >> Also, I experimented with using the get_frame() >> method on the consumer, and then getting the "_position" from it. >> However, that seemed to give the same position as the producer. > > That function is mainly for internal usage, but it is possible for an > app to use it when it does not start/stop the consumer. > >> Thanks as usual, >> -Jonathan >> >> >> On Sun, Feb 21, 2010 at 4:25 PM, Dan Dennedy <[email protected]> wrote: >>> On Sat, Feb 20, 2010 at 11:37 PM, Jonathan Thomas >>> <[email protected]> wrote: >>>> Dan, >>>> I have removed the 2 unneeded lines (rescale & distort), and replaced >>>> the "sdl" consumer with the "sdl_preview" consumer. I have also added >>>> all of the "refresh" hooks. >>>> >>>> The only issue I have found is a flicker when going from a speed of 0 >>>> to a speed of 1 on the producer. So, when you click Play / Pause, it >>>> flashes black. I also noticed that the "sdl" consumer seems a bit >>>> delayed, from the position() that the producer reports. In fact, I >>>> think the "sdl" consumer was also a bit delayed, but it did not flash >>>> black when pausing. >>> >>> Yes, these are the quirks I mentioned in chat. Part of the flashing is >>> due to switching from updating a X drawable in RGB to writing YUV into >>> a XVideo port. Part of this problem is due to using a scaled RGB >>> gamut. A straight YUV-RGB conversion will not use the full range of >>> RGB values, which can be undesirable for processing in RGB. Therefore, >>> MLT does scaled conversion to and from RGB. This also simplifies >>> integrating still photos and computer generated imagery, which use >>> full range RGB. >>> >>> Some of the flickering might also be due to the postion related issue... >>> >>>> I'm not sure if there is anything we can do to solve these issues, but >>>> any thoughts would be appreciated. >>> >>> The position reported by the producer is correct, but you are watching >>> the consumer, not the producer. You see there is a "render ahead" >>> buffer that absorbs the impact that frames that might take longer than >>> real time to produce and implement the frame-dropping for real time >>> (normal speed) playback. So, the position on the producer is ahead of >>> the consumer. The consumer fires a consumer-frame-show event >>> (http://www.mltframework.org/doxygen/event.html) that supplies a frame >>> object as an argument. Then, you can get the position from the frame >>> using get('_position'). (In C API, there is a mlt_frame_get_position >>> that I should add to mlt++.) >>> >>> I know you can setup a parameter-less event listener in Python - see >>> the ruby/play.rb for an example. However, you will not want to >>> wait_for an event; you will need to setup an event listener and be >>> able to get the frame parameter, which is a bit more complicated. In >>> mlt/src/swig/mlt.i you can see something special to setup a listener >>> for Ruby, and we might need something along these lines. I need to >>> time to explore this, but I am busy for a couple of months with other >>> commitments. >>> >>> I will try to find a little time to give the python listener some >>> attention, or you or someone else can look into it (it is at the >>> intersection of C++, Python, and swig). Or, you make this behavior >>> switchable in your code through a python variable until you decide >>> after some experimentation or feedback, make it a hidden config file >>> setting for power users, or even in Preferences. It is OK to send the >>> refresh property update to the sdl consumer - it will just ignore it. >>> >>>> Thanks, >>>> -Jonathan >>>> >>>> On Fri, Feb 19, 2010 at 10:01 PM, Dan Dennedy <[email protected]> wrote: >>>>> On Fri, Feb 19, 2010 at 7:45 PM, Jonathan Thomas >>>>> <[email protected]> wrote: >>>>>> I confirmed that the consumer is being stopped after a few seconds. >>>>>> I'm not sure why though. I'll look into it. >>>>> >>>>> BTW, looking over the code, I see some useless things: >>>>> >>>>> self.c.set("rescale", "1" ) >>>>> >>>>> This is a non-sensical value. It expects a string describing the >>>>> scaling method: nearest (default for SDL), tiles, bilinear (default >>>>> unless SDL), or hyper (best, but slow) >>>>> >>>>> self.c.set("distort", "1" ) >>>>> >>>>> This does nothing. >>>>> >>>>>> >>>>>> On Fri, Feb 19, 2010 at 9:42 PM, Dan Dennedy <[email protected]> wrote: >>>>>>> On Fri, Feb 19, 2010 at 6:56 PM, Jonathan Thomas >>>>>>> <[email protected]> wrote: >>>>>>>> Dan, >>>>>>>> Thanks for the suggestions. The "sdl_preview" worked fine. However, >>>>>>>> I was unable to figure out the consumer.set('refresh', 1). For >>>>>>>> example, if the video is paused for a few seconds, any resize to the >>>>>>>> screen will make the video area disappear (not redraw). I figure the >>>>>>>> .set('refresh', 1) method is supposed to tell the consumer to draw a >>>>>>>> frame of video back to the sdl window? Are we sure that "refresh" is >>>>>>>> the correct setting? It does not appear to have any effect. >>>>>>> >>>>>>> Yes, refresh is correct. Are you telling the consumer to stop or >>>>>>> setting the speed to 0 to pause it? >>>>>>> >>>>>>>> >>>>>>>> On Fri, Feb 19, 2010 at 3:59 PM, Dan Dennedy <[email protected]> wrote: >>>>>>>>> On Fri, Feb 19, 2010 at 12:13 PM, Jonathan Thomas >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Dan, >>>>>>>>>> >>>>>>>>>> We do not use melt for rendering, only to determine which audio and >>>>>>>>>> video codecs are installed. We have a single video thread, that >>>>>>>>>> either hooks up to a sdl consumer for previewing or a avformat >>>>>>>>>> producer for rendering. So, I'm not sure if I need to add the >>>>>>>>>> NO_VDPAU flag. What would you suggest? >>>>>>>>> >>>>>>>>> No, do not worry about it unless you want to give users a preference >>>>>>>>> setting to turn it off to aid with troubleshooting or workaround >>>>>>>>> incompatibility. >>>>>>>>> >>>>>>>>>> We have a bug report on LaunchPad explaining how to upgrade >>>>>>>>>> libsdl1.2debian to version 1.2.14. Other than that, we do not have >>>>>>>>>> much recommending that users upgrade. >>>>>>>>> >>>>>>>>> OK, just wondering as a result of a Kdenlive support issue. >>>>>>>>> >>>>>>>>>> I was unaware that the sdl_preview consumer existed. =) You might >>>>>>>>>> have told me before, now that you mention it, but that sounds much >>>>>>>>>> better than the sdl consumer. I had noticed that sdl just never lets >>>>>>>>>> up on the CPU. I will see if I can't integrate the sdl_preview into >>>>>>>>>> version 1.1 of OpenShot, before we release it. >>>>>>>>> >>>>>>>>> Yeah just .set('refresh', 1) when needed when paused and seeking or >>>>>>>>> adjusting effect param. >>>>>>>>> >>>>>>>>>> Thanks for the feedback! >>>>>>>>>> -Jonathan >>>>>>>>>> >>>>>>>>>> On Fri, Feb 19, 2010 at 12:02 PM, Dan Dennedy <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> Are you running melt or a separate child process to render? If so, >>>>>>>>>>> did >>>>>>>>>>> you heed my warning and set the MLT_NO_VDPAU environment variable? >>>>>>>>>>> >>>>>>>>>>> Finally, how are you recommending Ubuntu 9.10 users get the >>>>>>>>>>> libsdl1.2debian v1.2.14 from the luci repo that fixes the video >>>>>>>>>>> display issues on some systems? >>>>>>>>>>> >>>>>>>>>>> I will try to get around to some testing myself. One thing I noticed >>>>>>>>>>> recently is that you are using the sdl consumer and not the >>>>>>>>>>> sdl_preview. sdl_preview is not a perfect drop-in replacement - you >>>>>>>>>>> will need to add set-property calls to tell it when to refresh. >>>>>>>>>>> Basically, when you are paused, sdl continually updates the frame >>>>>>>>>>> using CPU during what appears to be an idle state, but sdl_preview >>>>>>>>>>> does not. sdl_preview also gets off of the XVideo port when paused >>>>>>>>>>> so >>>>>>>>>>> another media player can obtain it for better quality video playout >>>>>>>>>>> making it more friendly in a multi-tasking desktop environment >>>>>>>>>>> overall. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> +-DRD-+ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> +-DRD-+ >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +-DRD-+ >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> +-DRD-+ >>>>> >>>> >>> >>> >>> >>> -- >>> +-DRD-+ >>> >> > > > > -- > +-DRD-+ > _______________________________________________ Mailing list: https://launchpad.net/~openshot.developers Post to : [email protected] Unsubscribe : https://launchpad.net/~openshot.developers More help : https://help.launchpad.net/ListHelp
