On Mon, Sep 8, 2014 at 1:04 AM, Maksym Veremeyenko <ve...@m1stereo.tv> wrote: > 08.09.14 00:59, Dan Dennedy написав(ла): >> >> On Wed, Sep 3, 2014 at 7:27 AM, Maksym Veremeyenko<ve...@m1stereo.tv> >> wrote: >>> >>> Hi, >>> >>> if input signal to decklink board is differ from specified at board >>> initialization or changed later, decklink could inform it by >>> VideoInputFormatChanged callback. but it still does not give a proper >>> frame >>> at VideoInputFrameArrived >>> >>> provided patch stop/start decklink board with updated profile. >>> >> >> I tested this patch today, and it causes a regression for me. I am >> using Desktop Video 9.8 on Ubuntu 12.04 64-bit. I am giving a DeckLink >> SDI card SD NTSC input, and running simply "melt -verbose decklink:" >> which starts with a dv_pal MLT profile, then performs "auto-profile" >> in which DeckLink input format detection occurs and changes the >> profile. The regression I experience is that there are very many >> dropped frames "[consumer sdl] dropped video frame" and playback is >> very choppy, of course. Adding "-consumer sdl real_time=0" or -1 does >> make the problem go away, but I consider the "out of the box" >> experience of "melt decklink:" broken by it. >> > i think that is normal because of there is no framerate convertor in mlt and > 29.97 incoming framerate cause a drop frame because consumer works with 25 > fps
OK, based on the timing of events, that could be a logical explanation. However, with melt auto-profile, and the correct sequence of events, the consumer should have been reconfigured with the new frame rate. Correct sequence means VideoInputFormatChanged was received before the return of the first mlt_frame. Let me study this patch and code more. Maybe I can determine a condition when a restart is necessary and other times not. > before startup decklink been configured to dv_pal, but after > *VideoInputFormatChanged* notification call it is been restarted with > detected profile, like dv_ntsc in you case. > > in my case without patch i receive a white frame that generated by: > > [...] > if ( !*frame ) > *frame = mlt_frame_init( MLT_PRODUCER_SERVICE(producer) ); > [...] > > with a path i receive at least some frames. > > my test case was sending 1080i50 into dv_pal configured input and visa-verse > >> Does the problem you address occur with a different version of Desktop >> Video? Or, do I need a different test scenario to produce the problem >> you see? >> > i use the same diver version -- +-DRD-+ ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
