Re: [Mlt-devel] [PATCH] restart decklink if input signal changed mode

[Dan D. <da...@de...>]

On Tue, Sep 9, 2014 at 9:52 PM, Dan Dennedy <da...@de...> wrote:

> On Mon, Sep 8, 2014 at 9:44 AM, Dan Dennedy <da...@de...> wrote:
> > On Mon, Sep 8, 2014 at 1:04 AM, Maksym Veremeyenko <ve...@m1...>
> wrote:
> >> 08.09.14 00:59, Dan Dennedy написав(ла):
> >>>
> >>> On Wed, Sep 3, 2014 at 7:27 AM, Maksym Veremeyenko<ve...@m1...>
> >>> 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
>
> Maksym, I found that after the auto-profile step of melt, I am
> receiving an unexpected additional VideoInputFormatChanged() but with
> only event bmdVideoInputColorspaceChanged. However, colorspace is
> controlled by the BMDDisplayMode, and it is correct in the second
> pass. Therefore, if I make the following change, then it makes my
> problem go away and probably still works for you:
>
>
My previous diff was mangled by the plain text word wrapping. Here is that
patch as HTML e-mail to preserve line endings;

diff --git a/src/modules/decklink/producer_decklink.cpp
b/src/modules/decklink/producer_decklink.cpp
index 3b45301..710d33c 100644
--- a/src/modules/decklink/producer_decklink.cpp
+++ b/src/modules/decklink/producer_decklink.cpp
@@ -594,6 +594,7 @@ public:
  profile->description = strdup( "decklink" );
  mlt_log_verbose( getProducer(), "format changed %dx%d %.3f fps\n",
  profile->width, profile->height, (double) profile->frame_rate_num /
profile->frame_rate_den );
+ m_new_input = profile;
  }
  if ( events & bmdVideoInputFieldDominanceChanged )
  {
@@ -608,7 +609,6 @@ public:
  ( mode->GetFlags() & bmdDisplayModeColorspaceRec709 ) ? 709 : 601;
  mlt_log_verbose( getProducer(), "colorspace changed %d\n",
profile->colorspace );
  }
- m_new_input = profile;
  return S_OK;
  }
 };