View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001033KdenliveUser Interfacepublic2009-07-10 03:242010-09-22 17:54
Assigned To 
PlatformOSOS Version
Product VersionRecent git 
Target Version0.7.8Fixed in Version0.7.8 
Summary0001033: Timecodes indicate 23 fps in HD 1080p 23.98Hz project
DescriptionMade a new project using the HD 1080p 23.98Hz profile. When stepping through frames the timecodes shown in the timeline, preview window and perhaps other places show frame numbers counting from :00 to :22. After :22, the frame number rolls over to :00 again.

That range of frame numbers seems to indicate that there are 23 frames in a second, when the actual frame rate for this profile is 24000/1001 frames per second which is much closer to 24 than to 23. This discrepancy means that video that occupies one hour on the kdenlive timeline actually renders to 57 minutes 33 seconds.

The correct way to count frames here is not obvious to me since there aren't an integer number of them in each second. There is a standard drop frame time code for 60000/1001 (59.94) field-per-second interlaced NTSC video, but I haven't found a similar standard for 24000/1001 progressive. So, I can't honestly say that I know how the frame numbers should be handled in this case, but I'm pretty sure that treating them as if there are 23 in a second is not the right way.
TagsNo tags attached.
Build/Install MethodManual build from SVN
Attached Filestxt file icon kdenlive_patch_1003_v1.txt [^] (3,984 bytes) 2010-03-16 01:33 [Show Content]
txt file icon kdenlive_patch_1003_v1.1.txt [^] (3,579 bytes) 2010-03-16 01:35 [Show Content]
txt file icon kdenlive_DropFrame_Patch_v2.0.txt [^] (14,947 bytes) 2010-03-18 12:36 [Show Content]
txt file icon kdenlive_DropFrame_Patch_v2.1.txt [^] (15,130 bytes) 2010-03-18 21:07 [Show Content]
txt file icon kdenlive_DropFrame_Patch_v2.2.txt [^] (15,727 bytes) 2010-03-22 20:59 [Show Content]

- Relationships
related to 0001034closedddennedy A/V drifts out of sync in long HD 1080p 23.98Hz projects 

-  Notes
j-b-m (administrator)
2009-07-19 23:37
edited on: 2009-07-19 23:38

You're right, 23.98fps is not handeled correctly by Kdenlive. I use the drop frame timecode for NTSC (30000 / 1001), but like you I have no idea how to handle 23.98...

In the meantime, I made a commit (svn rev. 3739) to treat 23.98 as 24 fps, might improve the situation, and I also fixed a bug in the display of the timeline ruler, so now you will see 24 fps correctly...

If anybody has a hint on how to correctly display frames and timecode for 23.98fps, feedback welcome.

rockfx01 (reporter)
2010-03-11 07:14

23.98 ... actually 23.976 timecode is counted in Non-Drop Frame mode, never drop frame.

23.976 video should play at a speed = ((24 * 1000) / 1001), but the timecode should always be progressive. Frame counts should always count from :00 to :23, and then roll back over to :00. No dropped frames as in NTSC.

Does that answer your question?
rockfx01 (reporter)
2010-03-15 17:21

OK I did some further investigation on this with Final Cut Pro to see what the actual behavior was.

As stated above, timecode for 23.976 media is always progressive. So I exported a sequence with a duration of exactly 01:00:00:00 as an MOV. When opened in Quicktime, the exported file displayed a duration of 01:00:00:00 (with 'Show timecode when available' enabled), but when show timecode is turned off, it displays the duration in real time, which then read 0:01:00:03.60.

This is accurated if you calculate the real time duration based on the number of frames at a play speed of 23.976 fps.

Lesson learned:
Always play at ((24 * 1000) / 1001) frames per second.
Always display timecode at exactly 24 frames per second. Never drop any frames.
thatonefilmguy (reporter)
2010-03-16 01:41

I've written a patch that addresses this issue.

This patch also uses a better drop frame rate calculation which was partly to blame for this issue. (really it was caused because drop frames were calculated indiscriminately on any timecode that has a non-integer display rate, which 23.976fps falls under)

This patch also will now display drop frame timecode with the proper drop frame separator format "00:00:00;00" to indicate DF timecode in a DF project, rather than always using ":" (which is for non-drop frame timecode, NOT drop frame). Unfortunately this only fixes the issue for the sequence, and not for the Source/Timeline viewer windows.
thatonefilmguy (reporter)
2010-03-16 01:42

PLEASE USE "kdenlive_patch_1003_v1.1.txt", NOT "...v1.txt", as the first patch I uploaded had an extra change which should not have been included in this patch.
thatonefilmguy (reporter)
2010-03-16 15:23

OK Do not use either patch above :)

I have a better patch coming which fixes DF TC display in the monitors as well.

Additionally, I found that the timecode format "99:99:99;99" cannot be used because the QLineEdit inputMask does not allow semicolons to be used as separators. So instead I used "99:99.99:99" for DF notation, which is a common DF display format used by video decks.
thatonefilmguy (reporter)
2010-03-18 18:09

As stated on the ML:

"I just finished the patch. There might be a couple of spots in the GUI that I missed replacing with the "99:99.99:99" DF format, but at a glance I did not find any. If anyone finds areas that have not been replaced, please let me know. It should be easy to fix any missed areas.

The new patch is called "kdenlive_DropFrame_Patch_v2.0.txt" and I attached it to bug 0001033: [^]

A direct link to the patch: [^]

