If it's not the lights then I have no idea what is causing that problem, or where in the tool-chain that is happening, or even if it is possibly a hardware issue.

Do you get the same problem capturing with BlackMagic's MediaExpress?

When you view the recordings on the camera's LCD or on a TV connected to the camera's video (or HDMI) output, is the flicker present?

When I capture with Media Express from BlackMagic to uncompressed or to mjpeg codec, or when I capture to the camera's own AVCHD codec or when i look trough the camera's LCD or to the monitoring system, there is no flicker at all.

Just when I capture from Kdenlive to NDxHD codec (I tried different codecs, h.264, ffv1, but it lost lots of frames) I get the flicker.

I came with the DNxHD capture on Kdenlive idea when I look the 'Ingex' project, that captures DNxHD with ffmpeg.

Have you tried to capture from a different camera (or other type of source) to see if you get the same issue?

I tried with another camera and the problem it's the same.. it is a ffmpeg problem? If so, I go to the libav forum to ask for help

If it did it with a different source, then it might be an issue with ffmpeg. There is a slight chance that there might be something goofy going on with MLT's interfacing with the decklink API, but I've never experienced anything like that. There is a slight chance that it is a hardware issue with decklink, but I doubt that is the case if Blackmagic's Media Express didn't present any problems.

The problem is that dev's from the ffmpeg / libav project may not pay much attention since that codebase does not directly interface with the decklink API.

You could narrow it down by using the bmdcapture to grab a raw video stream. If the raw video stream has no problems, but still has the pulsing problem after being encoded to somthing else via ffmpeg, then you can say,"Ok, here is a raw video file that is causing problems somehow with ffmpeg."

If you do that and there are no issues, then the problem might be somewhere in MLT / Kdenlive. And in that case you could provide a raw video sample when creating a bug report.

Hi FishB8,

I builded bmdcapture and captured some raw video footage (yuv 4:2:2) and then transcoded it to DNxHD with very good results.. it seems that the flicker it's a kdenlive/MLT problem.. I really don't know what to do..

How can I report this issue to be corrected in next release?

Best regards

Bug reports for kdenlive are filed here: http://www.kdenlive.org/mantis/my_view_page.php

You can create a bug report there and describe what is going on. Be sure to note that you captured from the same device and source using bmdcapture and didn't have any issues.

Be sure to include:
-Model of decklink card used
-Camera model that is plugged into the card input
-Input type (analog, SDI, HDMI, etc.)
-Decklink driver version
-Versions of ffmpeg / libav, mlt, and kdenlive

Also you can capture directly to DNxHD by piping the feed straight to ffmpeg and save yourself time and space from capturing a raw video first:

bmdcapture -F nut -f pipe:1 | ffmpeg -y -i -

Thanks a lot for your time and help FishB8!

>>> "multi-threading when using mlt/kdenlive needs lot of work"
>> What?
> I do not see the same multi-threaded encoding performance when encoding via kdenlive that I seen when encoding directly from ffmpeg.

You are comparing a simple file transcode to a non-linear editor? At the very least we are doing automatic scaling, padding, and deinterlacing as-needed to your project settings. When some of those are not needed, there is still some overhead as MLT internally uses 4:2:2 for YUV (assuming all image operations stay in the YUV domain) plus a little more for frame-accurate seeking. Now add on all the filters and compositing. So, yes, encoding is being held back by the reading, demuxing, decoding, and all audio/image processing occurring in a single thread. If you want to experiment with parallel processing, see Settings > Environment > Processing threads. However, limit yourself to 2 or 3 and keep in mind there are quite a few things that are not still not concurrent. Also, you can turn on multi-threaded decoding, which is improved for libavcodec v53.

For the people who wants to capture video footage directly to DNxHD here is the preset i'm using with bmdcapture:

./bmdcapture -C 0 -m 9 -F nut -f pipe:1 | ffmpeg -y -i - -s 1920x1080 -aspect 16/9 -b 145000k -vcodec dnxhd -acodec pcm_s16le -threads 4 yourname.mov

bmdcapture is a command line (you have to download the app and then build) that captures from Blackmagic decklink cards and then transcode the footage via ffmpeg, all this in real time.

Thanks to FishB8 for the support.

How does that bmdcapture output compare with melt on the command line? IOW, does capturing with melt work any better with its command line utility melt rather than kdenlive?

melt -verbose -profile atsc_1080i_5994 -consumer avformat:yourname.mov b=145000k vcodec=dnxhd acodec=pcm_s16le threads=4

The latest versions of melt does input signal detection so you can drop -profile atsc_1080i_5994. I have to shuffle the DeckLink card back into my Linux box and do some more testing, and I will soon (but my only source of HD SDI is just another computer with SDI out).

When I use that melt command line, I get the help response, no footage at all.. I copy/pasted your command line.

I'm using MLT 0.7.3

Best regards

Sorru, I forgot to specify decklink input. :-\

melt -verbose -profile atsc_1080i_5994 decklink: -consumer avformat:yourname.mov b=145000k vcodec=dnxhd acodec=pcm_s16le threads=4