09.06.11 09:57, Dan Dennedy написав(ла):
> 2011/6/8 Maksym Veremeyenko<[email protected]>:
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mlt-devel
