Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
2007/12/11, Herman Robak <[EMAIL PROTECTED]>: > Another re-think: Do we need a project framerate? > > The framerate is a property of the source material and the rendered > output. Does the render pipeline need a fixed internal framerate? This is possible, though not without drawbacks, I know because I've implemented that in Open Movie Editor. Implementation is easy, but you do not have "frame-accurate" editing theoretically, because by mixing different framerates, a specific frame could "end" somewhere in the middle between two frames of another framerate. But I am quite sure that it is possible to fix the corner cases, and come up with a editing model that does the "right" thing. Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Hi, Herman Robak schrieb: Another re-think: Do we need a project framerate? The framerate is a property of the source material and the rendered output. Does the render pipeline need a fixed internal framerate? I would say yes. Of course one can convert framerates "on the fly" (which is not trivial), but the results might not be, what the user wants. In some cases, one wants to repeat/drop pictures (resulting a photo slideshow for very low input framerates), in other cases, one wants to interpolate motion scenes (like in yuvmotionfps). Maybe an option would be to have a configurable fps converter, which is applied right before a video stream is composited with some other video stream, but this would require user interaction (and knowlegde). IMO, framerate, interlace mode and audio samplerate should be the same in the whole project, everything else will likely result in conversion overhead and/or user confusion. Colormodel, image size and audio channel configuration can (and should be allowed to) be different. If one wants to support different framerates, one should do it right and support non-constant framerates as well, since they can occur e.g. in YouTube downloads. Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Tue, 11 Dec 2007 04:57:48 +0100, IL'dar AKHmetgaleev <[EMAIL PROTECTED]> wrote: На Mon, 10 Dec 2007 17:43:20 +0100 "Herman Robak" <[EMAIL PROTECTED]> записано: Which leads me to another missing feature: "fit to (size)". If you choose a canvas size, say PAL, then using the camera/projector to resize HDV or Youtube clips to fit a 4:3 PAL frame is a bit of work. Especially if you want to preserve interlacing! Perhaps working with interlaced video as with video with doubled fps by splitting fields to frames will be easier. Especially when you have to join interlaced and progressive images in same project. And of course filters like blur will be much easier to implement. By smart re-framing with some optical flow algorithms will be possible to interlace/deinterlace video just by re-framing. Just before exporting or/and viewing such images might be converted back to interlaced by joining odd and even frames to fields. This workaround would be acceptable for standard definition video. For 1080i, however, the extra memory footprint and bandwidth would be significant. Another re-think: Do we need a project framerate? The framerate is a property of the source material and the rendered output. Does the render pipeline need a fixed internal framerate? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
На Mon, 10 Dec 2007 17:43:20 +0100 "Herman Robak" <[EMAIL PROTECTED]> записано: > Which leads me to another missing feature: "fit to (size)". If you > choose a canvas size, say PAL, then using the camera/projector to > resize HDV or Youtube clips to fit a 4:3 PAL frame is a bit of work. > Especially if you want to preserve interlacing! Perhaps working with interlaced video as with video with doubled fps by splitting fields to frames will be easier. Especially when you have to join interlaced and progressive images in same project. And of course filters like blur will be much easier to implement. By smart re-framing with some optical flow algorithms will be possible to interlace/deinterlace video just by re-framing. Just before exporting or/and viewing such images might be converted back to interlaced by joining odd and even frames to fields. -- Втр Дек 11 10:50:51 KRAT 2007 Tue Dec 11 03:50:51 UTC 2007 -- Visit my home page http://www.akhil.nm.ru (Last update at 3th Dec 13:52) -- jabber: [EMAIL PROTECTED] -- Позволь эмоциям быть твоей энергией на пути в бесконечность. Ахметгалеев Ильдар aka AkhIL -- Linux artstation 2.6.22-gentoo-r9 #6 PREEMPT Thu Nov 22 12:52:50 KRAT 2007 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux up 3 days, 22:59, 12 users, load average: 0.64, 0.49, 0.44 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Herman Robak wrote: > On Mon, 10 Dec 2007 06:33:07 +0100, Christian Thaeter <[EMAIL PROTECTED]> > wrote: > >> Herman Robak wrote: > ... >>> I also think the default should be either PAL or NTSC, depending >>> on the user's locale. If you're in Europe, you're most likely >>> to deal with PAL, for example. >> >> I dont like too much automagic things. How about have a 'unconfigured' >> state where creating tracks/putting things to the timelime are greyed >> out (only add to resources when loading?) and one has to 'setup project' >> first (with a big reminder "Setup Project First!" in the statusbar). >> Thats common in a lot other applications. > > In my opinion, that's annoying. I want to do stuff, and I strongly > resent apps that tells me to answer their questionnaire first! > > But then again, why does Cinelerra have to have a "project resolution"? > How about having a canvas that is simply "fit to largest"? Of course, > the user should have the _option_ to set the canvas to some standard > size. Well for cin2 we have this project resolution thing, its probably not easy to plug out of the sourcecode. Thinking about cin3 we have this 'everything is a node in a graph' where nodes inputs and outputs will have very specific properties like size, color depth, aspect ratio and so on. Nodes which are incompatible can not be connected together, point! But cin3 can choose 'conversion-nodes' (scaling, letter|pillar boxing, framerate, YUV/RGB conversions, etc) and insert them automatically (or only on demand in HQ/PRO mode). A alpha channel is something special here since alpha is created by the application (unless we have some video codec which supports alpha) and more importantly, alpha is consumed by the aplication too since the renderpipe runs bottom up, we can pass a 'need for alpha' property up and only when alpha is needed AND present it will be passed around. Finally encoding will be done in graph nodes too, that is where you define framerate, resolution etc. for the output video, there is no global project setting. One could even have serveral encoder nodes at the end of a renderpipe (or even in the middle) for example encoding for DV, DVD, SVCD and Youtube in one rush. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007 15:15:31 +0100, Burkhard Plaum <[EMAIL PROTECTED]> wrote: IMO the colormodel settings of a project aren't necessary at all. Usually it's always possible for all elements of a pipeline to negotiate their colormodels, if the APIs are designed properly. If one want's to increase precision, one can insert a "Force colormodel" filter to make subsequent operations work in float RGBA instead of 32 bit RGBA. I would love to see the colour model go away from the basic project settings. If Cinelerra could use alpha "on demand", the performance would improve for projects that use it here and there, and as a bonus it would make Cinelerra easier to use! (no more "remember to use YUVA"!) Furthermore, there is no law, that all video data in all tracks must have the same colormodel all the time and thinking so prevents some fundamental optimizations (both speed and quality wise): E.g. if YUV 4:2:0 images are read from the source, processed by some simple Brightness/Saturation/Contrast filter and written to the rendered file (again in YUV 4:2:0), they don't have to be upsampled to 4:4:4 at all. Hear, hear! (then again, this sounds like Cin3 stuff...) -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007 18:09:23 +0100, Herman Robak <[EMAIL PROTECTED]>
wrote:
On Mon, 10 Dec 2007 17:51:44 +0100, Richard Spindler
<[EMAIL PROTECTED]> wrote:
2007/12/10, Herman Robak <[EMAIL PROTECTED]>:
Which leads me to another missing feature: "fit to (size)". If you
choose a canvas size, say PAL, then using the camera/projector to
resize HDV or Youtube clips to fit a 4:3 PAL frame is a bit of work.
"Fit to size" is not a trivial problem: Do you want to preserve aspect
ratios? then you need to know both input and output aspect. Then you
want to know whether to fit by adding blackborders on aspect mismatch,
or if you want to crop the image to fit.
Yes, I want to preserve aspect ratio. I was thinking of a global
setting for cropping versus padding. My suggestion would be padding
("letterboxing" and "pillarboxing") by default.
There's more to it than that. Some formats have a little "overscan"
while others don't. If I intermix footage that is "4:3 with 8 pixels
overscan" and 4:3 footage with no overscan, I'd most likeley want the
overscan cropped off, even though I chose "letterboxing" as the fit
strategy.
If you don't understand what I mean, read this to get an idea:
http://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml
So Cinelerra needs to know about overscan, and treat it the "usual"
way (cropping it off) by default.
--
Herman Robak
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007 17:51:44 +0100, Richard Spindler
<[EMAIL PROTECTED]> wrote:
2007/12/10, Herman Robak <[EMAIL PROTECTED]>:
Which leads me to another missing feature: "fit to (size)". If you
choose a canvas size, say PAL, then using the camera/projector to
resize HDV or Youtube clips to fit a 4:3 PAL frame is a bit of work.
"Fit to size" is not a trivial problem: Do you want to preserve aspect
ratios? then you need to know both input and output aspect. Then you
want to know whether to fit by adding blackborders on aspect mismatch,
or if you want to crop the image to fit.
Yes, I want to preserve aspect ratio. I was thinking of a global
setting for cropping versus padding. My suggestion would be padding
("letterboxing" and "pillarboxing") by default.
--
Herman Robak
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
2007/12/10, Herman Robak <[EMAIL PROTECTED]>: > Which leads me to another missing feature: "fit to (size)". If you > choose a canvas size, say PAL, then using the camera/projector to > resize HDV or Youtube clips to fit a 4:3 PAL frame is a bit of work. "Fit to size" is not a trivial problem: Do you want to preserve aspect ratios? then you need to know both input and output aspect. Then you want to know whether to fit by adding blackborders on aspect mismatch, or if you want to crop the image to fit. -Richard -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007 06:33:07 +0100, Christian Thaeter <[EMAIL PROTECTED]> wrote: Herman Robak wrote: ... I also think the default should be either PAL or NTSC, depending on the user's locale. If you're in Europe, you're most likely to deal with PAL, for example. I dont like too much automagic things. How about have a 'unconfigured' state where creating tracks/putting things to the timelime are greyed out (only add to resources when loading?) and one has to 'setup project' first (with a big reminder "Setup Project First!" in the statusbar). Thats common in a lot other applications. In my opinion, that's annoying. I want to do stuff, and I strongly resent apps that tells me to answer their questionnaire first! But then again, why does Cinelerra have to have a "project resolution"? How about having a canvas that is simply "fit to largest"? Of course, the user should have the _option_ to set the canvas to some standard size. Which leads me to another missing feature: "fit to (size)". If you choose a canvas size, say PAL, then using the camera/projector to resize HDV or Youtube clips to fit a 4:3 PAL frame is a bit of work. Especially if you want to preserve interlacing! Now imagine you want to re-render your PAL project as NTSC or 720p. You have to redo all your camera/projector tweaking manually again! Pretty tedious. You CAN do it, but it is a lot of extra work. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007 15:28:02 +0100, Stefan de Konink <[EMAIL PROTECTED]> wrote: On Mon, 10 Dec 2007, Gour wrote: On Mon, 10 Dec 2007 11:43:53 +0100 Stefan de Konink <[EMAIL PROTECTED]> wrote: > How will this *ever* solve the problems when 'compositing' or effects > are used. Both operations should be applied with prior knowledge to > optimize theirselves in quality. Some of the above problems can be 'solved' by providing better/more complete documentation/tutorials with the program itself, i.e. educating users. But how will this change the fact that an interlaced signal needs to be deinterlaced, (this may mean field-to-frames, interpolation, motion estimation...) effects applied and re interlaced? It won't! The task you just described is tedious to the skilled users and totally mysterious to the newbies. And yet it is quite well-defined, so the developers can understand what needs to be done. This is a good example of what Cinelerra should just DO, and do it RIGHT! Since many more Free Software users can write FAQs and tutorials than code, "educating the users" becomes a more common solution than making the software smarter. Ten years ago, I felt so empowered by having the knowledge in my brain instead of inside the software. I don't feel that way any longer. Knowing is somehow less cool than DOING. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007, Gour wrote: > On Mon, 10 Dec 2007 11:43:53 +0100 > Stefan de Konink <[EMAIL PROTECTED]> wrote: > > > How will this *ever* solve the problems when 'compositing' or effects > > are used. Both operations should be applied with prior knowledge to > > optimize theirselves in quality. > > Some of the above problems can be 'solved' by providing better/more complete > documentation/tutorials with > the program itself, i.e. educating users. But how will this change the fact that an interlaced signal needs to be deinterlaced, effects applied and re interlaced? Stefan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
On Mon, 10 Dec 2007 11:43:53 +0100 Stefan de Konink <[EMAIL PROTECTED]> wrote: > How will this *ever* solve the problems when 'compositing' or effects > are used. Both operations should be applied with prior knowledge to > optimize theirselves in quality. Some of the above problems can be 'solved' by providing better/more complete documentation/tutorials with the program itself, i.e. educating users. Sincerely, Gour ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Hi, Richard Spindler schrieb: 2007/12/10, Herman Robak <[EMAIL PROTECTED]>: YUV, YUVA, RGB, RGBA or floating point presision color format? My guess is that 90% of the users ought to use YUVA, so let that be the default. Is the difference in memory footprint between YUV and YUVA so big that it warrants a setting? I'm not sure. Two things: First, I think in most cases, convinience is more important than trying to save every possible tiny bit of memory. Second, RGBA is 32bit, RGB is 24bit. Most SSE and Fast vector operations in CPUs work on 32bit aligned data. My totally naive guess is that in certain cases, the 32bit alignment of Alpha-Enabled Data might be faster to process. But I won't claim that until properly benchmarked. ;-) Alignment is 128 bit for SSE IIRC. Theoretically YUVA is 33% larger than YUV, but it can well be, that YUV is stored in 32 bit words internally (wasting memory but speeding up processing). Another quesion are the numerical operations. If you have to process 4 channels instead of 3 things will get slowed down (at least in non-SIMD routines). The question of RGB vs YUV depends heavily on what you are doing. Some effects (especially the ones which change the color) work in faster in YUV, others in RGB. Then for some operations, you need an alpha channel, they fail if you don't have one. IMO the colormodel settings of a project aren't necessary at all. Usually it's always possible for all elements of a pipeline to negotiate their colormodels, if the APIs are designed properly. If one want's to increase precision, one can insert a "Force colormodel" filter to make subsequent operations work in float RGBA instead of 32 bit RGBA. Furthermore, there is no law, that all video data in all tracks must have the same colormodel all the time and thinking so prevents some fundamental optimizations (both speed and quality wise): E.g. if YUV 4:2:0 images are read from the source, processed by some simple Brightness/Saturation/Contrast filter and written to the rendered file (again in YUV 4:2:0), they don't have to be upsampled to 4:4:4 at all. Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
2007/12/10, Stefan de Konink <[EMAIL PROTECTED]>: > How will this *ever* solve the problems when 'compositing' or effects > are used. Both operations should be applied with prior knowledge to > optimize theirselves in quality. I am not saying that there will be a solution to all possible problems, but having an aid to finding the known solutions to the known problems is a start. Other then that, in an ideal world, the effect or composition engine/UI would have access to the data from the knowledgebase as well. Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Richard Spindler schreef: >> PAL, NTSC or anything else? Firstly, that should depend on what > > ---8<--- > >> Interlacing... That's so involved that it belongs in an essay >> of its own! Cinelerra must know more about interlacing, so >> that the users can get by without know anything about it. >> >> Aspect ratio. There is not really any setting in Cinelerra > > ---8<--- > > > So, Framesize, Interlacing and Pixel-Aspect are hard problems. In my > humble Opinion the only serious attempt to solve that problem in a > fashion that is at least somehow universial, is the following. How will this *ever* solve the problems when 'compositing' or effects are used. Both operations should be applied with prior knowledge to optimize theirselves in quality. Stefan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
2007/12/10, Herman Robak <[EMAIL PROTECTED]>: > YUV, YUVA, RGB, RGBA or floating point presision color format? > My guess is that 90% of the users ought to use YUVA, so let that > be the default. > Is the difference in memory footprint between YUV and YUVA so big > that it warrants a setting? I'm not sure. Two things: First, I think in most cases, convinience is more important than trying to save every possible tiny bit of memory. Second, RGBA is 32bit, RGB is 24bit. Most SSE and Fast vector operations in CPUs work on 32bit aligned data. My totally naive guess is that in certain cases, the 32bit alignment of Alpha-Enabled Data might be faster to process. But I won't claim that until properly benchmarked. ;-) > PAL, NTSC or anything else? Firstly, that should depend on what ---8<--- > Interlacing... That's so involved that it belongs in an essay > of its own! Cinelerra must know more about interlacing, so > that the users can get by without know anything about it. > > Aspect ratio. There is not really any setting in Cinelerra ---8<--- So, Framesize, Interlacing and Pixel-Aspect are hard problems. In my humble Opinion the only serious attempt to solve that problem in a fashion that is at least somehow universial, is the following. You need several tools, One Tool would be like the unix "file" utility. A tool that scans a video source and makes a good guess about what kind of Interlacing and Pixel-Aspect is being used. The Second Tool is some kind of machine readable Knowledge-Database, that is filled with rules and heuristics about common frame-sizes, their assorted pixel-aspects, and how and when and when certain formats are used, and how they should be converted to other formats when necessary. This information will likely be useful to the "Source-Analysis-Tool" as well, as mentioned in the paragraph above. Additionally the Knowledge Base should also be sprinkled with human readable information, Such as: "You are exporting a 24p file to 29.97i, a 3:2 Pulldown will be performed for conversion, for more information about that, click here...". Ideally the knowledge base should have information available for most of the common cases. In case there are conflicting rules, or two equally likely options, the database should have enough information available to ask the user the question whether he prefers A or B. Will this work? I think it will, take the debian installer for example, it is very good in asking "clever" human understandable questions, and it provides sensible options as answers. Try it one day, maybe you will understand what I mean. Surely some users might be overwhelmed in some situations, but if it works well, most cases should be covered, so the system could work without interaction. And there could be some option like a "tell me more" button, that will provide the user with detailed information about why a certain conversion algorithm was selected. In short, built an expert system that has all the current knowledge about video conversion compiled into the most usable form. Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Herman Robak wrote: > To the new readers here: There is a wiki page with a collection of > suggested usability enhancements for Cinelerra, here: > http://lab.dyne.org/cinelerra/Usability Wow, i didnt know about it :) > > One of my pet peeves is that users shouldn't be expected to care > about settings for which there is a 99% safe default. > > YUV, YUVA, RGB, RGBA or floating point presision color format? > My guess is that 90% of the users ought to use YUVA, so let that > be the default. > Is the difference in memory footprint between YUV and YUVA so big > that it warrants a setting? I'm not sure. should need 25% more memory and alpha is taken in account when mixing with all 3 other channels together. I am not sure but I won't wonder if there is a big performance hit sometimes. > PAL, NTSC or anything else? Firstly, that should depend on what > the user loads upon startup. If it's a PAL video, setting the > project resolution to PAL is a fairly safe bet, in my opinion. > If it's 1080i HDV, set the project to 1440x1080. > I also think the default should be either PAL or NTSC, depending > on the user's locale. If you're in Europe, you're most likely > to deal with PAL, for example. I dont like too much automagic things. How about have a 'unconfigured' state where creating tracks/putting things to the timelime are greyed out (only add to resources when loading?) and one has to 'setup project' first (with a big reminder "Setup Project First!" in the statusbar). Thats common in a lot other applications. Ymmv since this disables some functionality at start, but gives the user a hint about the needed preparations. Then 'Setup Project' may default to the a format choosen by loaded resources, locale. As I see on irc, editiong just pal/ntsc is not the most common case anymore, many people rather decide computer screencasts, youtube, etc. formats. > > Interlacing... That's so involved that it belongs in an essay > of its own! Cinelerra must know more about interlacing, so > that the users can get by without know anything about it. Ack, but maybe hardly doable for Cin2. > > Aspect ratio. There is not really any setting in Cinelerra > for that. There's a project setting labelled "aspect ratio", > but that's the _display_ aspect ratio. And it's _global_, > which is just wrong! Because the aspect ratio can differ > between sources, so if you mix sources (16:9 and 4:3, for > example) Cinelerra will not try to Do The Right Thing. > We may keep the global Aspect Ratio setting, but that would > only be a _render_ setting, i.e. "render to 16:9". A missing > setting/property is the "pixel ratio". If Cinelerra knew the > pixel ratio for every resource, it could calculate and perform > the appropriate stretching and cropping/padding, without user > intervention. > Pixel and aspect ratios are often not quite what we think > they are, as explained here: > http://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml ack2, as above Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
To the new readers here: There is a wiki page with a collection of suggested usability enhancements for Cinelerra, here: http://lab.dyne.org/cinelerra/Usability One of my pet peeves is that users shouldn't be expected to care about settings for which there is a 99% safe default. YUV, YUVA, RGB, RGBA or floating point presision color format? My guess is that 90% of the users ought to use YUVA, so let that be the default. Is the difference in memory footprint between YUV and YUVA so big that it warrants a setting? I'm not sure. PAL, NTSC or anything else? Firstly, that should depend on what the user loads upon startup. If it's a PAL video, setting the project resolution to PAL is a fairly safe bet, in my opinion. If it's 1080i HDV, set the project to 1440x1080. I also think the default should be either PAL or NTSC, depending on the user's locale. If you're in Europe, you're most likely to deal with PAL, for example. Interlacing... That's so involved that it belongs in an essay of its own! Cinelerra must know more about interlacing, so that the users can get by without know anything about it. Aspect ratio. There is not really any setting in Cinelerra for that. There's a project setting labelled "aspect ratio", but that's the _display_ aspect ratio. And it's _global_, which is just wrong! Because the aspect ratio can differ between sources, so if you mix sources (16:9 and 4:3, for example) Cinelerra will not try to Do The Right Thing. We may keep the global Aspect Ratio setting, but that would only be a _render_ setting, i.e. "render to 16:9". A missing setting/property is the "pixel ratio". If Cinelerra knew the pixel ratio for every resource, it could calculate and perform the appropriate stretching and cropping/padding, without user intervention. Pixel and aspect ratios are often not quite what we think they are, as explained here: http://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml This was quite a mouthful! There is more, but I think this chunk of suggestions will do for now. Any objections? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
