which information/field in MLV then should contain the time stamp so you can make use of it?
I think it would be immediately useful to add the timestamp to the filename, (it's already in mlv field)
The reason is that when proxies are created (and I think most render to a proxy format like cineform or prores for editing) the mlv data is lost, but filenames are easily retained.
The timestamp is not very useful when the file is in MLV format, it's not needed until editing, so this is why I think there should be an option to add timestamp to filenames.
When editing software allows native editing on MLV format, and computer hardware that can do it efficiently exists, we can make use of it in MLV data as well
The use case is this, when I import all the converted video files into adobe premiere, I can right click on a file, and easily assign it a starting timecode. If the timestamp is in the filename, it's a matter of copying and pasting into timecode window, and then at least the clips will automatically synchronize within one second. This is a huge timesaver for cameras that do not have reference sound for sync. At least then they are in the ballpark and only have to be nudged a few frames in either direction to achieve sync.
Another advantage is that when you open a project on another computer, and it has to search for files, it will be highly unlikely that duplicate files are found, since each file will have a timestamp in the name. So your project should find all the files with ease.
Here is a video that may help you understand:
http://library.creativecow.net/harrington_richard/DSLR-Timecode/1They are showing an excellent way to do this with h.264, but this does not work with mlv -> acr -> proxy workflow, because MLV timestamp is lost in conversion.
Re: second accurate clock:
second accuracy is better than no timestamp at all, but I think we can find a workaround to get frame accurate timestamp:
Since each frame has it's own timestamp in the MLV, we must find the first frame that has an updated timestamp, and we should use that as our reference to which all other frames timestamps are derived from. if I was coding for arduino it would go like this:
previousTimestamp=LoadRTCCal;
currentTimestamp=LoadRTCCal;
if currentTimestamp != previousTimestamp;
reference = currentTimestamp;
MLVtimestamp = (reference - offset);
I know this isn't entirely correct, but I hope it is helpful.
We will need a counter that is reset when the first frame starts recording, and the counter will increment each time a new frame is captured, this will give us our offset
Once we have found our reference frame, and subtracted the offset, we should have a frame accurate timestamp.
Please let me know if you need more information, or if there is anything I can do to help.
