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: bandwidth at sourceforge.net > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
