FYI, I've just added raw footages from the Canon EOS 7D in Kdenlive's camcorder database.

More informations:
* http://www.kdenlive.org/video-editor/canon-eos-7d
* http://kevin.deldycke.com/static/documents/canon-eos-7d-movie-samples/
* http://kevin.deldycke.com/2010/05/canon-eos-7d-movie-samples/

Thanks, these work for me.

I can confirm that Canon EOS 7D footages are well suported with the following set of components:
* Kdenlive 0.7.8
* MLT 0.5.10
* FFmpeg 0.6
* Kubuntu 10.10

I'm finding kdenlive is detecting the h264 from the 550D (similar to 7D) as BT601 not 709. So I'm seeing combed luma in the scopes.

Also the resolution is detected as 1920x1088, so I created a new project profile 1920x1088 but when extracting an image from the monitor it scales the 1920 higher to compensate for the increased height, even though I set 1920x1088.

**EDIT**

Ok strike the colourspace and luma range, just checked for updates in sunabs PPA and the latests gives control over both, Dan, Fantastic. A real first, the only OSS NLE that offers this and does the job right.

With latest MLT (0.5.10) the last 8 pixels will be cropped automatically (they are black anyways). So you should be able to use the normal profiles.
Have a look at this profile: http://kdenlive.org/video-editor/canon-eos-550d

ttill, thanks but I'm using MLT 0.5.11 and kdenlive from sunabs svn PPA. Importing Canon EOS 550D video doesn't appear to be working correctly, I get a message telling me that a profile doesn't exist for 1920x1088 and using the 1920x1080 25p profile results in the frame being scaled down to accommodate the extra pixels giving me a black bar each side within a 1920x1080 frame.

Also it's applying a BT601 colour space when it's BT709 so have to force 709 on every file import. :-(

Disregard the new, somewhat annoying dialog about profile mismatch.

I have an EOS 7D clip, and it too says the colorspace is 601. We use what ffmpeg tells us unless it reports unknown, in which case we use Poynton's heuristic for "HD" (#pixels > 750000) to choose 709.

I do not get the black bars you describe. Just downloaded the 550D sample clips and same thing.

Dan, thanks for the reply. It's still happening with latest svn from sunabs PPA.

http://blendervse.files.wordpress.com/2010/10/kden-svn.jpg

It shows black bars left and right, this is part of the image. Histogram shows solid black bar. Also opening the extracted image which is 1920x1080 not 1088, up in Gimp shows the black bars as transparent. So not only image not right but it's been scaled down to 1920x1080 and kept the black bars. :-( If the black bars are there it should be a 1088 width, if not cropped off to 1080, not both. :-)

re. Colour primaries/matrix coefs of 7D / 550D, I've put a query into Canon for confirmation of 601/709 but I anticpate it'll be 709 and it's well known to be full range.

Also the image shows histogram, it's set to 709 and the spikey histogram shows something isn't right still.

I've forced 709 and full luma in the clip properties, still get spikey histogram, so I think mlt/kdenlive is doing the 709 full luma forcing based on a 601 starting point.

Meaning when MLT forces 709 is it doing it from a 601 frame from FFMPEG or telling FFPEG to treat the video source as 709 and full luma? Hopefully it's not taking a 601 restricted luma source and converting to 709 full range?

If I can not reproduce the problem, then I can not fix it. I have done all I am going to do in this area for the meantime. I have other stuff to do.

No problem, perhaps it's my set up I don't know. It works for you doesn't for me so I'll come back another time and try again.

Even the Eiffel Tower sample video in this thread does it and if I extract a frame using a 1080P project I get a 1934x1088 image and transparent bars down the sides :-(

I also get constant crashing with Aside preview on mpeg2 HDV .m2t extension. :-(

So long and thanks.

Regarding the 1088/1080 problem, I have an EOS-550D camera that does the same. Very simple: ignore it. The 1088 resolution seems to be only in the (mov) container, the video track is actually 1080, I've never had to crop any lines.

I must correct myself here, it seems it's the other way around, the container (mov) says 1920x1080, but the video stream itself is 1920x1088. Strange. One way or the other I never had any problems with that, but all of a sudden it shows up. I've change my ffmpeg command line a bit:

ffmpeg -y -i MVI_0791.MOV -vf "crop=1920:1080" -acodec pcm_s16le -vcodec dnxhd -vsync 1 -b 145000k -f mov mvi_0791.mov

Please note the -vf "crop=1920:1080 part, that cuts away 8 lines.

yellow, there was a regression in the handling of 1920x1088 since the 0.7.8 release that I just fixed tonight.