Re: [Mlt-devel] [PATCH] restart decklink if input signal changed mode
On Mon, Sep 8, 2014 at 9:44 AM, Dan Dennedy d...@dennedy.org wrote:
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 Veremeyenkove...@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
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:
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;
}
};
Is it OK we make this change to your patch?
--
+-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=157508191iu=/4140/ostg.clktrk
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Re: [Mlt-devel] [PATCH] restart decklink if input signal changed mode
On Tue, Sep 9, 2014 at 9:52 PM, Dan Dennedy d...@dennedy.org wrote:
On Mon, Sep 8, 2014 at 9:44 AM, Dan Dennedy d...@dennedy.org wrote:
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 Veremeyenkove...@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
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;
}
};
--
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=157508191iu=/4140/ostg.clktrk___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Re: [Mlt-devel] [PATCH] restart decklink if input signal changed mode
08.09.14 00:59, Dan Dennedy написав(ла): On Wed, Sep 3, 2014 at 7:27 AM, Maksym Veremeyenkove...@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 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 Veremeyenko -- 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=157508191iu=/4140/ostg.clktrk ___ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
Re: [Mlt-devel] [PATCH] restart decklink if input signal changed mode
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 Veremeyenkove...@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=157508191iu=/4140/ostg.clktrk ___ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
[Mlt-devel] [PATCH] restart decklink if input signal changed mode
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.
--
Maksym Veremeyenko
From a2a7c254df003a7082d395626dac904a647cd326 Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko ve...@m1.tv
Date: Wed, 3 Sep 2014 19:11:50 +0300
Subject: [PATCH] restart decklink if input signal changed mode
---
src/modules/decklink/producer_decklink.cpp | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/modules/decklink/producer_decklink.cpp b/src/modules/decklink/producer_decklink.cpp
index 04510f4..e194b38 100644
--- a/src/modules/decklink/producer_decklink.cpp
+++ b/src/modules/decklink/producer_decklink.cpp
@@ -79,6 +79,7 @@ private:
}
public:
+ mlt_profile m_new_input;
void setProducer( mlt_producer producer )
{ m_producer = producer; }
@@ -91,6 +92,7 @@ public:
m_producer = NULL;
m_decklink = NULL;
m_decklinkInput = NULL;
+ m_new_input = NULL;
}
virtual ~DeckLinkProducer()
@@ -606,6 +608,7 @@ public:
( mode-GetFlags() bmdDisplayModeColorspaceRec709 ) ? 709 : 601;
mlt_log_verbose( getProducer(), colorspace changed %d\n, profile-colorspace );
}
+ m_new_input = profile;
return S_OK;
}
};
@@ -627,6 +630,13 @@ static int get_frame( mlt_producer producer, mlt_frame_ptr frame, int index )
mlt_position end = mlt_producer_get_playtime( producer );
end = ( mlt_producer_get_length( producer ) end ? mlt_producer_get_length( producer ) : end ) - 1;
+ if ( decklink decklink-m_new_input )
+ {
+ decklink-m_new_input = NULL;
+ decklink-stop();
+ decklink-start( decklink-m_new_input );
+ }
+
// Re-open if needed
if ( !decklink pos end )
{
--
1.7.7.6
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
