openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

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 <dan@xxxxxxxxxxx> wrote:
> 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-+
>