openshot.developers team mailing list archive

[Dan Dennedy <dan@xxxxxxxxxxx>]

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