<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 11, 2018 at 7:21 AM, 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 10:18 pm, robertlazarski wrote:<br>
> I confirmed that too, in the process I learned what "drop frames" are and<br>
> what they do.<br>
<br>
</span>Yeah, I realized I only partially understood how drop frame timecode<br>
works, so I had to spend some time going through the details.<br>
The ATSC standard used for digital TV broadcast in the US and some Asian<br>
countries calls out 30fps and 29.97fps, I was hoping that everyone would<br>
just switch to straight 30fps and drop frame would go away, but I guess<br>
during the transition period from analog to digital broadcasts they went<br>
with 29.97002997002997... for compatibility, and then just never switched.<br>
 We're stuck with it forever probably.<br>
<br></blockquote><div><br></div><div>For a music performance video that does post through Ardour and ends up on youtube or whatever ... In your opinion, should I use or not use drop frames? I'm sort of doing "option bingo" right now :-) . <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">
Anyway, I didn't get a chance to try stepping through the video import<br>
last night, but I did do a sanity check on video file import, and using a<br>
file I generated with ltcgen and ffmpeg I verified that I could import a<br>
video file and it would line up on the timeline exactly where I expected.<br>
<br>
I used a bitmap editor to generate a 720x480 bitmap, it was just a single<br>
color background with "LTC Test" text added so that I had a starting frame<br>
for the video.  Named test_image.bmp for reference below.<br>
<br>
I created an audio file with timecode starting at 6:05:29 to match your<br>
earlier file (length was picked as some semi-random value a little over 5<br>
min long):<br>
ltcgen -f 30/1.001df -l 00:05:32:15 -t 06:05:29:14 time_code_test_060529.wav<br>
<br>
Created video with command:<br>
ffmpeg -loop 1 -i test_image.bmp -i time_code_test_060529.wav -c:v libx264<br>
-tune stillimage -c:a aac -b:a 192k -pix_fmt yuv420p -r 30000/1001<br>
-shortest timecode_test_video.mp4<br>
<br>
When I opened timecode_test_video.mp4 in Ardour it lined up right at 6:05:29.<br>
So that seems to point at something in your specific video file having<br>
some feature that confuses the ardour import.<br>
You should be able to duplicate using those command lines I pasted in<br>
above, you just need to create a single bmp file in a graphics editor to<br>
start with.<br></blockquote><div><br></div><div>Wow, thanks for that info! I am definitely going to look deeper into that analysis. When you say "create a single bmp file" , do you mean like Gimp? Sorry I am a video and graphics newbie and some things I don't understand yet. <br><br></div><div>The whole idea of this project was to use phone cameras since they are disposable. Nice cameras with a BNC timecode input become obsolete too soon for them to be worth it to me ymmv. However I already suspected my problems are in the Irig DUO / phone chain somewhere. <br><br></div><div>So instead of setting up a second phone camera chain I went with a different chain after the F8: The Zoom Q8 and a Tentacle Sync E timecode generator. I was going to split the BNC signal out of the F8 for each camera but the TS has LTC audio out and the cables I need. <br><br>The short story on the Q8 is it uses MOV as the video format, I figured with ffmpeg I can convert it if need be. The audio can be embedded in the video or recorded to separate files. It has very good L/R 1/4 audio inputs with video quality barely competitive with the latest phones but that is ok at the moment. It was only a little more than another Irig DUO. <br><br></div><div>This new gear is arriving Friday so I will test it out then.  <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">
<span class="gmail-"><br>
> Yes, I am using the OpenCamera app and it allows a wide range of variable<br>
> bit rates and fps options. I could try any combo, just let me know.<br>
<br>
</span>And the app is set at 29.97fps? I'm still confused about why ffmpeg is<br>
flagging the video file as 29.89fps. Maybe just a rounding error since<br>
that original file is only 42 seconds long.  Have you tried with a file<br>
from that phone which is a few minutes long?<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>The android Moto X (2nd generation) used in the links I provided has defaults, and my camera app just
 uses those unless I do "option bingo". The frame rate the phone uses
 for these videos is a mystery to me. I tried another phone (Latest Moto X) and it does that same weird fps. I also don't understand yet why 
re-encoding the video frame rate didn't fix the problem.  <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>
Chris Caudle<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Kind regards,<br></div>Robert<br></div>