[Kdenlive-devel] Crop effect does not work on .kdenlive clips

[Dan Dennedy]

On Mon, Aug 30, 2010 at 11:23 AM, Dan Dennedy <dan at dennedy.org> wrote:
> On Mon, Aug 30, 2010 at 8:59 AM, Simon A. Eugster <simon.eu at gmail.com> wrote:
>> As the Canon EOS 550D is recording with 1088 px height.
>
> Note to self: avoid purchasing a camera that does this!
>
>> When using 1080p as project profile, black borders are created on the
>> left/right of the video (scaled down to 1080). So one option is to add a
>> Crop effect to every single clip in the timeline and cutting off 8 px from
>> the bottom (or the top).
>
> I wonder if it makes sense at all to change the pixel aspect ratio? I
> think that is a little more convenient than crop on each clip.

No, bad idea. From a little analysis, I see that 1088 is used because
it is an integral number of macroblocks (68*16 = 1088). AVCHD and
similar contain crop information in the H.264 parameter sets. However,
on the Canon EOS cameras, the sequence parameters sets contain 0 for
the cropping fields. There might be signaling elsewhere that ffmpeg
does not understand because interestingly Quicktime shows it as 1080
(VLC as 1088). Or, Quicktime may have baked in some heuristic, which
is what I am considering. The logic would very constrained: if no
override, height is 1088, and project aspect ratio is 16:9 crop 8 rows
from the bottom.

>> The other possibility would be to work with a 1088p project profile and,
>> when done, import this .kdenlive project in a new project (add it as clip)
>> with a 1080p profile, adding the crop effect only once to the .kdenlive clip.
>
> I am not sure that is best. What about footage that is not from the
> EOS 550D - it will be cropped. And you have to make the custom project
> profile, remember to use it, and remember this procedure (easy for you
> and I but maybe not for someone editing a few times a year).
>
>> At least in theory. In practise, the crop effect does not do anything
>> applied to a .kdenlive file. Why? And could this be fixed for the next release?
>
> I can not tell you why right now, but I will take a look into. The way
> crop is integrated is special. It is probably something simple.
> However, I think we might want to think about another remedy. I am not
> sure what right now. It would be interesting to see what people are
> doing on other editors and platforms.

OK, it was simple, but only at a conceptual level. :-) I have a local
branch named autoprofile that I have been working on for a couple of
weeks that somewhat addresses the issue. Basically, the problem is
that MLT XML does not contain a MLT profile specification. The branch
adds XML (de)serialization of profile as well as some logic in melt
and supporting changes elsewhere.

When supplying a video clip and no -profile, melt analyses it and
generates a matching profile to make simple playback and transcode
scenarios simpler, more obvious, less surprising. When supplying a
.mlt or .kdenlive file and no -profile, melt uses the serialized
profile, if available. When supplying a .mlt or .kdenlive file and
also specifying a -profile, melt automatically uses the 'consumer'
producer.

The consumer producer is what is used by Kdenlive to render to a
resolution or aspect ratio different from the project, but currently
(master branch) it is required explicitly. So, there may be a
fundamental problem today with loading .kdenlive files into Kdenlive
as a clip: the profileinfo kdenlive adds is not understood by MLT and
MLT does not automatically wrap it in a consumer producer.  I say
"may" because I am assuming Kdenlive is doing nothing special when
loading a .kdenlive as a clip, but I could be wrong.

I have a little more work to do on the autoproducer branch before
merging it. For one, the logic of when to add the consumer producer is
in melt, the utility, and the how is somewhat a hack. So, it will not
"just work" today in the .kdenlive as a clip use case. I need to see
if I can address this and do more testing in general.

>> Footage can be found here:
>> http://kdenlive.org/video-editor/canon-eos-550d
>>
>> Simon
>
> --
> +-DRD-+
>