The new patch does the following:

    * Replaces the timecode separators in most (if not all) areas of the application including: Timeline, Project/Clip Monitors, Add Title Clip, Add Color Clip, Add Slideshow Clip, and Clip Properties dialogue boxes, as well as Keyframe/Effects windows.

    * Centralizes the inputMask values for DF/NDF into the new function "inputMask()" which is part of the Timecode class. This function can be called to get the appropriate inputMask QString, based on the timecode object that calls it. Therefore inputMask for both DF and NDF projects can be set using, for example:


instead of setting it manually:


    * The patch also implements a simple function to reformat the separators for timecode currently being displayed in the project. This is useful if/when the user changes the project format to reformat timecode values currently displayed if they are not already being refreshed when the project format changes. It is also useful for pre-processing default timecode duration values (such as Color Clip default length) before setting the default Color Clip duration value in the CC dialogue box. Supplying the default NDF "00:05:00:00" to the duration dialogue when the inputMask is set to DF results in the default duration being improperly set, so preprocessing the default duration is required. The default duration must be set in the same format as the input mask.

The new function, "reformatSeparators(QString duration)" is also a part of the Timecode class. So calling:


...would reformat the timecode from "00:05.00:00" if the project is Drop Frame, and will return it in the same format "00:05:00:00" if the project is NDF. Likewise, if "00:05.00:00" is supplied to the function and the project is NDF, then the function will return NDF timecode "00:05:00:00".

    * It implements another new function, "df()" as part of the Timecode class, which simply returns a boolean TRUE if the timecode object passed to it is drop frame.

if ( timecodeObject->df() ) { ... }

    * For slideshow clips, the default transition (luma) duration previously was hard coded to "00:00:00:24". Not only is this timecode value invalid for projects with 24 FPS or less, but it also is variable in duration for projects >25 FPS. This has been revised to always return a value of 1 second based on the FPS of the project:


    * Some other optimizations have also been made to Timecode.cpp which makes it slightly more efficient, as well as accommodates the new DF display format.

Download it and take a look!

thatonefilmguy (reporter)
2010-03-18 21:09

OK one more try...

Patch "kdenlive_DropFrame_Patch_v2.0.txt" resulted in a crash when opening the DVD Wizard from the File menu.

The new patch, "kdenlive_DropFrame_Patch_v2.1.txt" includes all the changes from the previous patch, but does not result in a crash when opening the DVD Wizard.
thatonefilmguy (reporter)
2010-03-22 21:01

Patch "kdenlive_DropFrame_Patch_v2.1.txt" sometimes resulted in timecode being displayed incorrectly in the Chapters page of the DVD Wizard. This seemed to occur when viewing an NTSC clip in a PAL DVD project.

The new patch, "kdenlive_DropFrame_Patch_v2.2.txt" includes all the changes from the previous patch "kdenlive_DropFrame_Patch_v2.1.txt", and fixes this defect.
xzhayon (developer)
2010-04-01 00:47

fixed in revision 4353

- Issue History
Date Modified Username Field Change
2009-07-10 03:24 madkins New Issue
2009-07-10 03:24 madkins Build/Install Method => Manual build from SVN
2009-07-19 23:37 j-b-m Note Added: 0003687
2009-07-19 23:37 j-b-m Status new => feedback
2009-07-19 23:38 j-b-m Note Edited: 0003687 View Revisions
2009-07-19 23:38 j-b-m Relationship added related to 0001034
2010-03-11 07:14 rockfx01 Note Added: 0004806
2010-03-15 17:21 rockfx01 Note Added: 0004827
2010-03-16 01:33 thatonefilmguy File Added: kdenlive_patch_1003_v1.txt
2010-03-16 01:35 thatonefilmguy File Added: kdenlive_patch_1003_v1.1.txt
2010-03-16 01:41 thatonefilmguy Note Added: 0004828
2010-03-16 01:42 thatonefilmguy Note Added: 0004829
2010-03-16 15:23 thatonefilmguy Note Added: 0004831
2010-03-18 12:36 thatonefilmguy File Added: kdenlive_DropFrame_Patch_v2.0.txt
2010-03-18 18:09 thatonefilmguy Note Added: 0004838
2010-03-18 21:07 thatonefilmguy File Added: kdenlive_DropFrame_Patch_v2.1.txt
2010-03-18 21:09 thatonefilmguy Note Added: 0004841
2010-03-22 20:59 thatonefilmguy File Added: kdenlive_DropFrame_Patch_v2.2.txt
2010-03-22 21:01 thatonefilmguy Note Added: 0004850
2010-04-01 00:44 xzhayon Note Added: 0004903
2010-04-01 00:44 xzhayon Status feedback => acknowledged
2010-04-01 00:45 xzhayon Note Deleted: 0004903
2010-04-01 00:47 xzhayon Note Added: 0004904
2010-04-01 00:47 xzhayon Status acknowledged => resolved
2010-04-01 00:47 xzhayon Fixed in Version => Recent git
2010-04-01 00:47 xzhayon Resolution open => fixed
2010-04-01 00:47 xzhayon Assigned To => xzhayon
2010-04-01 00:48 xzhayon Assigned To xzhayon =>
2010-04-01 00:49 xzhayon Target Version => future version
2010-09-14 11:01 j-b-m Fixed in Version Recent git => 0.7.8
2010-09-14 23:00 j-b-m Status resolved => closed
2010-09-22 17:54 Granjow Target Version future version => 0.7.8

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker