This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Timecode Reading
#1
Hi Selur,

I've noticed that Hybrid is reading some timecodes from footage differently to how Davinci Resolve or Media Info might do so

I have a 29.97 clip that Mediainfo and Resolve reads the start timecode as 

00:05:43:08

Hybrid reads it as

00:05:43.610 (I'm guessing the final number is in msec rather than frames)

Problem is that when injecting timecode into the ProRes on the 'ProRes' tab, it's reading as 

0:5:43:61

Is there a way to improve the timecode reading/stamping on my clips? My hope is to take the standards converted clips from Hybrid and re-conform back in Resolve as close as possible using the original timecode

Thanks

James


Attached Files Thumbnail(s)
           
Reply
#2
If can you share a sample where this happens I can look into it.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#3
Hi Selur,

This video should demonstrate the issue

https://drive.google.com/file/d/1Q0CncGc...sp=sharing

Thanks

James
Reply
#4
Ah, okay I see the problem.
MediaInfo reports:
Video
Count                                    : 391
Count of stream of this kind             : 1
Kind of stream                           : Video
Kind of stream                           : Video
Stream identifier                        : 0
StreamOrder                              : 0
ID                                       : 1
ID                                       : 1
Format                                   : VC-3
Format                                   : VC-3
Commercial name                          : DNxHD 220x
Commercial name                          : DNxHD 220x
Format version                           : Version 1
Format profile                           : HD@HQX
Codec ID                                 : AVdn
Codec ID/Info                            : Avid DNxHD
Codec ID/Url                             : http://www.apple.com/quicktime/download/standalone.html
Duration                                 : 9643
Duration                                 : 9 s 643 ms
Duration                                 : 9 s 643 ms
Duration                                 : 9 s 643 ms
Duration                                 : 00:00:09.643
Duration                                 : 00:00:09:19
Duration                                 : 00:00:09.643 (00:00:09:19)
Bit rate mode                            : CBR
Bit rate mode                            : Constant
Bit rate                                 : 219980759
Bit rate                                 : 220 Mb/s
Width                                    : 1920
Width                                    : 1 920 pixels
Height                                   : 1080
Height                                   : 1 080 pixels
Pixel aspect ratio                       : 1.000
Display aspect ratio                     : 1.778
Display aspect ratio                     : 16:9
Rotation                                 : 0.000
Frame rate mode                          : CFR
Frame rate mode                          : Constant
Frame rate                               : 29.970
Frame rate                               : 29.970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Frame count                              : 289
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Chroma subsampling                       : 4:2:2
Bit depth                                : 10
Bit depth                                : 10 bits
Scan type                                : Progressive
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 3.540
Delay                                    : 343610
Delay                                    : 5 min 43 s
Delay                                    : 5 min 43 s 610 ms
Delay                                    : 5 min 43 s
Delay                                    : 00:05:43.610
Delay                                    : 00:05:43:08
Delay                                    : 00:05:43.610 (00:05:43:08)
Delay_Settings                           : DropFrame=No / 24HourMax=No / IsVisual=No
Delay_DropFrame                          : No
Delay, origin                            : Container
Delay, origin                            : Container
Stream size                              : 265158656
Stream size                              : 253 MiB (100%)
Stream size                              : 253 MiB
Stream size                              : 253 MiB
Stream size                              : 253 MiB
Stream size                              : 252.9 MiB
Stream size                              : 253 MiB (100%)
Proportion of this stream                : 0.99999
Encoded date                             : 2024-03-06 16:29:06 UTC
Tagged date                              : 2024-03-06 16:29:06 UTC
colour_description_present               : Yes
colour_description_present_Source        : Container
Color primaries                          : BT.709
colour_primaries_Source                  : Container
transfer_characteristics_Source          : Container
Matrix coefficients                      : BT.709
matrix_coefficients_Source               : Container
Gamma                                    : 2.400

Hybrid looks at these three lines:
Delay                                    : 00:05:43.610
Delay                                    : 00:05:43:08
Delay                                    : 00:05:43.610 (00:05:43:08)
and since all these should represent the same info, it simply sticks with the first. Smile
<input_data name="TimeCode" value="00:05:43.610"/>
The value Hybrid collects can also be seen, if you open the 'Show All Data' info in 'Base'-tab.
Which results in Hybrid using '-timecode 0:5:43.61'.
Strangely when using this:
ffmpeg -r 30000/1001 -y -noautorotate -nostdin -threads 8 -ignore_editlist true -i "C:\Users\Selur\Desktop\TEST_2997.mov" -map 0:0 -an -sn -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv  -pix_fmt yuv422p10le -strict -1 -vsync 0  -vcodec prores_ks -profile:v 0 -vtag apco -timecode 0:5:43.61 -metadata encoding_tool="Hybrid 2024.03.05.1" -aspect 1920:1080 -f mov "G:\Output\TEST_2997_1_2024-03-06@19_14_01_9210_01.mov"
Strangely when looking at the output, MediaInfo reports:
Delay                                    : 00:05:45.045
Delay                                    : 00:05:45;01
Delay                                    : 00:05:45.045 (00:05:45;01)
But, if I use: "-timecode 0:5:43:8" it properly reports:
Delay                                    : 00:05:43.610
Delay                                    : 00:05:43:08
Delay                                    : 00:05:43.610 (00:05:43:08)
So the problem seems to be that "00:05:43.610" and "00:05:43:08" are not the same. :/
Normally:
"00:05:43:08" represents hrs:minConfusedeconds:ms
and
"00:05:43.610" represents hrs:minConfusedeconds.NumberOfFrames
Problem is that FFmpeg
-timecode hh:mm:ssSEPff

    Specify Timecode for writing. SEP is ’:’ for non drop timecode and ’;’ (or ’.’) for drop.
sees this differently.
-> I'll adjust Hybrid to capture the hrs:minConfusedec:ms time.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#5
Send you a link to a dev version for testing, which hopefully fixes the problem and doesn't break other time related stuff. Wink

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#6
I will take a look, thanks so much for all your hard work looking into this!
Reply
#7
These changes are incorporated in the curren release, so test with the current release.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#8
Hi Selur,

I tested the latest version and it now accurately printing the timecode onto the new file. Can I ask if another addition can be made?

At the moment, the timecode from the original frame rate file is being copied onto the new file. However, that causes errors because it's not a direct translation once the frame rate is converted.

E.g. Original Frame Rate 29.98 - 00:05:43:28
New Frame Rate 23.98 (when using Hybrid) - 00:05:44:04

Because ':28' can't exist in the new frame rate, some sort of conversion is happening that leads to an incorrect frame rate.

I think it could be more accurate by converting to frames and then back to timecode at the end

E.g. Original Frame Rate 29.98 - 00:05:43:28
Conversion timecode to frames: 10,311
Conversion to new frame rate: (10,311/29.98)=~344     344*23.98=~8247
Conversion frames to timecode: ~05:43:22

Understandably there are round errors but the end timecode is accurate to within a frame or so when tested in Davinci Resolve

Thanks and hope you're up for the challenge!

James
Reply
#9
Quote:E.g. Original Frame Rate 29.98 - 00:05:43:28
New Frame Rate 23.98 (when using Hybrid) - 00:05:44:04

Because ':28' can't exist in the new frame rate, some sort of conversion is happening that leads to an incorrect frame rate.
I'm confused. Huh
When converting telecined 29.97fps content to 23.976fps via ivtc, the playback length of the clip does not change.
Since frame rate and frame count get changed in the same way.
I do not understand how a different the timecode could lead to an incorrect frame rate.
This timecode should only indicate the offset to another file and it should not have anything to do with the frame rate.
=> did you mean 'incorrect time stamp' instead of ' incorrect frame rate' ?

00:05:43:28 usually indicates 5min 43seconds and 28 frames. 343*29.98 +28 = 10.311 frames.
So assuming you are converting telecined 29.98fps content to 23.976fps by adjusting the frame count and the frame rate in the same way (ike ivtc does), the 28 frames would need to be adjusted.
When changing from 29.98fps to 23.976fps the 28 frames need to be converted to 28*23.976/29.98=22
So you would end up with 00:05:43:22 instead of 00:05:43:28.

Main problem I have with this is I'm totally unsure how to add this to the gui without overcomplicating this with tons of controls and at the same time be sure that this is applied only when needed.
=> Sorry, but I'm not going to implement this. I leave it to the user to adjust such time codes. Especially since the tiemcode usually indicates the offset to another file and Hybrid has no way of knowing whether the other file was changed like the current file will be changed by Hybrid.

Cu Selur
----
Dev versions are in the 'experimental'-folder of my GoogleDrive, which is linked on the download page.
Reply
#10
Hi Selur,

I chose some poor terminology, I did indeed mean 'incorrect time stamp/timecode' when converting between frame rates.

I think your method for correcting the frame number is tidier than what I was suggesting and makes a lot of sense

However, if you're unable to implement that without a lot of work I do understand. Given I have to batch convert a lot of material and cannot manually adjust the timecode, I may have to look into a script that does that for myself. Is there a way to inject a script into any of the processes that Hybrid does?

Thanks

James
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)