Author Topic: [Module/5D3] SMPTE experiment, not usable (Read 84497 times)

g3gg0 · « **Reply #125 on:** September 21, 2013, 05:12:24 PM »

23.976 is not integer, so it most likely wont work with continuous output.
if you only output 10 audio frames to jamsync, it should do the job.

yes, you need the mlv version of raw_rec, how else would you sync the raw video to audio.

this module outputs that timecode, that is being written into the MLV container file.
so you can exactly sync audio frames to video frames if you recorded the smpte output along with your scene audio.
(on the 3rd channel)

stevefal · « **Reply #126 on:** September 21, 2013, 05:47:11 PM »

Quote

yes, you need the mlv version of raw_rec, how else would you sync the raw video to audio.

I wasn't sure if that integration was done, or if there was just an experimental non-mlv raw_rec that you had modified just to get vsync working.

I get it. Thanks again.

AnotherDave · « **Reply #127 on:** October 03, 2013, 12:01:59 AM »

Been out-of-the-loop.... where is the latest and greatest version to try out?

How are things working?

g3gg0 · « **Reply #128 on:** October 03, 2013, 01:25:07 AM »

updated the main post with the latest build.
didnt change anything for a while.

the build should work as expected and output the SMPTE time.
anything missing?

stevefal · « **Reply #129 on:** October 03, 2013, 02:58:34 AM »

I assume 23.976 fps still missing...

g3gg0 · « **Reply #130 on:** October 03, 2013, 10:12:02 AM »

Uh no it is implemented. But as said, continuous output might cause trouble.
this was said to be not necessary. A few seconds are enough.

i cant test it because i dont have the chance to test.

stevefal · « **Reply #131 on:** October 03, 2013, 06:04:18 PM »

I think it's a pretty big compromise. If a track is not fully striped, it means you're relying on two clocks being perfectly timed in order for things to stay in sync over a long take. One should be able to sync two clips from the middle. You should also be able to cut a clip, process it externally, e.g. noise reduction, and re-sync it without having to work with the whole take. Also it's unclear how every app will work when the audio LTC doesn't match the framerate that you're syncing to. It may not work at all in some NLEs/graders/apps. Continuous LTC is standard.

[EDIT] I realize this is billed as 'not usable'. I just want to help make sure normal LTC use is understood.

AnotherDave · « **Reply #132 on:** October 03, 2013, 06:16:03 PM »

Where is the latest version of mlv_rec.mo to test? Any ideas? Looking all over for it... :-/

g3gg0 · « **Reply #133 on:** October 03, 2013, 06:49:21 PM »

ok in 23.976 fps mode, you might see one frame offset after a few thousand frames.
will this hurt?

iirc in this thread it was said free run mode is just fine.
i thought a few seconds LTC audio *is* free run mode, am i wrong?

g3gg0 · « **Reply #134 on:** October 03, 2013, 06:56:34 PM »

i am using 44.1kHz sampling rate.
with 23.976 fps, the buffer for one LTC frame should be 1840.3393 samples.
but i am using 1840, so we are 0.3393 samples per frame too short.

after 5422 frames (226 seconds) the audio is one frame ahead and exactly one frame out of sync.

is that a problem?

AnotherDave · « **Reply #135 on:** October 03, 2013, 07:13:43 PM »

48khz is usually the standard we record in on our external recorders.

Will it be 1 frame off for every 5422 seconds? If so, that could be a problem.

If you can point me in the direction of the latest compiled build for this, I'd be happy to do some testing over the weekend.

g3gg0 · « **Reply #136 on:** October 03, 2013, 07:24:46 PM »

i wrote 226 seconds / 5422 frames.
so you continuously record raw video clips with about 4 minutes length where you need perfect sync?
thats a problem then.

i didnt change anything to smpte since the last build i posted.

if the generated audio has 44.1kHz or 48kHz doesnt matter as you have an analog audio cable.

stevefal · « **Reply #137 on:** October 03, 2013, 09:51:04 PM »

This relates to the TC going into the MLV video. Is it dropframe? Is 24fps rawrec video 24fps or 23.967?

g3gg0 · « **Reply #138 on:** October 03, 2013, 10:22:13 PM »

ah thanks for the video.
forgot to say that i dont handle drop frames either.
will watch the video and maybe i can add that feature.

i just dont know how to verify that it works

