[FFmpeg-user] Want to hire a coder

[Francois Visagie]

> -----Original Message-----
> From: ffmpeg-user-bounces at ffmpeg.org [mailto:ffmpeg-user-
> bounces at ffmpeg.org] On Behalf Of Bouke (VideoToolShed)
> Sent: 17 July 2014 16:42
> To: FFmpeg user questions
> Subject: [FFmpeg-user] Want to hire a coder
> 
> Hi all,
> Tried this on the FFdevelop list, but no-one would take it...
> 
> Feature request / want to hire a coder, and IMHO a not so difficult.
> (Well, the devil will be in the detail's of course / famous last words...)
> 
> I would like to have proper timecode on capturing live streams.
> Now, the way it is currently, i can start the recording with a timecode
value,
> but there is no fixed relation between the moment FFmpeg is fired and the
> first frame is captured, so there is always an unpredictable offset.
> 
> What I think 'could' work is adding something that will hold FFmpeg at the
> point just before it starts buffering. (So start up FFmeg with '-timecode
> hold_horses' or whatever) Then, ask for a timecode value input.
> On receiving it, start filling the buffer and encode. (Taking the time
between
> that an initializing the buffer into account, if needed.)
> 
> That 'should' result in a +/- one frame accurace, as the start time could
be
> just after the beginning of a frame coming in, or very close to the end of
one,
> so there can be an offset of slightly less than one frame duration.
> No idea how to cope with that at the moment. Perhaps I could fire the
values
> at a fixed time intervals of N*frameDur so the offset would always be the
> same. (All sources may be genlocked.)
> 
> Instead of taking the timecode from the user, it could also use the system
> time. My main concern is that I get multiple recordings starting at
different
> moments in sync.

Let me say upfront I'm no expert at all on the matter. However, in case it
adds any value I'd like to offer my take on it.

If I understand correctly, the underlying principle of this approach is 1)
giving ffmpeg a starting timecode, 2) manipulating the start of ffmpeg's
processing in a way that most closely coincides with that time, and 3)
relying on the local system clock to provide future timestamps using the
given value as offset.

As you outline, this creates difficulty with synchronising the start of
processing with the given initial timestamp. In addition, this approach is
vulnerable to clock drift.

IF your recording environment provides genlock(?), might it be possible for
ffmpeg to be a genlock client? I.e. to not only obtain the initial
timestamp, but all following ones externally. 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. However, clock
drift would be eliminated. 

Apologies if this is off the mark.

> 
> Does this make sense?
> Doable?
> 
> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user