Hi,

I'm testing to capture video footage with a Blackmagic Decklink HD Extreme 3D+ into Kdenlive using this configuration in the capture codification profile:

s=1920x1080 aspect=@16/9 b=145000k vcodec=dnxhd acodec=pcm_s16le

Everything works fine the first 5 seconds and then the capture starts to lost lots of frames, making look the video footage as a stop motion film.

Can you help me to solve this in some way?
Maybe I need a faster HDD? I'm using a Seagate esata 7200 rpm HDD


Also, when I try to transcode an AVCHD clip into DNxHD I get this message (using the regular DNxHD transcode presets in Kdenlive):

The value for top was -1 which is not within 0.000000 - 1.000000
¡Transcodification failed!

Are you capturing with kdenlive, or some other tool? If kdenlive, which version?

I have recorded dnxhd, but directly with ffmpeg. Personally I've found that the multi-threading when using mlt/kdenlive needs lot of work. That may or may not be your problem. For what it's worth, I encode to an SSD drive separate from the system drive and can encode using ffmpeg up to ~145fps with 720p 59.9 dnxhd 145M. (same bitrate as what you are trying to do)

You can capture directly to ffmpeg from decklink using bmdcapture. https://github.com/lu-zero/decklink-ffmpeg

Interesting. I am running ffmpeg v0.8 and another from head, and ffmpeg -h shows -top takes a -1 for automatic mode. Maybe the libav fork has changed that.
When running your capture to DNxHD, try adding threads=2 or more depending upon the number of cores. That passes through to libavcodec for the encoder.

"multi-threading when using mlt/kdenlive needs lot of work" What?

>> "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. When encoding via ffmpeg all cores are utilized at the same level. With kdenlive, there is usually one core at 100% and the rest being used, but generally at less then 50%.

It may not actually be a threading issue with the encoder per se, it may very well be that the temporal, spatial and color-space transforms that is done to the video, before handing it off to the encoder, is itself not multi-threaded or very well optimized and as a result starves the encoder threads.

Thanks Dan.. now the capture is better but still there are a little blink on the footage.. I'm using a Intel i7 1950, 4 cores, 8 threads.

Also I was testing to capture with BlackMagic Media Express with Mjpeg and there are differences in color between mjpeg codec and DNxHD codec.. here you can see what I mean:

http://www.youtube.com/watch?v=60_RHkpSHGw

File size for codec:

mjpeg x 1 hour = 42,55 Gb
DNxHD x 1 hour = 62,31 Gb

Wich one do you like more (color)?



FishB8 I tried to build the BMDcapture but this error was reported:

g++ -o bmdcapture bmdcapture.cpp ../../include/DeckLinkAPIDispatch.cpp -Wno-multichar -I ../../include -fno-rtti -D__STDC_CONSTANT_MACROS -g -lm -ldl -lpthread `pkg-config --libs libavformat`
bmdcapture.cpp: In function ‘int main(int, char**)’:
bmdcapture.cpp:730: error: ‘AVIO_FLAG_WRITE’ was not declared in this scope
bmdcapture.cpp:730: error: ‘avio_open’ was not declared in this scope
bmdcapture.cpp:803: error: ‘avio_close’ was not declared in this scope
make: *** [bmdcapture] Error 1


Can you tell me what it's wrong?

Best regards

It's probably API differences with the version of ffmpeg your are building against. I believe the tip of that git repo is meant to be build against libav (the ffmpeg fork), although I suspect it will also build against the just released ffmpeg-0.8.

If you check the history of that file you will see the diff changes made to that section of code to get it to build with the newer API in libav / ffmpeg 0.8.0. Revert those changes and it will probably build against ffmpeg 0.6.0 - 0.7.1. (That's what I did)

BTW: ffmpeg 0.7.1 is the same as 0.8.0, but with the older API.

Still, i'm getting a tittle blink on the capture function of Kdenlive. I'm using the next preset for capture 1080i 59.94:

s=1920x1080 aspect=@16/9 b=145000k vcodec=dnxhd acodec=pcm_s16le threads=4

I'm working with an Intel i7 1950 and 6 Gb RAM, a NVIDIA Geforce 8400 GS and a Seagate esata 7200 rpm 1TB

The footage quality it's almost perfect, just the little blink.. With the threads=4 i'm not losting any frames, just a extrange blinking.

Do I need a faster disk or graphic card?

When you say "blinking" are you talking about blinking in the captured footage, or just in the capture monitor?

I doubt the problem is with the external drive. The bit-rate should not be anything beyond what a dedicated drive can easily handle. Although it might depend on how the drive is formatted. If you use NTFS so that you can access it from a windows machine, then the performance will suck. The NTFS-3G driver that most Linux distros use for accessing NTFS is implemented in userspace (a FUSE filesystem) and is dog slow.

If that's the case, then you could try formatting it to ext2, and then use the Ext2fsd filesystem driver to connect to it from windows machines.

Hi,

> When you say "blinking" are you talking about blinking in the captured footage

Yes, the captured footage. Before the 'threads=4' option, kdenlive was reporting lots of losted frames. Now, using the 'threads' option, kdenlive is not reporting losses, but the captured footage gots an effect similar to those old muted movies from 1920 (the blinking).

I'm not using NTFS at all, just linux.

Best regards

Ok, well what build of kdenlive and MLT are you using? Are you building latest from svn / git?

I had this problem several weeks back but it had been fixed since then.

You can also try bumping up your thread count to see if that makes any difference. (Your distro probably has hyperthreading enabled, which would be seen by anything in userspace as 8 cores)

I'm using:

Kdenlive 0.8.1 rev. 5789
MLT 0.7.3
ffmpeg N-29565-g45ecc7a

I tried the hyperthreading thing. My computer detects 8 cores, so I changed the options to 'threads=8' on the capture profile, but there is no differences. The blink it is still there.

I'm gonna try deleting the folder for the kdenlive build and rebuilding everything from zero.

Best regards

Besides the blinking on the footage captured, working with DNxHD is so smooth..

I can make trims and everything and when rendering it is super fast.. Kdenlive it's getting so cool everyday

I rebuild everything and I'm still getting the blinking on the video footage.

Here you can see it:

http://www.youtube.com/watch?v=nZ0PtnXs7_s

You can apreciate the blinking on the red from the video. On the waveform, it looks like it can be apreciated in the lower right portion of the waveform monitor (as an oscillate waveform).

Ah, after watching that video I see that you are referring to something very different to what I was thinking. I thought you meant entire white frames like the frame capture was being corrupted or dropped.

I don't think your problem has anything to do with Kdenlive. :)

Are you in a room with florescent lights? Florescent lights are not always on like incandescent bulbs. They actually flicker very quickly. When their flicker rate is close to that of the camera framerate, and the camera is using a fast shutter speed, you get flickering like what is seen in that video. http://www.youtube.com/watch?v=1QbYAl4auF0

Try shooting something outside and see if you have the same issue.

I tested your suggestion but it is not a florescent problem.. I turned off the lights and filmed my little garden with cloudy natural light and the blinking it is still there.. and worst.. now that I moved the camera as i was shooting, the blinking transformed in a refresh rate between frames that renders too slow in the screen.

May I have to report this as a bug on ffmpeg?

Best regards