openshot.developers team mailing list archive

[Dan Dennedy <dan@xxxxxxxxxxx>]

On Sun, Feb 21, 2010 at 4:35 PM, Jonathan Thomas
<jonathan.oomph@xxxxxxxxx> 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 <dan@xxxxxxxxxxx> wrote:
>> On Sat, Feb 20, 2010 at 11:37 PM, Jonathan Thomas
>> <jonathan.oomph@xxxxxxxxx> 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 <dan@xxxxxxxxxxx> wrote:
>>>> On Fri, Feb 19, 2010 at 7:45 PM, Jonathan Thomas
>>>> <jonathan.oomph@xxxxxxxxx> 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 <dan@xxxxxxxxxxx> wrote:
>>>>>> On Fri, Feb 19, 2010 at 6:56 PM, Jonathan Thomas
>>>>>> <jonathan.oomph@xxxxxxxxx> 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 <dan@xxxxxxxxxxx> wrote:
>>>>>>>> On Fri, Feb 19, 2010 at 12:13 PM, Jonathan Thomas
>>>>>>>> <jonathan.oomph@xxxxxxxxx> 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 <dan@xxxxxxxxxxx> 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-+