09.06.11 09:57, Dan Dennedy написав(ла):
> 2011/6/8 Maksym Veremeyenko<ve...@m1stereo.tv>:
>> hi,
>>
>> attached patch provides decklink consumer rework in order to simplify and
>> fix current bugs (#3311153, #3309546, #3308341). it also makes (IMHO) it
>> more straightforward and easer to investigate...
>>
>> i did a tests against videos i have and found no noticeable regressions.
>
> Overall, I like the direction of it very much; it is much clearer.
> However, there is at least one big problem. It does not respect the
> realtime frame-dropping behavior of mlt_consumer. Basically, I
> re-added this part between renderAudio() and renderVideo() plus
> members and initializers to support it.
>
> if ( mlt_properties_get_int( MLT_FRAME_PROPERTIES(frame), "rendered") )
> {
>       // Close the previous frame and use the new one
>       mlt_frame_close( m_frame );
>       m_frame = frame;
> }
> else
> {
>       if ( !m_frame )
>               m_frame = frame;
>       // Reuse the last frame
>       mlt_log_verbose( getConsumer(), "dropped video frame %u\n", ++m_dropped 
> );
> }
>
> ---
>
> If a frame is not rendered, then the render-ahead thread in
> mlt_consumer has decided to skip preparing an image for it (if
> real_time>  0). You did not notice because you can still request to
> render an image anyway on-demand by calling mlt_frame_get_image and
> also because you were probably not stressing it.
>

thanks for noticing that - that is just clear what "rendered" properties 
of frame means.

I would like to propose two ways for workaround of frame-dropping 
behavior of mlt_consumer:

1. i can honer them by two ways
     a) keep latest rendered frame and output (without audio) it for a 
case of non-"rendered" as it was present in origin code
     b) just avoid any render(Audio|Video) if it dropped frame but 
increment counter (m_count) - lets decklink freeze latest frame

2. use mlt_consumer_get_frame (i think its the same as 
mlt_consumer_rt_frame but without RT behavior) - what could be most 
preferred because there is also a check:
[...]
<------><------>// enqueu more frames if underrun
<------><------>if(bmdOutputFrameDisplayedLate == completed)
<------><------><------>ScheduleNextFrame(false);
[...]

i can even implement both by either by #ifdef or by properties like "rt" 
that could split (regulate) behavior for dropped frames workaround...

> I am still testing it. In your own testing, please lookout for screen
> tearing, which is why I was previously creating multiple
> IDeckLinkMutableVideoFrames. I did not see it yet maybe because
> ScheduleVideoFrame() is now synchronous with
> ScheduledFrameCompleted().

i will try to load system hard and test again...

-- 
________________________________________
Maksym Veremeyenko


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel

Reply via email to