AnotherDave · « **Reply #139 on:** October 03, 2013, 10:47:06 PM »

Could that be the source of the sync issue? Since it is consistent?

Also, I am having a super hard time location the latest compile and latest mlv_rec.mo... It is starting to make me feel stupid. :-/

g3gg0 · « **Reply #140 on:** October 03, 2013, 10:57:05 PM »

Quote from: AnotherDave on October 03, 2013, 10:47:06 PM

Could that be the source of the sync issue? Since it is consistent?

which sync issue do you mean?

stevefal · « **Reply #141 on:** October 03, 2013, 11:05:00 PM »

Quote

i just dont know how to verify that it works

We could shoot a TC generator as reference, and then analyze the video and audio/TC clips to see if nothing slips during a long run.

Important to remember that timecode counts time, not frames. Subtracting starttime from endtime should give actual duration when played at correct speed.

g3gg0 · « **Reply #142 on:** October 04, 2013, 12:04:09 AM »

Quote from: AnotherDave on October 03, 2013, 10:47:06 PM

Also, I am having a super hard time location the latest compile and latest mlv_rec.mo... It is starting to make me feel stupid. :-/

see main post in mlv thread.

AnotherDave · « **Reply #143 on:** October 04, 2013, 05:53:28 AM »

Quote from: g3gg0 on October 03, 2013, 10:57:05 PM

which sync issue do you mean?

You said it is off by 1 frame every 226 seconds, and that pattern continues every 226 frames...

That sounds like a drop frame vs. non-drop frame issue... Drop frame drops frames every so many seconds to account for a sync issue that was discovered when color tv first started broadcasting... or something like that.

Dave

g3gg0 · « **Reply #144 on:** October 04, 2013, 12:24:34 PM »

no, this is the reason:

Quote from: g3gg0 on October 03, 2013, 06:56:34 PM

i am using 44.1kHz sampling rate.
with 23.976 fps, the buffer for one LTC frame should be 1840.3393 samples.
but i am using 1840, so we are 0.3393 samples per frame too short.

after 5422 frames (226 seconds) the audio is one frame ahead and exactly one frame out of sync.

is that a problem?

stevefal · « **Reply #145 on:** October 04, 2013, 03:03:12 PM »

Maybe a silly idea but could it occasionally alternate to a buffer that is 1841 samples?

g3gg0 · « **Reply #146 on:** October 04, 2013, 04:40:42 PM »

i already implemented the correction routine yesterday, just didnt test it.

Code: [Select]

        uint32_t correction_needed = (smpte_out_calls * smpte_out_buffer_remainder) / smpte_current_fpsx1000;
        
        if(correction_needed > smpte_out_corrected)
        {
            trace_write(trace_ctx, "smpte_asif_out_cbr: applying length correction #%d", correction_needed);
            corr = 1;
            smpte_out_corrected++;
        }

        SetNextASIFDACBuffer(smpte_out_buffers[smpte_out_buffer], smpte_out_buffer_size + corr);

applewide · « **Reply #147 on:** May 11, 2014, 04:50:13 PM »

hi

can somebody give smpte module for 1.2.3 canon the night built please, appreciate you guys very much to take a look

dpjpandone · « **Reply #148 on:** August 16, 2014, 06:09:05 AM »

I wanted to try this, but I get the following error when I restart the camera with this module loaded:

raw_rec_cbr_stopping defined twice (from mlv snd and smpte)
also same message for _skip_frame, _cbr_stopping, _mlv_block

and undefined symbol 'module card drive'

failed to link modules.

I know it says "5D3" in the title.... and I tried it on 7D anyways......

maybe we can work on some of this timecode stuff this fall when u have time, I am still REALLY interested in this, I want to build an arduino-based smart slate that could use a canon DSLR as master and vice-versa!

mario1000 · « **Reply #149 on:** March 20, 2015, 02:45:51 PM »

Dear g3gg0

I wanted to give your experimental SMPTE module on a 5D3.113 (latest nightly build) a try based on this video:

.

After I copied the module from your first post into the module folder and switched the camera back on all I get is a lot of weird error messsages and no module was loaded. After removing the module everthing worked fine again. Does a new version of your module exists working together with the latest nightly builds?

News:

Author Topic: [Module/5D3] SMPTE experiment, not usable (Read 84497 times)