[Module/5D3] SMPTE experiment, not usable

Started by g3gg0, August 19, 2013, 01:52:01 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

g3gg0

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)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

stevefal

Quoteyes, 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.
Steve Falcon

AnotherDave

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

How are things working?

g3gg0

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?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

stevefal

Steve Falcon

g3gg0

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.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

stevefal

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.
Steve Falcon

AnotherDave

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

g3gg0

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?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

g3gg0

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?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

AnotherDave

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

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.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

stevefal

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

http://www.youtube.com/watch?v=ykjyNeuQROU
Steve Falcon

g3gg0

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
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

AnotherDave

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

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?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

stevefal

Quotei 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.
Steve Falcon

g3gg0

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.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

AnotherDave

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

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?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

stevefal

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

g3gg0

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


        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);

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

applewide

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

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

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?