Closed zuf closed 11 years ago
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.
If you run "ffprobe -i the.mts" against your AVCHD clip, does it report colorspace yuvj420p or just yuv420p?
Fixed in git commit 06ead5bbc68092983e029800b6c35ee4fdd1a7a9
Thank you!
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 c48ed741443ffdc9ba510d0a99354d3a9fd89676 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
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.
Ok, thank you for explanations.
Hello.
I found significant performance regression with playing AVCHD clips in melt (and kdenlive). I made git bisect and found commit (c48ed741443ffdc9ba510d0a99354d3a9fd89676) with this regression. Without this commit I can smoothly play my project (1080p 25fps) in kdenlive or melt (CPU load is about 60-80% for one core). After this commit CPU load always around 100% and I see video with about 15 fps only.