----- Original Message -----
From: "Nicolas George" <geo...@nsup.org>
Already done, for the most part. You should explain your actual problem in
details instead of trying to hire someone.
Ok, i'll try to outline the problem a bit more, and add some stuff others
wrote on the develop L.
And of course i'm interested in 'any' solution that will do the job, no
matter the routine used, that's open to discussion of course.
I need to add timecode to stream recordings, following either the internal
clock or timecode as given on input, but with a bit of math based on the
actual recording start.
Currently this is not possible, as starting FFmpeg with -timecode yadda
results in a file with the provided timecode,
but between the command and the first frame recorded is an unknown /
variable amount of time, thus there is no relation with the given time
anymore.
Hence it's not possible to stamp the output files with a timecode value that
has an accurate relation to the given input timecode.
Aim is to have multiple instances of FFmpeg using BM cards capturing, and
have matching TC on all output files.
It's not possible to start all streams at the same time, the BM API causes
blue screens of death when it's called too often in a short time, at least
half a second between the streams is needed.
----- Original Message -----
From: "Francois Visagie" <francois.visa...@gmail.com>
processing with the given initial timestamp. In addition, this approach is
vulnerable to clock drift.
True, I don't think that's a real problem: clock drift is in worst case some
4 frames per hour (measured on my worst computer.).
Thus, before the offset is more than half a frame (that could get you a
frame offset due to rounding),
7 minutes have passed. It's not a problem to do a sync to a time server each
minute or so.
(And the latest generations of TC generators can act like a time server if
needed.)
IF your recording environment provides genlock(?), might it be possible
for
ffmpeg to be a genlock client?
That would be great, no idea how difficult that turns out to be though.
If the sources are genlocked, the images will be in sync, and it's up to the
new feature to decide when the given TC should be upnumbered cause the time
between 'start' and the first frame buffered is < half a frame.
The problem with synchronising
the start of recording will remain but, as you seem to imply, few people
will be bothered by a possible less-than 1-frame offset.
Less than 1 frame offset can only exist is sound, not in video of course.
But yes, to get it 'really' right, the calculation of the correct time can
only be done at the moment it's sure what time it is when the first frame
is/will be buffered.
---
IMHO,
On the new feature, it's NOT possible to give 'any' timecode value in the
startup commandline, since it's not clear what the time difference is
between starting FFmpeg and the time the value is actually interpreted.
(But i could be wrong, perhaps FFmpeg knows the exact time it's started, in
that case some simple math could do the trick.).
So my idea was to have FFmpeg ask for TC input when all needed preperations
are done.
Another approach could be to feed FFmpeg with -timecode TODdf / ndf, and
have FFmpeg calculate the correct TC based on current system time when the
first frame is buffered.
From: "Oliver Fromme" <oli...@fromme.com>
Just an idea ... Would it help to provide a "wait" option?
In other words, you specify a timestamp on the command line
that is in the near future (a minute or just a few seconds
ahead), and that "wait" option would instruct ffmpeg to wait
until the local system clock actually reaches that timestamp,
right before starting the recording.
This could work just swell.
Thx,
Bouke
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
