openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

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
listener.  I took a look at the mlt.i file, but it wasn't clear to me
how it was working. 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.

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-+
>