Oops wrong thread... Ignore my last mail... On Wed, Mar 31, 2010 at 1:23 PM, John T. Mertz <thatonefilm...@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 <avi...@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 <avi...@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 <avi...@freebsd.org> >> http://people.FreeBSD.org/~avilla >> >> SAFETY >> I can live without >> Someone I love >> But not without >> Someone I need. >> >
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
