[Kdenlive-devel] Default title length

[John T. Mertz]

Oops wrong thread... Ignore my last mail...

On Wed, Mar 31, 2010 at 1:23 PM, John T. Mertz <thatonefilmguy at gmail.com> wrote:
> Hi Alberto,
>
> I tried your patch and it is not working for me either.  Then again
> that may or may not be a surprise since I do not see this behavior in
> Dolphin either, as you reported should work.
>
> Keep trying! :)
>
> Thanks,
> -JTM
>
> On Wed, Mar 31, 2010 at 9:21 AM, Alberto Villa <avilla at freebsd.org> wrote:
>> On Wednesday 31 March 2010 16:29:22 John T. Mertz wrote:
>>> On Wed, Mar 31, 2010 at 7:17 AM, Alberto Villa <avilla at freebsd.org> wrote:
>>> > imho - just imho, as a user - if i'm working with frames:
>>> > 1. i set N frames and i want them to be N forever. i don't want the
>>> > program to change them for me. if i want 2 seconds, i would work with
>>> > timecode 2. it's my responsibility to take care of this
>>> >
>>> > if something has to be done, i vote for adding a notice on profile
>>> > changing. there is already one if i remember correctly (that isn't
>>> > really a suggested operation): conditionally adding some text to that
>>> > one would be trivial
>>>
>>> You brought up a point which I hoped would be quietly swept under the rug
>>> :)
>>>
>>> I both agree and disagree with this.  Typically, I don't want
>>> something I set to change automagically.  In this case, however, I am
>>> curious whether the benefits of storing such a setting in a way that
>>> can be automatically adjusted for different frame rates outweighs the
>>> fact that the user would have to set the default setting again within
>>> the new project settings in order to achieve the desired results IF
>>> they care about the frame count more than the real time consumed by
>>> the default duration.  IMO, I think most users will be more concerned
>>> with the real time than the frame count when switching between project
>>> formats.
>>>
>>> Personally I think the benefits outweigh the negatives.  In the case
>>> of video, timecode and/or frame count is a count of time, relative to
>>> the time base of the video format.  50 frames in PAL has a longer
>>> duration, in real time, than 50 frames of NTSC video.
>>>
>>> If the 50 frames is stored in fractional seconds, then it will always
>>> be translated as 50 frames in PAL video, so in your typical working
>>> scenario, you will always have the 50 frame (2 second) duration that
>>> you want.  If you switch to 24P or 60i, then the duration will remain
>>> 2 seconds and the frame count will adjust accordingly.
>>>
>>> Generally speaking, I agree with you and if I am working in a single
>>> project frame rate, then I want my 50 frames of video to always be
>>> exactly 50 frames.  But when I look at the bigger picture, really what
>>> is more important to me is that in a PAL project my 50 frames be
>>> equivalent to 2 seconds of video.  If I switch to NTSC at 30 fps, then
>>> I have to go and change the setting to 60 frames to get the same
>>> duration as I had in my PAL project.  IMHO I would prefer my default
>>> value of 50 frames to equal 2 seconds in the PAL project, and to also
>>> equal 2 seconds in the NTSC project, even though the frame count will
>>> be different.
>>>
>>> Also, you can get in to trouble by just storing frames as the default
>>> duration.  For example, in its default configuration, kdenlive ships
>>> with a default duration of I believe 5 seconds for the default Title
>>> duration.  If this were stored in frames, then it would be 125 frames
>>> @ 25fps.  However, if the user (such as myself) normally edits in
>>> NTSC, then I will probably switch to a default project setting with 30
>>> or 60 fps video.  At 30fps, the default 125 frame duration becomes
>>> 4.17 seconds, and at 60fps it becomes a mere 2.08 seconds.  To the
>>> user, this will look like a bizarre default duration to have in a
>>> video application.
>>>
>>> If kdenlive stores either timecode OR frames, then it has to manage
>>> getting timecode for either type of value when the default setting is
>>> retrieved, which is easily doable but would perhaps make it more
>>> complicated than it is worth.
>>
>> you must forgive me. i don't know how, but i think i've replied with another
>> question in mind :S
>> what i wanted to say is: i think we should store timecodes
>> --
>> Alberto Villa, FreeBSD committer <avilla at FreeBSD.org>
>> http://people.FreeBSD.org/~avilla
>>
>>        SAFETY
>> I can live without
>> Someone I love
>> But not without
>> Someone I need.
>>
>