https://bugs.kde.org/show_bug.cgi?id=403831

            Bug ID: 403831
           Summary: intelligent time estimation at rendering
           Product: kdenlive
           Version: 18.12.1
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: User Interface
          Assignee: j...@kdenlive.org
          Reporter: j...@cspv.hu
  Target Milestone: ---

SUMMARY

it would be great if the estimated rendering time could be a little more
accurate :) or rather, if estimation would be made more intelligently...

STEPS TO REPRODUCE
1. create a 1 min long project, and start rendering it
2. read the estimated rendering time 
3. check the actual duration after it's done

OBSERVED RESULT  (beware: a slow machine!! :))
with one color clip, 1 min, rendering as mp4 (23/160, medium speed, 1 thread)
estimation: 45 sec, actual time 1:10   (45:75 -- 150%  of the estimated time)

the same 1 min clip with 30 a second long title clip
estimated time: 3:20, actual time: 2:24  (200:144 --> 75% of the estimated
time)



EXPECTED RESULT
in both cases better estimates could be made :)

(Note: in both cases I could predict that the actual duration would be
different, including telling that it would be longer and shorter, respectively)

- - - - - - -
SUGGESTION:


#1
or there could be a function "test rendering speed"...
with a "built in", pre-defined series of rendering tasks... 
or 
KDENLIVE could be able to learn the machines IRL capabilities while rendering
:)

#2/A
a quick test rendering could be made with any project...
of variable time... like "quick" or "longer", during which some parts of the
project would be rendered, like 30 seconds of them, which could, in the end
make an intelligent guessing possible...

#2/B 
as an alternative to 2/A, a project survey could be made...
identifying 3 different types of sections, "parts"...

like: 
"type A task parts" -- plain video, no effect or overlay" 45% of the whole... 
"type B" -- some not so resource consuming video effects", 
"type C" -- some downright resource-demanding effects", transitions

as I imagine, even distinguishing just 3 types could make estimation much more
accurate...

cause before rendering a survey could be made as to how much of the 3 types
will have to be rendered... in percentage... like 6 minutes (A:45%, B: 25%,
C:30%)


NOTE:
when you're working on a a project, of COURSE, you'll learn it quickly how long
it will take to render one minute of it or the whole, so it's not such a great
deal if the estimation is not so accurate...
also, knowing that it is not-so-accurate helps a lot :)
so, after all, I'm not so sure if it should be dealt with at all...


--- thank you for developing KDENLIVE! ---







SOFTWARE/OS VERSIONS
Windows: 
MacOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to