new First Light changes are doing something odd
 

David, I was playing with your new changes in FL, especially with the burn-in of meta-data with the info from your blog. Very powerful and very interesting! Wow, you guys are adding some pretty powerful stuff for the future! I was very excited, as this adds "instant burned-in TC windows" in a non-distructive way, which greatly speeds up our translation checking process when sending this stuff out worldwide for dubbing. Great addition and it is only one little new aspect!

But I noticed something odd. When I "burned-in" the timecode and ran it in preview mode in any VFW program, the 1920x1080p NTSC video is seemingly being interpreted as 25fps PAL and the burn-in timecode window was showing TC totally different than that represented below in the interface TC window! Somethings screwy there.

FYI, on this ws, the output (under View) is 1/2 res (no dif with full), and viewed as YUV.

Frame by frame advance shows this clearly, switching the burnin tc at 25 frames, but the interface TC window switching seconds at 30 frames. The status bar on the bottom clearly shows the clip as being 29.97003, so prob apparently is in the passive data interpretation?

Suggestions?

The burn-in extracts timecode from the sample (each frame) if it is different the FL display, think about how the image was acquired. There was a bug in SI-2K captures that put 24fps timecode into 25fps files, so this could happen elsewhere. This actually demonstrates the power of sample based metadata -- the decode that was acquired at frame encode time is never lost.

This footage was V1 60i, up'ed to 1920x1080p, and edited and final output mastered at 30p NTSC. Everywhere else it shows as regular ole 29.97 NTSC and the tc tracks correctly.

Why would the FL burn-in read be different? I can frame by frame it and see they are different as interpreted. It's got to be a bug. This video never saw 24/25 fps in it's life.

Our bug, not in the burn-ins, but in HDLink. When a clip doesn't report a timecode through HDLink we default to a 24fps timecode, we should use the frame rate.

Figured it was something easy. Am looking forward to the fix, tnx!

Timecode in First Light
 

My First Light is doing the opposite. XDCAM EX footage shot at 25p and with the passive metadata showing the timecode base correctly as 25fps. The burn-in timecode in First Light is correct, but the interface timecode runs on a 30fps base, though the start point is correct.

It doesn't matter at the moment, but it would be nice to have some agreement.

Any new betas with this prob addressed, David?

Not for this one yet.