[FFmpeg-user] Want to hire a coder

[Bouke (VideoToolShed)]

----- Original Message ----- 
From: "Nicolas George" <george at 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.visagie at 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" <oliver at 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