From: Christian B. <ein...@do...> - 2002-05-05 15:57:03
|
Servus Well this is the first draft for the editing file: Syntax: real: normal real number with "." as a decimal point and no points or commas at the 1000 position param: -<paramname> <param> example: -startvalue 5 params: <param> <param...> example: -startvalue 1 -stopvalue 4 -wrtlpfmpf "HAllo" commands: (can only appear outside of scenes) <commandname> <params > example: open_input -name somefile -filename "file.avi" -speed 1.42 connection: <connectionname> <effect> <params> examples: 3 mosaik -input 2 2 read somefile scene_start <params> <connections> scene_stop Commands: open_input : Opens a file for input Params: -file : Internal name (no string) -filename : Filename of file on disk -speed : factor of speed 1=normal >1 faster <1 slower -start : start of file in milliseconds open_output : sets the file for output Params: -filename : filename -sizex : width of image in pixels -sizey : height of image in pixels -nativesize : yes=keep frames in size of possible no=scale all frames -type : type of file (avi, mov, mpg, etc) -fps : framerate -nativefps : yes=keep original framerate no=don't keep framerate -videocodec : type of codec -nativevideocodec : yes=keep native codec no=recompress all contents -soundrate : samplerate of sound -nativesoundrate : yes/no -soundformat : format of sound (8bit, 16bit, uLaw, etc) -nativesoundformat : yes/no seek : seek to a certain position -file : identifier of file opened -absolute : seek to absolute position in ms -relative : seek to relative position in ms Scene definition: scene_start : command to start a scene Params: -duration : duration of sceene -name : name of scene -based_on : name of scenes which this scene is based on (usefull for clusters) may apear multible times Several lines with connections. The output reads from connection 0. All connections (which may contain effects) are only called once per frame in an order which makes sense. Scenes also are usually executed in order, but might be executed in parallel. scene_stop (no params) Colors: #rrggbb (like in HTML) or #aarrggbb (like in HTML, but with added transparency) Connections: in : simply pipes the input Params: -file : identifier of file mosaik : simple mosaic effect Params: -input : number of connection to read from fade : simple crossfade Params: -input1 : connection from which to fade -input2 : connection to which to fade -start : start value of fading (0-1) -stop : stop value of fading (0-1) flatcolour : simple colour Params: -colour : colour value overlay : overlays 2 signals Params: -background : background connection -foreground : foreground connection title : generates title Params: -text : text to display -x : position x -y : position y -colour : colour -font : font -height : height Well that's it for a start |
From: Jason W. <jas...@bl...> - 2002-05-05 21:32:30
|
On Sunday 05 May 2002 4:56 pm, Christian Berger wrote: > Servus > > Well this is the first draft for the editing file: Cool, I wasn't expecting it this quick :-) Did you get better quickly, or have you been working at it in bed? :-) > Syntax: > > > real: > normal real number with "." as a decimal point and no points or commas > at the 1000 position > > param: > -<paramname> <param> > example: -startvalue 5 > > params: > <param> <param...> > example: -startvalue 1 -stopvalue 4 -wrtlpfmpf "HAllo" > > commands: (can only appear outside of scenes) > <commandname> <params > > example: open_input -name somefile -filename "file.avi" -speed 1.42 > > connection: > <connectionname> <effect> <params> > examples: 3 mosaik -input 2 > 2 read somefile > > scene_start <params> > <connections> > scene_stop > > > Commands: > open_input : Opens a file for input > Params: > -file : Internal name (no string) > -filename : Filename of file on disk > -speed : factor of speed 1=normal >1 faster <1 slower > -start : start of file in milliseconds > > open_output : sets the file for output > Params: > -filename : filename > -sizex : width of image in pixels > -sizey : height of image in pixels > -nativesize : yes=keep frames in size of possible > no=scale all frames > -type : type of file (avi, mov, mpg, etc) > -fps : framerate > -nativefps : yes=keep original framerate > no=don't keep framerate > -videocodec : type of codec > -nativevideocodec : yes=keep native codec > no=recompress all contents > -soundrate : samplerate of sound > -nativesoundrate : yes/no > -soundformat : format of sound (8bit, 16bit, uLaw, etc) > -nativesoundformat : yes/no I think that videocodec and soundcodec might be better off as seperate commands, which are then referenced by open_output. The reason for this is that different codecs will have different options. By seperating them out, we make the file a little cleaner. > > seek : seek to a certain position > -file : identifier of file opened > -absolute : seek to absolute position in ms > -relative : seek to relative position in ms Although obvious, a note should be made that only -absolute OR -relative can exist in a single seek command, or an error should be thrown. > > Scene definition: > scene_start : command to start a scene > Params: > -duration : duration of sceene > -name : name of scene > -based_on : name of scenes which this scene > is based on (usefull for clusters) > may apear multible times > > Several lines with connections. The output reads from connection 0. All > connections (which may contain effects) are only called once per frame > in an order which makes sense. Scenes also are usually executed in > order, but might be executed in parallel. Am I correct from this that only one output may exist at once? That's fine, but a line should be added saying that if an attempt is made to open a second output, then the command will fail and an error will be thrown. > scene_stop (no params) > > Colors: > #rrggbb (like in HTML) or > #aarrggbb (like in HTML, but with added transparency) I think this as good a place as any to mention this point : I think that any parameter which can be set between 0 and some maximum value should have that maximum value set to 1.0, and that scaling should occur within the cutter. This makes it easy to modify the resolution of the parameter at a later date, as well as simplfiying any scaling operations that may need to be performed on the value. If we take color as an example, if we are using 24 bit color, then we simply multiply the rgb values by 255 (or 256, can't remember) to get the correct value. If we now choose to move to 16 bit color, we simply multiply by the new relevant scaling value instead. Another important point is that if we are doing linear interpolation across these values, then we _need_ to work in floating point anyway to avoid rounding errors between scenes. I can explain this in detail if you don't understand why this is so, but it's a little lengthy so I'll refrain for the moment. Anyway, color is one such value that should be set from 0-1, including fade (as you have already set from 0-1 below), other transitions and any other effect with a "maximum" value. Because of all t his :-) I think color would be better represented as either : RGB( redvalue, greenvalue, bluevalue) RGBA( red, green, blue, alpha) ARBG( alpha, red, green, blue) -r redvalue, -g greenvalue, -b bluevalue -a alphavalue The top three are better ways of representing color, as they would allow us to represent color using other colorspaces, for instance HSV. > > Connections: > in : simply pipes the input > Params: > -file : identifier of file > > mosaik : simple mosaic effect > Params: > -input : number of connection to read from > > fade : simple crossfade > Params: > -input1 : connection from which to fade > -input2 : connection to which to fade > -start : start value of fading (0-1) > -stop : stop value of fading (0-1) > > flatcolour : simple colour > Params: > -colour : colour value > > overlay : overlays 2 signals > Params: > -background : background connection > -foreground : foreground connection > > title : generates title > Params: > -text : text to display > -x : position x > -y : position y > -colour : colour > -font : font > -height : height > > > Well that's it for a start BTW, once we've discussed this and agreed on everything, I'll add a documents section to the web page and put it there. Cheers, Jason -- Jason Wood I knew I needed a break when I tried to close konqueror by typing <Esc>:q! |
From: Christian B. <ein...@do...> - 2002-05-06 12:10:52
|
Jason Wood schrieb: > > On Sunday 05 May 2002 4:56 pm, Christian Berger wrote: > > Servus > > > > Well this is the first draft for the editing file: > > Cool, I wasn't expecting it this quick :-) Did you get better quickly, or have > you been working at it in bed? :-) No, I just felt decent for some time, today I've seen a doctor, I have problems with the blood circulation at the ears. She gave me pills and if It isn't any better by next week I should see her again. > > > Syntax: > > > > > > real: > > normal real number with "." as a decimal point and no points or commas > > at the 1000 position > > > > param: > > -<paramname> <param> > > example: -startvalue 5 > > > > params: > > <param> <param...> > > example: -startvalue 1 -stopvalue 4 -wrtlpfmpf "HAllo" > > > > commands: (can only appear outside of scenes) > > <commandname> <params > > > example: open_input -name somefile -filename "file.avi" -speed 1.42 > > > > connection: > > <connectionname> <effect> <params> > > examples: 3 mosaik -input 2 > > 2 read somefile > > > > scene_start <params> > > <connections> > > scene_stop > > > > > > Commands: > > open_input : Opens a file for input > > Params: > > -file : Internal name (no string) > > -filename : Filename of file on disk > > -speed : factor of speed 1=normal >1 faster <1 slower > > -start : start of file in milliseconds > > > > open_output : sets the file for output > > Params: > > -filename : filename > > -sizex : width of image in pixels > > -sizey : height of image in pixels > > -nativesize : yes=keep frames in size of possible > > no=scale all frames > > -type : type of file (avi, mov, mpg, etc) > > -fps : framerate > > -nativefps : yes=keep original framerate > > no=don't keep framerate > > -videocodec : type of codec > > -nativevideocodec : yes=keep native codec > > no=recompress all contents > > -soundrate : samplerate of sound > > -nativesoundrate : yes/no > > -soundformat : format of sound (8bit, 16bit, uLaw, etc) > > -nativesoundformat : yes/no > > I think that videocodec and soundcodec might be better off as seperate > commands, which are then referenced by open_output. The reason for this is > that different codecs will have different options. By seperating them out, we > make the file a little cleaner. I wouldn't do that, since I already need most options at the start of the encoding. > > > > seek : seek to a certain position > > -file : identifier of file opened > > -absolute : seek to absolute position in ms > > -relative : seek to relative position in ms > > Although obvious, a note should be made that only -absolute OR -relative can > exist in a single seek command, or an error should be thrown. Uhm, why? Why shouldn't I first seek abolutely and then relatively in one line? > > Scene definition: > > scene_start : command to start a scene > > Params: > > -duration : duration of sceene > > -name : name of scene > > -based_on : name of scenes which this scene > > is based on (usefull for clusters) > > may apear multible times > > > > Several lines with connections. The output reads from connection 0. All > > connections (which may contain effects) are only called once per frame > > in an order which makes sense. Scenes also are usually executed in > > order, but might be executed in parallel. > > Am I correct from this that only one output may exist at once? That's fine, > but a line should be added saying that if an attempt is made to open a second > output, then the command will fail and an error will be thrown. Well you cannot open outputs, the output of the scene is simply the output of line 0 > > scene_stop (no params) > > > > Colors: > > #rrggbb (like in HTML) or > > #aarrggbb (like in HTML, but with added transparency) > > I think this as good a place as any to mention this point : > > I think that any parameter which can be set between 0 and some maximum value > should have that maximum value set to 1.0, and that scaling should occur > within the cutter. This makes it easy to modify the resolution of the > parameter at a later date, as well as simplfiying any scaling operations that > may need to be performed on the value. True > If we take color as an example, if we are using 24 bit color, then we simply > multiply the rgb values by 255 (or 256, can't remember) to get the correct > value. If we now choose to move to 16 bit color, we simply multiply by the > new relevant scaling value instead. > > Another important point is that if we are doing linear interpolation across > these values, then we _need_ to work in floating point anyway to avoid > rounding errors between scenes. I can explain this in detail if you don't > understand why this is so, but it's a little lengthy so I'll refrain for the > moment. No, I don't understand why we should use floating point (bleah), why aren't 32bit integers for each component enought? > Anyway, color is one such value that should be set from 0-1, including fade > (as you have already set from 0-1 below), other transitions and any other > effect with a "maximum" value. > > Because of all t his :-) I think color would be better represented as either : > > RGB( redvalue, greenvalue, bluevalue) > RGBA( red, green, blue, alpha) > ARBG( alpha, red, green, blue) > -r redvalue, -g greenvalue, -b bluevalue -a alphavalue > > The top three are better ways of representing color, as they would allow us to > represent color using other colorspaces, for instance HSV. How about RGB,0.4,0.1,0.4 ? This would be easier to parse. > > > > Connections: > > in : simply pipes the input > > Params: > > -file : identifier of file > > > > mosaik : simple mosaic effect > > Params: > > -input : number of connection to read from > > > > fade : simple crossfade > > Params: > > -input1 : connection from which to fade > > -input2 : connection to which to fade > > -start : start value of fading (0-1) > > -stop : stop value of fading (0-1) > > > > flatcolour : simple colour > > Params: > > -colour : colour value > > > > overlay : overlays 2 signals > > Params: > > -background : background connection > > -foreground : foreground connection > > > > title : generates title > > Params: > > -text : text to display > > -x : position x > > -y : position y > > -colour : colour > > -font : font > > -height : height > > > > > > Well that's it for a start > > BTW, once we've discussed this and agreed on everything, I'll add a documents > section to the web page and put it there. Good > Cheers, > Jason Servus Casandro > -- > Jason Wood > I knew I needed a break when I tried to close konqueror by typing <Esc>:q! > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |
From: Jason W. <jas...@bl...> - 2002-05-07 13:38:16
|
On Monday 06 May 2002 1:10 pm, Christian Berger wrote: > Jason Wood schrieb: > > On Sunday 05 May 2002 4:56 pm, Christian Berger wrote: > > > Servus > > > > > > Well this is the first draft for the editing file: > > > > Cool, I wasn't expecting it this quick :-) Did you get better quickly, or > > have you been working at it in bed? :-) > > No, I just felt decent for some time, today I've seen a doctor, I have > problems with the blood circulation at the ears. She gave me pills and > if It isn't any better by next week I should see her again. Get well soon. I have exams on Wednesday and Thursday, and will not have time to reply properly until afterwards. Bear with me! Cheers, Jason -- Jason Wood I knew I needed a break when I tried to close konqueror by typing <Esc>:q! |
From: Christian B. <ein...@do...> - 2002-05-07 19:02:03
|
Jason Wood schrieb: > > On Monday 06 May 2002 1:10 pm, Christian Berger wrote: > > Jason Wood schrieb: > > > On Sunday 05 May 2002 4:56 pm, Christian Berger wrote: > > > > Servus > > > > > > > > Well this is the first draft for the editing file: > > > > > > Cool, I wasn't expecting it this quick :-) Did you get better quickly, or > > > have you been working at it in bed? :-) > > > > No, I just felt decent for some time, today I've seen a doctor, I have > > problems with the blood circulation at the ears. She gave me pills and > > if It isn't any better by next week I should see her again. > > Get well soon. Thanks > I have exams on Wednesday and Thursday, and will not have time to reply > properly until afterwards. Bear with me! Ohh, we have a free day on Thursday :) Good luck with your exams. > Cheers, > > Jason Servus Casandro > -- > Jason Wood > I knew I needed a break when I tried to close konqueror by typing <Esc>:q! > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |
From: Jason W. <jas...@bl...> - 2002-05-10 19:36:48
|
On Monday 06 May 2002 1:10 pm, Christian Berger wrote: > Jason Wood schrieb: > > > open_output : sets the file for output > > > Params: > > > -filename : filename > > > -sizex : width of image in pixels > > > -sizey : height of image in pixels > > > -nativesize : yes=keep frames in size of possible > > > no=scale all frames > > > -type : type of file (avi, mov, mpg, etc) > > > -fps : framerate > > > -nativefps : yes=keep original framerate > > > no=don't keep framerate > > > -videocodec : type of codec > > > -nativevideocodec : yes=keep native codec > > > no=recompress all contents > > > -soundrate : samplerate of sound > > > -nativesoundrate : yes/no > > > -soundformat : format of sound (8bit, 16bit, uLaw, > > > etc) -nativesoundformat : yes/no > > > > I think that videocodec and soundcodec might be better off as seperate > > commands, which are then referenced by open_output. The reason for this > > is that different codecs will have different options. By seperating them > > out, we make the file a little cleaner. > > I wouldn't do that, since I already need most options at the start of > the encoding. How are you thinking of handling extra video codec options, such as e.g. compression, smoothing, etc. that might crop up in different codecs? > > > seek : seek to a certain position > > > -file : identifier of file opened > > > -absolute : seek to absolute position in ms > > > -relative : seek to relative position in ms > > > > Although obvious, a note should be made that only -absolute OR -relative > > can exist in a single seek command, or an error should be thrown. > > Uhm, why? Why shouldn't I first seek abolutely and then relatively in > one line? Well this file will normally be generated by a seperate program (which can calculate the relative offset itself), which makes the functionality a little redundant. Secondly, it might get confusing : if you have the command : seek -file 1 -relative +4:00 -absolute 2:00 Should that first move relative to the current position, and then move to the absolute position (effectively making the relative command redundant), or should it seek to the absolute location first, and then seek to the relative location (which makes sense, but is not expressed clearly by the line given. Finally, I can't see any particular reason why doing an absolute seek followed by a relative seek would be advantageous over a single absolute seek which does both. > > > Scene definition: > > > scene_start : command to start a scene > > > Params: > > > -duration : duration of sceene > > > -name : name of scene > > > -based_on : name of scenes which this scene > > > is based on (usefull for clusters) > > > may apear multible times > > > > > > Several lines with connections. The output reads from connection 0. > > > All connections (which may contain effects) are only called once per > > > frame in an order which makes sense. Scenes also are usually executed > > > in order, but might be executed in parallel. > > > > Am I correct from this that only one output may exist at once? That's > > fine, but a line should be added saying that if an attempt is made to > > open a second output, then the command will fail and an error will be > > thrown. > > Well you cannot open outputs, the output of the scene is simply the > output of line 0 What about the open_output command defined above? If you ever try and make a second conflicting open_output command it should return an error. > > > scene_stop (no params) > > > > > > Colors: > > > #rrggbb (like in HTML) or > > > #aarrggbb (like in HTML, but with added transparency) > > > > I think this as good a place as any to mention this point : > > > > I think that any parameter which can be set between 0 and some maximum > > value should have that maximum value set to 1.0, and that scaling should > > occur within the cutter. This makes it easy to modify the resolution of > > the parameter at a later date, as well as simplfiying any scaling > > operations that may need to be performed on the value. > > True > > Another important point is that if we are doing linear interpolation > > across these values, then we _need_ to work in floating point anyway to > > avoid rounding errors between scenes. I can explain this in detail if you > > don't understand why this is so, but it's a little lengthy so I'll > > refrain for the moment. > > No, I don't understand why we should use floating point (bleah), why > aren't 32bit integers for each component enought? Well, if we consider floats and 32bit integers to be of the same precision, then none, except that floats are easier to work with (to scale you simply multiply by whatever maximum value you eventually want, whilst with a 32 bit integer you would have to divide & multiply) The problem would be seen more if you picked values like e.g. 0-100 or something. If we are linearly interpolating from one value to another, and there are several scenes inbetween (like in the picture here : http://www.uchian.pwp.blueyonder.co.uk/roundingerror.jpg) then without using floating point we have to round to the nearest value at the beginning/end of each scene. This causes the interpolation (which should look like the purple line) to end up scewed like the red line, due to the rounding at the beginning/end of each scene. This causes small errors in how we render each frame (in this case, the two red dots, representing effect values are displayed instead of the blue dots representing the correct values. Of course, floating point itself will have some small precision errors due to rounding, but I haven't looked into them in any great detail :-) > > Anyway, color is one such value that should be set from 0-1, including > > fade (as you have already set from 0-1 below), other transitions and any > > other effect with a "maximum" value. > > > > Because of all t his :-) I think color would be better represented as > > either : > > > > RGB( redvalue, greenvalue, bluevalue) > > RGBA( red, green, blue, alpha) > > ARBG( alpha, red, green, blue) > > -r redvalue, -g greenvalue, -b bluevalue -a alphavalue > > > > The top three are better ways of representing color, as they would allow > > us to represent color using other colorspaces, for instance HSV. > > How about RGB,0.4,0.1,0.4 ? This would be easier to parse. I'm not sure it will be that much easier : to parse the RGB() one, you would do something like this : if(next piece of string is RGB) { while (next character is whitespace) move along a character if( character isn't a '(' ) return an error. read first value, until we reach a character which can't be parsed as part of a number. while(next character is whitespace) move along a character# if( character isn't a ',' ) return an error. // repeat the last three steps for each value, except for the last one, where we replace the test for a comman with a test for a closing bracket. repeat for next value. } Consider that whitespace test becomes a function call, reading a number becomes a function call, and the character tests are simple. Jason Wood I knew I needed a break when I tried to close konqueror by typing <Esc>:q! |
From: Christian B. <ein...@do...> - 2002-05-10 20:56:51
|
Jason Wood schrieb: > > On Monday 06 May 2002 1:10 pm, Christian Berger wrote: > > Jason Wood schrieb: > > > > open_output : sets the file for output > > > > Params: > > > > -filename : filename > > > > -sizex : width of image in pixels > > > > -sizey : height of image in pixels > > > > -nativesize : yes=keep frames in size of possible > > > > no=scale all frames > > > > -type : type of file (avi, mov, mpg, etc) > > > > -fps : framerate > > > > -nativefps : yes=keep original framerate > > > > no=don't keep framerate > > > > -videocodec : type of codec > > > > -nativevideocodec : yes=keep native codec > > > > no=recompress all contents > > > > -soundrate : samplerate of sound > > > > -nativesoundrate : yes/no > > > > -soundformat : format of sound (8bit, 16bit, uLaw, > > > > etc) -nativesoundformat : yes/no > > > > > > I think that videocodec and soundcodec might be better off as seperate > > > commands, which are then referenced by open_output. The reason for this > > > is that different codecs will have different options. By seperating them > > > out, we make the file a little cleaner. > > > > I wouldn't do that, since I already need most options at the start of > > the encoding. > > How are you thinking of handling extra video codec options, such as e.g. > compression, smoothing, etc. that might crop up in different codecs? Well most coceds already want that as a single string, so I'd do it as a single parameter. After all, when we open the output file we already have to have the values for all parameters, so we have to have it somewhere here > > > > seek : seek to a certain position > > > > -file : identifier of file opened > > > > -absolute : seek to absolute position in ms > > > > -relative : seek to relative position in ms > > > > > > Although obvious, a note should be made that only -absolute OR -relative > > > can exist in a single seek command, or an error should be thrown. > > > > Uhm, why? Why shouldn't I first seek abolutely and then relatively in > > one line? > > Well this file will normally be generated by a seperate program (which can > calculate the relative offset itself), which makes the functionality a little > redundant. Secondly, it might get confusing : if you have the command : > > seek -file 1 -relative +4:00 -absolute 2:00 > > Should that first move relative to the current position, and then move to the > absolute position (effectively making the relative command redundant), or > should it seek to the absolute location first, and then seek to the relative > location (which makes sense, but is not expressed clearly by the line given. It should first seek the relative position and then the absolute one, even if it seems redundant. But if order is important all things are evaluated left to right. We have the same problem here: 1 mosaik -size 4 -input -side 8 should the size be 4 or 8? It shurely should be 8 because that's the last value it's set to. > Finally, I can't see any particular reason why doing an absolute seek followed > by a relative seek would be advantageous over a single absolute seek which > does both. Imagine you have a rather simple cutting list generator. For example imagine a situation where you edit with tapes, all tapes have headers before their recordings. Now you not only want a normal edit, but one which contains all he raw material with the headers. You could then simply add a -relative -1000ms param after every seek command. The actual cutter however might optimize this somehow. > > > > Scene definition: > > > > scene_start : command to start a scene > > > > Params: > > > > -duration : duration of sceene > > > > -name : name of scene > > > > -based_on : name of scenes which this scene > > > > is based on (usefull for clusters) > > > > may apear multible times > > > > > > > > Several lines with connections. The output reads from connection 0. > > > > All connections (which may contain effects) are only called once per > > > > frame in an order which makes sense. Scenes also are usually executed > > > > in order, but might be executed in parallel. > > > > > > Am I correct from this that only one output may exist at once? That's > > > fine, but a line should be added saying that if an attempt is made to > > > open a second output, then the command will fail and an error will be > > > thrown. > > > > Well you cannot open outputs, the output of the scene is simply the > > output of line 0 > > What about the open_output command defined above? > > If you ever try and make a second conflicting open_output command it should > return an error. Well hmm, I think all the output of a sceene should get throught the sceene. So the only position where it may make sense to define the output is at scene level or higher. Since there can only be one output per scene it makes sense to use line #0 > > > > scene_stop (no params) > > > > > > > > Colors: > > > > #rrggbb (like in HTML) or > > > > #aarrggbb (like in HTML, but with added transparency) > > > > > > I think this as good a place as any to mention this point : > > > > > > I think that any parameter which can be set between 0 and some maximum > > > value should have that maximum value set to 1.0, and that scaling should > > > occur within the cutter. This makes it easy to modify the resolution of > > > the parameter at a later date, as well as simplfiying any scaling > > > operations that may need to be performed on the value. > > > > True > > > > Another important point is that if we are doing linear interpolation > > > across these values, then we _need_ to work in floating point anyway to > > > avoid rounding errors between scenes. I can explain this in detail if you > > > don't understand why this is so, but it's a little lengthy so I'll > > > refrain for the moment. > > > > No, I don't understand why we should use floating point (bleah), why > > aren't 32bit integers for each component enought? > > Well, if we consider floats and 32bit integers to be of the same precision, > then none, except that floats are easier to work with (to scale you simply > multiply by whatever maximum value you eventually want, whilst with a 32 bit > integer you would have to divide & multiply) Floats are _slow_ and only few processors support them properly. > The problem would be seen more if you picked values like e.g. 0-100 or > something. If we are linearly interpolating from one value to another, and > there are several scenes inbetween (like in the picture here : > http://www.uchian.pwp.blueyonder.co.uk/roundingerror.jpg) then without using > floating point we have to round to the nearest value at the beginning/end of > each scene. This causes the interpolation (which should look like the purple > line) to end up scewed like the red line, due to the rounding at the > beginning/end of each scene. This causes small errors in how we render each > frame (in this case, the two red dots, representing effect values are > displayed instead of the blue dots representing the correct values. I'm sorry, but that image seems to be corrupt > Of course, floating point itself will have some small precision errors due to > rounding, but I haven't looked into them in any great detail :-) Well I think integers would be sufficient. > > > Anyway, color is one such value that should be set from 0-1, including > > > fade (as you have already set from 0-1 below), other transitions and any > > > other effect with a "maximum" value. > > > > > > Because of all t his :-) I think color would be better represented as > > > either : > > > > > > RGB( redvalue, greenvalue, bluevalue) > > > RGBA( red, green, blue, alpha) > > > ARBG( alpha, red, green, blue) > > > -r redvalue, -g greenvalue, -b bluevalue -a alphavalue > > > > > > The top three are better ways of representing color, as they would allow > > > us to represent color using other colorspaces, for instance HSV. > > > > How about RGB,0.4,0.1,0.4 ? This would be easier to parse. > > I'm not sure it will be that much easier : to parse the RGB() one, you would > do something like this : > > if(next piece of string is RGB) { > while (next character is whitespace) move along a character > if( character isn't a '(' ) return an error. > > read first value, until we reach a character which can't be parsed as part of > a number. > while(next character is whitespace) move along a character# > if( character isn't a ',' ) return an error. > > // repeat the last three steps for each value, except for the last one, where > we replace the test for a comman with a test for a closing bracket. > > repeat for next value. > } > > Consider that whitespace test becomes a function call, reading a number > becomes a function call, and the character tests are simple. Well I think parameters shouldn't contain whitespaces, otherwise we don't know this is only a single parameter, since parameters are seperated by whitespace, too. However for texts we need Quotes for enclosing string, but this is general. > Jason Wood > I knew I needed a break when I tried to close konqueror by typing <Esc>:q! Servus Casandro > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |
From: Jason W. <jas...@bl...> - 2002-05-11 12:40:51
|
On Friday 10 May 2002 9:08 pm, Christian Berger wrote: > Jason Wood schrieb: > > How are you thinking of handling extra video codec options, such as e.g. > > compression, smoothing, etc. that might crop up in different codecs? > > Well most coceds already want that as a single string, so I'd do it as a > single parameter. After all, when we open the output file we already > have to have the values for all parameters, so we have to have it > somewhere here Fair enough. > > > > > > seek : seek to a certain position > > > > > -file : identifier of file opened > > > > > -absolute : seek to absolute position in ms > > > > > -relative : seek to relative position in ms > > > > > > > > Although obvious, a note should be made that only -absolute OR > > > > -relative can exist in a single seek command, or an error should be > > > > thrown. > > > > > > Uhm, why? Why shouldn't I first seek abolutely and then relatively in > > > one line? > > > > Well this file will normally be generated by a seperate program (which > > can calculate the relative offset itself), which makes the functionality > > a little redundant. Secondly, it might get confusing : if you have the > > command : > > > > seek -file 1 -relative +4:00 -absolute 2:00 > > > > Should that first move relative to the current position, and then move to > > the absolute position (effectively making the relative command > > redundant), or should it seek to the absolute location first, and then > > seek to the relative location (which makes sense, but is not expressed > > clearly by the line given. > > It should first seek the relative position and then the absolute one, > even if it seems redundant. But if order is important all things are > evaluated left to right. We have the same problem here: > > 1 mosaik -size 4 -input -side 8 > > should the size be 4 or 8? It shurely should be 8 because that's the > last value it's set to. Surely it should give an error - too many parameters :-) Or at least a warning "parameter hidden by second parameter", but if this was generated by a cutting list generator, then it is a bug in the generator (in which case sending an error from the cutter makes it easier to debug), and if it was hand crafted by a human... then again it has to be a bug. There is no reason why one parameter shold exist if it get's hidden straight away by another parameter, giving no access to the original. Order of parameters should not be important. > > Finally, I can't see any particular reason why doing an absolute seek > > followed by a relative seek would be advantageous over a single absolute > > seek which does both. > > Imagine you have a rather simple cutting list generator. For example > imagine a situation where you edit with tapes, all tapes have headers > before their recordings. Now you not only want a normal edit, but one > which contains all he raw material with the headers. You could then > simply add a -relative -1000ms param after every seek command. The > actual cutter however might optimize this somehow. If it is the cutting list generator creating the file, then it will still be able to handle this itself, and if we are considering using e.g. sed to modify the file in a script, then it wouldn't be any harder to add a second seek on a seperate line. As far as the cutter is concerned, it can still optimise this in exactly the same way. > > > > > Scene definition: > > > > > scene_start : command to start a scene > > > > > Params: > > > > > -duration : duration of sceene > > > > > -name : name of scene > > > > > -based_on : name of scenes which this scene > > > > > is based on (usefull for clusters) > > > > > may apear multible times > > > > > > > > > > Several lines with connections. The output reads from connection > > > > > 0. All connections (which may contain effects) are only called once > > > > > per frame in an order which makes sense. Scenes also are usually > > > > > executed in order, but might be executed in parallel. > > > > > > > > Am I correct from this that only one output may exist at once? That's > > > > fine, but a line should be added saying that if an attempt is made to > > > > open a second output, then the command will fail and an error will be > > > > thrown. > > > > > > Well you cannot open outputs, the output of the scene is simply the > > > output of line 0 > > > > What about the open_output command defined above? > > > > If you ever try and make a second conflicting open_output command it > > should return an error. > > Well hmm, I think all the output of a sceene should get throught the > scene. So the only position where it may make sense to define the > output is at scene level or higher. Since there can only be one output > per scene it makes sense to use line #0 I was talking about at higher than scene level - I mean, that between scenes you shouldn't be able to define more than one output at a time :-) If you can, then they would need to be given an ID, and each scene should recieve "Output ID" as a parameter so that it knows where to output it's stuff to. But I don't think that a cutting list should be able to send stuff to multiple outputs - for that you really should be using multiple cutting lists, so I think an error on attempting to open a second output makes sense. > > > > > scene_stop (no params) > > > > > > > > > > Colors: > > > > > #rrggbb (like in HTML) or > > > > > #aarrggbb (like in HTML, but with added transparency) > > > > > > > > I think this as good a place as any to mention this point : > > > > > > > > I think that any parameter which can be set between 0 and some > > > > maximum value should have that maximum value set to 1.0, and that > > > > scaling should occur within the cutter. This makes it easy to modify > > > > the resolution of the parameter at a later date, as well as > > > > simplfiying any scaling operations that may need to be performed on > > > > the value. > > > > > > True > > > > > > > Another important point is that if we are doing linear interpolation > > > > across these values, then we _need_ to work in floating point anyway > > > > to avoid rounding errors between scenes. I can explain this in detail > > > > if you don't understand why this is so, but it's a little lengthy so > > > > I'll refrain for the moment. > > > > > > No, I don't understand why we should use floating point (bleah), why > > > aren't 32bit integers for each component enought? > > > > Well, if we consider floats and 32bit integers to be of the same > > precision, then none, except that floats are easier to work with (to > > scale you simply multiply by whatever maximum value you eventually want, > > whilst with a 32 bit integer you would have to divide & multiply) > > Floats are _slow_ and only few processors support them properly. Remember that these float (or double) values don't need to be used internally to the cutter if it doesn't want to - in that case you only have to deal with floats at the beginning/end of each scene, it's not in any inner loops and optimisation of it is pointless. Consider also the problem for generating a cutting list which will be used on both 32 bit hardware and 64 bit hardware. Should we limit integer precision to 32 bit so that it works on both, or do we make seperate cutting lists to work on each? The first means that we are not making full use of the 64 bit processor, the second means that the cutting list is not cross-platform. With floating point, all numbers are between 0 & 1, so we never have to worrk about what MAX_INT happens to be on a specific system. As long as the cutting list generator makes the numbers as precise as necessary, (1024 bit floats? mmm!) then the cutter can just take them and use them as precisely as it can. > > > The problem would be seen more if you picked values like e.g. 0-100 or > > something. If we are linearly interpolating from one value to another, > > and there are several scenes inbetween (like in the picture here : > > http://www.uchian.pwp.blueyonder.co.uk/roundingerror.jpg) then without > > using floating point we have to round to the nearest value at the > > beginning/end of each scene. This causes the interpolation (which should > > look like the purple line) to end up scewed like the red line, due to the > > rounding at the beginning/end of each scene. This causes small errors in > > how we render each frame (in this case, the two red dots, representing > > effect values are displayed instead of the blue dots representing the > > correct values. > > I'm sorry, but that image seems to be corrupt Doh, works fine here & in gimp, but I've made a .png out of it here : http://www.uchian.pwp.blueyonder.co.uk/roundingerror.png It's 7 times the size, and I didn't keep the original image I made, so it's still got all the compression artifacts that jpg adds but hopefully you will have more luck with it. > > > Of course, floating point itself will have some small precision errors > > due to rounding, but I haven't looked into them in any great detail :-) > > Well I think integers would be sufficient. See above. You can still use integers internally to the cutter, but use floating point in the cutting list file. > > > > Anyway, color is one such value that should be set from 0-1, > > > > including fade (as you have already set from 0-1 below), other > > > > transitions and any other effect with a "maximum" value. > > > > > > > > Because of all t his :-) I think color would be better represented as > > > > either : > > > > > > > > RGB( redvalue, greenvalue, bluevalue) > > > > RGBA( red, green, blue, alpha) > > > > ARBG( alpha, red, green, blue) > > > > -r redvalue, -g greenvalue, -b bluevalue -a > > > > alphavalue > > > > > > > > The top three are better ways of representing color, as they would > > > > allow us to represent color using other colorspaces, for instance > > > > HSV. > > > > > > How about RGB,0.4,0.1,0.4 ? This would be easier to parse. > > > > I'm not sure it will be that much easier : to parse the RGB() one, you > > would do something like this : > > > > if(next piece of string is RGB) { > > while (next character is whitespace) move along a character > > if( character isn't a '(' ) return an error. > > > > read first value, until we reach a character which can't be > > parsed as part of a number. > > while(next character is whitespace) move along a character# > > if( character isn't a ',' ) return an error. > > > > // repeat the last three steps for each value, except for the > > last one, where we replace the test for a comman with a test for a > > closing bracket. > > > > repeat for next value. > > } > > > > Consider that whitespace test becomes a function call, reading a number > > becomes a function call, and the character tests are simple. > > Well I think parameters shouldn't contain whitespaces, otherwise we > don't know this is only a single parameter, since parameters are > seperated by whitespace, too. However for texts we need Quotes for > enclosing string, but this is general. Ok, forget the whitespace from above. Cheers, Jason -- Jason Wood I knew I needed a break when I tried to close konqueror by typing <Esc>:q! |
From: Christian B. <ein...@do...> - 2002-05-11 15:31:51
|
Jason Wood schrieb: > > On Friday 10 May 2002 9:08 pm, Christian Berger wrote: > > Jason Wood schrieb: > > > How are you thinking of handling extra video codec options, such as e.g. > > > compression, smoothing, etc. that might crop up in different codecs? > > > > Well most coceds already want that as a single string, so I'd do it as a > > single parameter. After all, when we open the output file we already > > have to have the values for all parameters, so we have to have it > > somewhere here > > Fair enough. Good > > 1 mosaik -size 4 -input -side 8 > > > > should the size be 4 or 8? It shurely should be 8 because that's the > > last value it's set to. > > Surely it should give an error - too many parameters :-) Or how about "Parameter out of bounds (32)"? > Or at least a warning "parameter hidden by second parameter", but if this was > generated by a cutting list generator, then it is a bug in the generator (in > which case sending an error from the cutter makes it easier to debug), and if > it was hand crafted by a human... then again it has to be a bug. There is no > reason why one parameter shold exist if it get's hidden straight away by > another parameter, giving no access to the original. Yes, but some cheap gernerators might create such lists, but I think a warning or notice might be good. > Order of parameters should not be important. Well we might hit a situation where we might need it, but at the moment I cannot think of one. > > > Finally, I can't see any particular reason why doing an absolute seek > > > followed by a relative seek would be advantageous over a single absolute > > > seek which does both. > > > > Imagine you have a rather simple cutting list generator. For example > > imagine a situation where you edit with tapes, all tapes have headers > > before their recordings. Now you not only want a normal edit, but one > > which contains all he raw material with the headers. You could then > > simply add a -relative -1000ms param after every seek command. The > > actual cutter however might optimize this somehow. > > If it is the cutting list generator creating the file, then it will still be > able to handle this itself, and if we are considering using e.g. sed to > modify the file in a script, then it wouldn't be any harder to add a second > seek on a seperate line. As far as the cutter is concerned, it can still > optimise this in exactly the same way. Well what if we have programms wanting to edit the "cutlist" directly? Then we might get into those situations. > > Well hmm, I think all the output of a sceene should get throught the > > scene. So the only position where it may make sense to define the > > output is at scene level or higher. Since there can only be one output > > per scene it makes sense to use line #0 > > I was talking about at higher than scene level - I mean, that between scenes > you shouldn't be able to define more than one output at a time :-) If you > can, then they would need to be given an ID, and each scene should recieve > "Output ID" as a parameter so that it knows where to output it's stuff to. > > But I don't think that a cutting list should be able to send stuff to multiple > outputs - for that you really should be using multiple cutting lists, so I > think an error on attempting to open a second output makes sense. Well we should have open_output and close_output commands. That way we can generate several files with one "cutlist". > > > > > > scene_stop (no params) > > > > > > > > > > > > Colors: > > > > > > #rrggbb (like in HTML) or > > > > > > #aarrggbb (like in HTML, but with added transparency) > > > > > > > > > > I think this as good a place as any to mention this point : > > > > > > > > > > I think that any parameter which can be set between 0 and some > > > > > maximum value should have that maximum value set to 1.0, and that > > > > > scaling should occur within the cutter. This makes it easy to modify > > > > > the resolution of the parameter at a later date, as well as > > > > > simplfiying any scaling operations that may need to be performed on > > > > > the value. > > > > > > > > True > > > > > > > > > Another important point is that if we are doing linear interpolation > > > > > across these values, then we _need_ to work in floating point anyway > > > > > to avoid rounding errors between scenes. I can explain this in detail > > > > > if you don't understand why this is so, but it's a little lengthy so > > > > > I'll refrain for the moment. > > > > > > > > No, I don't understand why we should use floating point (bleah), why > > > > aren't 32bit integers for each component enought? > > > > > > Well, if we consider floats and 32bit integers to be of the same > > > precision, then none, except that floats are easier to work with (to > > > scale you simply multiply by whatever maximum value you eventually want, > > > whilst with a 32 bit integer you would have to divide & multiply) > > > > Floats are _slow_ and only few processors support them properly. > > Remember that these float (or double) values don't need to be used internally > to the cutter if it doesn't want to - in that case you only have to deal with > floats at the beginning/end of each scene, it's not in any inner loops and > optimisation of it is pointless. Sure > Consider also the problem for generating a cutting list which will be used on > both 32 bit hardware and 64 bit hardware. Should we limit integer precision > to 32 bit so that it works on both, or do we make seperate cutting lists to > work on each? The first means that we are not making full use of the 64 bit > processor, the second means that the cutting list is not cross-platform. > > With floating point, all numbers are between 0 & 1, so we never have to worrk > about what MAX_INT happens to be on a specific system. As long as the cutting > list generator makes the numbers as precise as necessary, (1024 bit floats? > mmm!) then the cutter can just take them and use them as precisely as it can. All the exterman numbers should be between 0 and 1 (1 theoretically excluded, but still interpreted as brightest) > > > > > The problem would be seen more if you picked values like e.g. 0-100 or > > > something. If we are linearly interpolating from one value to another, > > > and there are several scenes inbetween (like in the picture here : > > > http://www.uchian.pwp.blueyonder.co.uk/roundingerror.jpg) then without > > > using floating point we have to round to the nearest value at the > > > beginning/end of each scene. This causes the interpolation (which should > > > look like the purple line) to end up scewed like the red line, due to the > > > rounding at the beginning/end of each scene. This causes small errors in > > > how we render each frame (in this case, the two red dots, representing > > > effect values are displayed instead of the blue dots representing the > > > correct values. > > > > I'm sorry, but that image seems to be corrupt > > Doh, works fine here & in gimp, but I've made a .png out of it here : > > http://www.uchian.pwp.blueyonder.co.uk/roundingerror.png > > It's 7 times the size, and I didn't keep the original image I made, so it's > still got all the compression artifacts that jpg adds but hopefully you will > have more luck with it. I think I know what you mean. > > > > > Of course, floating point itself will have some small precision errors > > > due to rounding, but I haven't looked into them in any great detail :-) > > > > Well I think integers would be sufficient. > > See above. You can still use integers internally to the cutter, but use > floating point in the cutting list file. Well we can use floatin point notation in the cutting list (my parser might read it out into integers then :) ) > > Well I think parameters shouldn't contain whitespaces, otherwise we > > don't know this is only a single parameter, since parameters are > > seperated by whitespace, too. However for texts we need Quotes for > > enclosing string, but this is general. > > Ok, forget the whitespace from above. OK, now somebody needs to make a new version of the file format, maybe it's your turn now :) > Cheers, > Jason Servus Casandro > -- > Jason Wood > I knew I needed a break when I tried to close konqueror by typing <Esc>:q! > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |