On Mon, Aug 30, 2010 at 11:23 AM, Dan Dennedy <d...@dennedy.org> wrote: > On Mon, Aug 30, 2010 at 8:59 AM, Simon A. Eugster <simon...@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-+ > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
