From: Henrikki A. <hen...@gm...> - 2013-12-14 23:08:49
|
Hi all, I've been looking into bug 3181. http://www.kdenlive.org/mantis/view.php?id=3181 The bug is triggered when framerate is set to 3/1 or slower (so 3 seconds per frame). What happens is division by 0 error from Timecode.cpp line 414: int frames = framenumber % m_displayedFramesPerSecond; In there the m_displayedFramesPerSecond is 0. This is set earlier: void Timecode::setFormat(double framesPerSecond, Formats format) { m_displayedFramesPerSecond = (int)(framesPerSecond + 0.5); m_dropFrameTimecode = (framesPerSecond / 1.00 != (int)framesPerSecond) ; m_format = format; m_realFps = framesPerSecond; if (m_dropFrameTimecode) { m_dropFrames = round(m_realFps * .066666); //Number of frames to drop on the minute marks is the nearest integer to 6% of the framerate m_framesPer10Minutes = round(m_realFps * 600); //Number of frames per ten minutes } } So in situations where framesPerSecond is less than 0.5 (eg. 3/1 in the dialog -> framesPerSecond is 0.3333...) the m_displayedFramesPerSecond becomes 0, leading to crash. So I can figure out two ways to solve this: 1. Profile dialog could prevent giving more than 2 for first value in frame rate (or just set it 1 and disallow changing it) 2. The Timecode.cpp needs to be changed to allow 0 in m_displayedFramesPerSecond. Which one would be better (or a third option)? If 1, where should I poke my head to do this? -- Henrikki Almusa |
From: Vincent P. <vin...@la...> - 2013-12-15 04:27:21
|
Hello, Thanks for your involvement ! I would take option 2, allowing any value of fps, 1 being a workaround for a design limitation... displayed fps should be made a float for this case (0.33), or a fraction (1/3)? As you prefer/have time to do... Once done can you send a git-formatted patch? BR, Vincent Le 15/12/2013 00:08, Henrikki Almusa a écrit : > Hi all, > > I've been looking into bug 3181. > http://www.kdenlive.org/mantis/view.php?id=3181 > > The bug is triggered when framerate is set to 3/1 or slower (so 3 > seconds per frame). What happens is division by 0 error from > Timecode.cpp line 414: > > int frames = framenumber % m_displayedFramesPerSecond; > > In there the m_displayedFramesPerSecond is 0. This is set earlier: > > void Timecode::setFormat(double framesPerSecond, Formats format) > { > m_displayedFramesPerSecond = (int)(framesPerSecond + 0.5); > m_dropFrameTimecode = (framesPerSecond / 1.00 != > (int)framesPerSecond) ; > m_format = format; > m_realFps = framesPerSecond; > if (m_dropFrameTimecode) { > m_dropFrames = round(m_realFps * .066666); //Number of frames > to drop on the minute marks is the nearest integer to 6% of the framerate > m_framesPer10Minutes = round(m_realFps * 600); //Number of > frames per ten minutes > } > } > > So in situations where framesPerSecond is less than 0.5 (eg. 3/1 in the > dialog -> framesPerSecond is 0.3333...) the m_displayedFramesPerSecond > becomes 0, leading to crash. > > So I can figure out two ways to solve this: > 1. Profile dialog could prevent giving more than 2 for first value in > frame rate (or just set it 1 and disallow changing it) > 2. The Timecode.cpp needs to be changed to allow 0 in > m_displayedFramesPerSecond. > > Which one would be better (or a third option)? If 1, where should I poke > my head to do this? > |
From: Henrikki A. <hen...@gm...> - 2013-12-15 09:28:03
|
On 2013-12-15 06:27, Vincent PINON wrote: > Hello, > > Thanks for your involvement ! No problem. I'm trying to learn c++ so best way to do that is code and I do use kdenlive. > I would take option 2, allowing any value of fps, 1 being a workaround > for a design limitation... > displayed fps should be made a float for this case (0.33), or a fraction > (1/3)? As you prefer/have time to do... The return formats assume 2 numbers for frames, so I might have to change that to accommodate the larger numbers, here's hoping nothing breaks. Is there a preference to float or fraction? > Once done can you send a git-formatted patch? Yes. I have a clone of master. > BR, > > Vincent > > Le 15/12/2013 00:08, Henrikki Almusa a écrit : >> Hi all, >> >> I've been looking into bug 3181. >> http://www.kdenlive.org/mantis/view.php?id=3181 >> >> The bug is triggered when framerate is set to 3/1 or slower (so 3 >> seconds per frame). What happens is division by 0 error from >> Timecode.cpp line 414: >> >> int frames = framenumber % m_displayedFramesPerSecond; >> >> In there the m_displayedFramesPerSecond is 0. This is set earlier: >> >> void Timecode::setFormat(double framesPerSecond, Formats format) >> { >> m_displayedFramesPerSecond = (int)(framesPerSecond + 0.5); >> m_dropFrameTimecode = (framesPerSecond / 1.00 != >> (int)framesPerSecond) ; >> m_format = format; >> m_realFps = framesPerSecond; >> if (m_dropFrameTimecode) { >> m_dropFrames = round(m_realFps * .066666); //Number of frames >> to drop on the minute marks is the nearest integer to 6% of the framerate >> m_framesPer10Minutes = round(m_realFps * 600); //Number of >> frames per ten minutes >> } >> } >> >> So in situations where framesPerSecond is less than 0.5 (eg. 3/1 in the >> dialog -> framesPerSecond is 0.3333...) the m_displayedFramesPerSecond >> becomes 0, leading to crash. >> >> So I can figure out two ways to solve this: >> 1. Profile dialog could prevent giving more than 2 for first value in >> frame rate (or just set it 1 and disallow changing it) >> 2. The Timecode.cpp needs to be changed to allow 0 in >> m_displayedFramesPerSecond. >> >> Which one would be better (or a third option)? If 1, where should I poke >> my head to do this? >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > -- Henrikki Almusa |
From: Vincent P. <vin...@la...> - 2014-01-06 22:42:02
|
Le dimanche 15 décembre 2013, 11:27:50 Henrikki Almusa a écrit : > No problem. I'm trying to learn c++ so best way to do that is code and I > do use kdenlive. kdenlive "stable" is not always designed with the most modern trends & language features due to its now quite long history, but it is not worse than many projects ;-) > The return formats assume 2 numbers for frames, so I might have to > change that to accommodate the larger numbers, here's hoping nothing > breaks. Is there a preference to float or fraction? I think fraction is better understandable (1 image every 3 secs)... in some cases, but not in general :-/ the best would be a clever display, but is it worth the effort? If you find it too long to handle framerate<1, you can temporarily fix the bug by clamping the allowed value to >=1, and add a note in the bug without closing it to improve the solution later? |