<div dir="ltr">Thanks again Chris! <br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 9, 2018 at 8:21 PM, Chris Caudle <span dir="ltr"><<a href="mailto:chris@chriscaudle.org" target="_blank">chris@chriscaudle.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, April 9, 2018 6:05 pm, Chris Caudle wrote:<br>
> Again that should only account for 20-something<br>
> seconds, so I don't see how that explains the video being imported a<br>
> minute later on the timeline.<br>
<br>
</span>Actually, I think I was mis-remembering an earlier set of files.  With the<br>
most recent files (the ones which start at timecode 06:05:29), Ardour<br>
actually imports the audio file at 06:05:29 if the session frame rate is<br>
set to 29.97 drop.<br>
<br>
I'm looking more closely at the time code in the audio and video files,<br>
and something seems wrong in the video timecode.<br>
The BWF header in the file from the Zoom says origination time is 6:05:29.<br>
The origination time is 0x03ebc8b00, or decimal 1,052,543,744 (sample<br>
count since midnight for beginning sample).  That comes out to 6.0911<br>
hours, 6:05:28. Maybe I missed a rounding, but pretty close  to the<br>
6:05:29 in the origination time field.<br>
Anyway, before I lose the point, I can set the secondary clock display in<br>
Ardour to sample count, and when I zoom way in the audio file is imported<br>
exactly at sample 1,052,543,744.<br>
That is at 6:05:06:02 on the frame count when the session rate is 29.97,<br>
or 6:05:28 when set to 29.97 drop, so I think the audio file really is<br>
using drop frame.<br>
<br>
I double checked the audio from the video, using ltcdump -f 30/1.001df,<br>
and I see the skipped timecode values at the top of the minute:<br>
00000000   06:05:59.29 |  1211682  1213283<br>
00000000   06:06:00.02 |  1213284  1214884<br>
<br>
Note frame numbers 00 and 01 are skipped, as expected for drop frame time<br>
code.<br>
<br></blockquote><div><br></div><div>I confirmed that too, in the process I learned what "drop frames" are and what they do. <br><br></div><div>I decided to try some other fps settings, 29.97D is the default so I tried 29.97ND too. And I tried 25 fps on the F8 and also on the phone camera. I tried importing all that into Ardour and I am still seeing the late audio sync problems and no video when importing using the file timestamp. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think you said you set the RTC on the Zoom by hand, right?  So that<br>
might explain the slight offset of the timecode starting at 6:05:34 and<br>
your phone displaying 6:05:37, it probably takes about 3 seconds to type<br>
in the time and hit the button to start the clock running again, so I'm<br>
not putting too much into that.<br>
<br></blockquote><div><br></div><div>Yes exactly, I eye balled the time the best I could. I can't figure out an NTP or GPS time sync option on the F8. I noticed there is an F8 firmware upgrade available and I'll try that tomorrow to see if it helps at all. <br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The only message I see in the Ardour log is that the video is being<br>
aligned to 1,055,787,966 samples, nothing additional in the terminal<br>
window where I started ardour to indicate how that was determined.<br>
At this point I'm stumped at how to debug any more externally, I may have<br>
to bug Robin about where the LTC decoding happens in Ardour and see if I<br>
can figure out how to put a breakpoint in the debugger and step through<br>
the calculations that happen to determine where the video file should be<br>
imported.<br>
 </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I need to do some research on ffprobe and ffmpeg to see how the frame<br>
rates get reported, whether that is stored in metadata for the file or<br>
whether it is calculated somehow.<br></blockquote><div><br></div><div>I haven't looked at the source yet but that looks like the next step. Any help here would be much appreciated. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Just a thought, does your phone have any video quality settings you can<br>
tweak?  I'm thinking specifically about something like variable bit rate.<br>
I would not think that would leak through into the frame rate<br>
calculations, but I'm grasping at straws at this point.<br>
I don't have any other good examples of video files with time code<br>
embedded, I may have to try to generate some artificially by using ltcgen<br>
to create a time code audio track that I can mux with an existing video<br>
file.<br></blockquote><div><br></div><div>Yes, I am using the OpenCamera app and it allows a wide range of variable bit rates and fps options. I could try any combo, just let me know. <br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Chris Caudle<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Kind regards,<br></div><div class="gmail_extra">Robert<br></div></div></div>