kdenlive doesn't seem able to scale my video properly during the render.

My clips are in DV NTSC 16:9 format. So that means they have non-square pixels. I'm trying to render to h.264/mp4 using the H.264 2000K profile and I'd like the finished video be 16:9 with square pixels.

The originals are 720x480, PAR 40:33, DAR 20:11. If I choose the H.264 2000K profile and force scale to 640x360 (a 16:9 resolution), the finished product comes out with Pixel Aspect Ratio 1:1 (which is good), but 640x372 and DAR 160:93. Why were 12 scanlines added? I have tried adding various melt directives like display_aspect_num=16 display_aspect_den=9, but it makes no difference.

My work around is that I just render the whole project to DV, then use ffmpeg to properly transcode and scale. This is ok, but I would prefer to only transcode once.

So 2 questions:

1) Does anyone know why kdenlive/melt don't seem to be able to scale to my specifications?
2) Is there some better way to "pipe" to ffmpeg? Like piping something like huffyuv+pcm directly to ffmpeg without saving an intermediary (huge) file?

Thanks!

Anyone have any ideas on this?

Thanks.

I have still never been able to figure this out. Does anyone have any ideas for either of the 2 questions?

Thanks.

Which Kdenlive / MLT version?
A recent change in FFmpeg broke rendering with h.264 because previously we used "profile=dv_ntsc_wide" to pass the profile to MLT, but that now conflicts with FFmpeg's rendering args.

That should be changed to "mlt_profile=dv_ntsc_wide".

Can you try to render using the "Generate script option", that will create a "script0000.sh" file in ~/kdenlive/scripts and copy / paste the content of the file here (remove any private info if you want like user name, etc).

kdenlive 0.7.8-2
mlt 0.6.2-2
x264 0.106.1741

Thanks - I did some checking and this may have more to do with kdenlive or mlt's interaction with libx264. I rendered the same clip to the following stock profiles, rescaling to 640x360, and these are the PAR/DARs and any unique error that ffmpeg reports for each finished file (from ffmpeg -i ):

H.264 800k - 640x372 [PAR 1:1 DAR 160:93], [h264 @ 0x154cb10]brainfart cropping not supported, this could look slightly wrong ...

XVid4 800k - 640x360 [PAR 1:1 DAR 16:9]

MPEG-4 800k - 640x360 [PAR 1:1 DAR 16:9]

As you can see, still getting those extra 12 scanlines just like I was before (that was with different versions of kdenlive, mlt, x264, etc), but only with x264.


Here's the kdenlive_renderer script:

#! /bin/sh

SOURCE="/home/user/Videos/Project/scripts/script003.sh.mlt"
TARGET="/data/tmp/Project.mp4"
RENDERER="/usr/bin/kdenlive_render"
MELT="/usr/bin/melt"
PARAMETERS="dv_ntsc_wide avformat - consumer:/home/user/Videos/Project/scripts/script003.sh.mlt /data/tmp/Project.mp4 f=mp4 hq=1 acodec=aac ab=128k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=800k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=@16/9 s=704x396"
$RENDERER $MELT $PARAMETERS


Thanks for responding - its nice to have someone to communicate with about this vexing problem!

Oh, you are using rather old MLT / Kdenlive versions... it's hard to tell the problem but I think there were also lots of changes / improvements in recent FFmpeg / libx264 so my guess is that you should upgrade to newer versions to solve the issue.

Also, I don't really understand why the script mentions an output size of 704x396 (s=704x396) if you wanted 640x360...

One last thing you can try is to do a transcoding with FFmpeg (MLT uses the FFmpeg libraries to render) so that you can be sure if the problem is in FFmpeg /libx264.

Try something like this:

ffmpeg -i mydv_wide_clip.dv -f mp4 -hq -acodec aac -ab 128k -ar 48000 -pix_fmt yuv420p -vcodec libx264 -minrate 0 -b 800k -b_strategy 1 -subcmp 2 -cmp 2 -coder 1 -flags +loop -flags2 +dct8x8 -qmax 51 -subq 7 -qmin 10 -qcomp 0.6 -qdiff 4 -trellis 1 -aspect 16:9 -s 640x360 test.mp4