[Kdenlive-devel] Cutting List Specification Version 0.04

[Christian Berger]

Am Samstag, 16. November 2002 17:35 schrieben Sie:
> On Saturday 16 November 2002 05:11 pm, Christian Berger wrote:
> > I opose to the format of time unless there is a clear definition of
> > what is meant by frames.
> > Video (especially NTSC) doesn't have the same amount of frames per
> > second. I see no way of calculating time-differences in a HH:MM:SS:FF
> > format.
>
> Why? if you have integer fps (as in PAL/NTSC/anything) it's trivial.
> Convert to frame numbers, subtract, convert back to time format.

But NTSC doesn't have an integer fps. NTSC has 29.9something. This is 
already a serious problem at timecodes on normal video.
And look at _real_ video. You don't expect your camera or VCR to run at an 
accuracy of better than 1% do you? And 1% equals about one frame every 4 
seconds. Or half a minute at a 1 hour video.

> > Besides both formats are hard to parse as well as hard for humans to
> > read.
>
> I don't agree. As I said, I have not many different commercial editors,
> but the three I know all display time in hh:mm:ss.ff, where ff is max 30
> for NTSC and max 25 for PAL. Very easy to read for me. Any non-frame
> based format will severely suffer from rounding errors, like in the
> suggestion I made:
>
>  HH:MM:SS.mmm
>
> where .mmm are milliseconds. Together with fps of the sample it's
> possible to calculate the right frame, but not easy in NTSC.

Well but at NTSC we don't always have 30 frames per second, as far as I 
know they try to compensate that by either storing a wiered timecode with 
30 frame and 29 frame seconds as well as one with 30 frame long seconds 
(which don't correspond to real seconds)

BTW, try to calculate the timespan between
01:24:35:20 and
03:32:42:01 in your head

Besides without opening the files we could not even check their validy. Or 
imagines what happens when you have a draft edit on 10 fps files and later 
do the real edit on 25 fps files.

Or what is if you want to do slo-mo. Then you would maybe have to work 
with fields. What would you do? Say it's 23,5 frames?

> Anyway, I want to stress, that merging video with different framerates
> is not that simple. Already NTSC<->PAL is very difficult when done
> non-interlaced. It's nothing wrong about keeping this option in mind,
> but I would not waste too much time and energy on this topic at this
> point.

Well you also have to keep in mind that computer video editing is not 
always done with 25 fps or  30fps. Many people prefer 12,5 fps or 15 fps 
or other wiered framerates.

Besides, look into the future. With new codecs interpolating frames in a 
high quality might be trivial. Some codecs don't even have fixed 
framerates. Just think of realplayer's codecs. They only have a maximum 
framerate, but the actual framerate differs.

> Cheers,
> Rolf

Servus
  Casandro

> ***************************************************************
>  Rolf Dubitzky
>  e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
>  s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
> ***************************************************************
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel

-- 
Warning! (this is no commercial ad)
This e-mail probably will be read by secret services.
Therefore please get pgp or gnupg and send me 
your public key so we e-mail encryptedly.
http://www.gnupg.org/