1 Jul 10:46
Re: Scheduler:
Hi, Christian Thaeter wrote: > Anton Yakovlev wrote: >> Hi, guys! >> >> Two simple questions: >> 1) How to interpret job's gavl_time_t value from scheduler's point of >> view? I mean, how can I understand, that it's time to fire up some job? > > The job's time should be copied into the schedulers table, that needs > more memory space, but far less pointer dereferencings (i saied that > already). Then the heap algorithm can just do (64bit type) comparsions > (less than) to sort it. Note that the scheduler runs on real/absolute > time. Gavl has no much provisions for this (Burkhard, shall we do our > own stuff here or do you want to include some simple time functions > which in the gavltime api?). There is a simple timer already (gavl_timer_t), which works perfectly for me. The flaw is, that it's based on gettimeofday(), the most portable solution. I would like to implement it with clock_gettime(CLOCK_MONOTONIC, ...), but that must be optional since I'm sure that MinGW (where gavl was ported to) doesn't have clock_gettime(). If you can live with the current gavl_timer_t API, you can use it. If you think you need more (or different) functionality, it would better to do your own stuff. Burkhard(Continue reading)
because Juan probably referred to the NTSC video framerate (23.976)
-- thanks for pointing that out!
I think, for the most common video framerates, we should provide fixed
identifiers on the API/GUI (and internally represent them as rational numbers).
>> .... Even worse, a lot of (consumer) cameras clock drift depending on
>> temperature, moon-phase and mood, the audio sample rate is not exactly
>> 48kHz but some Hz more or less (i'd guess frame rates may drift too). Some
>> people told me that this gives noticeable audio desyncs depending if the
>> camera was warm or cold. We'll face endless fun with such things :).
Yes, can confirm that. Both image and sound framerate can drift on consumer
cameras, which gives you endless headaches esp. when filming a musical event
with several such cameras....
>> I think some automation for frame/sample rate fine adjustment controling
>> some noise gate (extend/compact silent phases) or frame drop (or doubling)
>> might be a forseeable tool to correct that.
we could try to find a solution here; but I'm rather sceptical with regards to
getting sound automatically synched to the image. Maybe a semi-automatic tool
could work. But even a tool of the sort "pin this (mouse click in waveform)
sound elm. to that video frame and stretch sound if necessary" would be a great
help for this tedious task...
Hermann
RSS Feed