[Bf-committers] Problems with time in do_nla()

[Matthew Fulmer]

On Thu, Jan 05, 2006 at 02:56:27PM -0500, Stephen Swaney wrote:
> > Video (and audio) are fundamentally continuous, analog signals,
> > broadcast throughout the real world. 
> 
> For audio, this is true.  For video, the fundamental unit is the
> frame.  Yes, broadcast video is sent over an analog signal, but that
> is merely the carrier.  The information is essentially a packet
> whether delivered in parallel as a film frame or serially as broadcast
> scanlines. ( Let us ignore interlaced video since the fields are
> basically half-frames )

I was thinking not in terms of broadcast video, but of light
beams entering the eye from the surrounding world. Light waves
are continuous.

> > Thus, since we have access to the original video at every moment
> > in time (not just a finite set of frames), frames should be more
> > of an afterthought.
> 
> I am not so sure.  Our output devices are frame-based, and therefore
> bandwith limited.  Sampling at multiples of the Nyquist limit does not
> buy us much extra fidelity and increases the data rate greatly.  For
> some effects like motion blur, being able to interpolate between frames
> can be handy, but this is not the same as shifting into the analog domain.

Indeed, the frame rate of the output device is usually set in
stone and must be met if you are making a video for that medium.
The frame rate of any output device is usually sufficient to
make the Nyquist limit a non-issue, and the sampling of the eye
makes the point further moot. 

You made me think of another advantage that time based (not
frame based) animation might have: device independence.
Currently, the frame rate of the video is hardcoded (in some
form) in every action and ipo strip; changing the frame rate of
a video would involve either recalculating of every time in
every action or ipo, or somehow re-interpolating the video in
post-production (I don't know if this is done). I am thinking
that the timing of each action should be independent of what
frame rate you decide to render at, so that moving a video from
dvd frame rate to tv frame rate would just involve a re-render
(just like changing the motion blur or the resolution). 

I think that using time instead of frames is like using blender
units instead of pixels. I may be wrong. Thank you for your
feedback. 

-- 
Matthew Fulmer