Performance regression with AVCHD in commit c48ed741443ffdc9ba510d0a99354d3a9fd89676 about mlt

[ddennedy]

Perhaps this is because the AVCHD is marked as full color range. I might need to revert part of this change. I will look into it.

[ddennedy]

If you run "ffprobe -i the.mts" against your AVCHD clip, does it report colorspace yuvj420p or just yuv420p?

[ddennedy]

Fixed in git commit 06ead5b

[zuf]

Thank you!

[zuf]

Hello again. Now I start working with kdenlive and I found that performance degradation still exists (some frames drops). It works faster with latest git. But with reverted c48ed74 kdenlive works much faster.

Info about my video clips.

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'MVI_0719.MOV':
  Metadata:
    major_brand     : qt  
    minor_version   : 537331968
    compatible_brands: qt  CAEP
    creation_time   : 2012-08-17 21:01:16
  Duration: 00:03:07.92, start: 0.000000, bitrate: 45323 kb/s
    Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p, 1920x1080, 43783 kb/s, 25 fps, 25 tbr, 25k tbn, 50k tbc
    Metadata:
      creation_time   : 2012-08-17 21:01:16
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 2 channels, s16, 1536 kb/s
    Metadata:
      creation_time   : 2012-08-17 21:01:16

[ddennedy]

Sorry, but it is doing something more correct now because the colorspace is yuvj420p instead of simply yuv420p and thereby fixes a bug. You can see about how to tell the camera to not use the full luma range or in the Advanced Clip Properties, you can override it and turn it off.

[zuf]

Ok, thank you for explanations.