search

mltframework / mlt

MLT Multimedia Framework
https://www.mltframework.org
GNU Lesser General Public License v2.1
1.48k stars 314 forks source link

Performance regression with AVCHD in commit c48ed741443ffdc9ba510d0a99354d3a9fd89676 #18

Closed zuf closed 11 years ago

zuf commented 11 years ago

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.

ddennedy commented 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.

ddennedy commented 11 years ago

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

ddennedy commented 11 years ago

Fixed in git commit 06ead5bbc68092983e029800b6c35ee4fdd1a7a9

zuf commented 11 years ago

Thank you!

zuf commented 11 years ago

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
ddennedy commented 11 years ago

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 commented 11 years ago

Ok, thank you for explanations.