Re: [CinCV] help choosing a video camera compatible with gnu/linux
hello again i wrote some months ago asking about a camera but at the end at my work they didn't have money. now they have money and they ask to me to see if they are compatible with linux and cinelerra. they told to me about this two cameras: canon HFS21 canonHFM306 i have looked in internet but i dont find a site where you can get this kind of information. if there is one, please, tell to me? or any advice will be wellcome. thanks a lot :) On 11/11/2010 10:16 PM, candela wrote: hello i am using around 5 years cinelerra. thanks for your tutorials and list. and also for the program, of course :) i am not a profesional on video. i edit video one or two times a year. now, in my work, an immigrants ngo in barcelona, they want to buy a video camera for next week. i work there 10h/week among other works. they have not much money and they are in a hurry because x. they have choosen this model sony handycam hd-cx118 that cost 500€ but i dont know if it is compatible with gnu/linux -> cinelerra. i have search in internet but i there is not information. PLEASE, can you help us to know if it is compatible or not? another alternative? they want it to be usb because we work with young people and sometimes we dont have firewire on the computers that we use. THANKS A LOT, for any help :) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Hola Candela, If this camera has an HDMI output, you can capture the video using a blackmagic capture board using one of these softwares: http://smorgasbork.com/bmdcapture/ http://juba.tvlivre.org/bm_capture/ bye, rafael diniz Quoting candela : hello i am using around 5 years cinelerra. thanks for your tutorials and list. and also for the program, of course :) i am not a profesional on video. i edit video one or two times a year. now, in my work, an immigrants ngo in barcelona, they want to buy a video camera for next week. i work there 10h/week among other works. they have not much money and they are in a hurry because x. they have choosen this model sony handycam hd-cx118 that cost 500€ but i dont know if it is compatible with gnu/linux -> cinelerra. i have search in internet but i there is not information. PLEASE, can you help us to know if it is compatible or not? another alternative? they want it to be usb because we work with young people and sometimes we dont have firewire on the computers that we use. THANKS A LOT, for any help :) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
I now realize that my test was irrelevant and the result pointless.
* When I load the mpeg2 clip into cinelerra, render it as uncompressed YCbCr
4:2:0 (using yuv4mpegpipe), reload it into cinelerra and compare to the
original clip (setting "Overlay" mode of the track to "Subtract"), there's
absolutely no difference between original and rendered versions of the video.
* When I load the mpeg2 clip into avisynth (using DGDecode_MPEG2Source), render
it as uncompressed YCbCr 4:2:0 (using avs2yuv), reload it into avisynth and
compare to the original clip (with Subtract), there's absolutely no difference
between original and rendered versions of the video.
* Moreover, when I load the mpeg2 clip into avisynth, render it as uncompressed
YCbCr 4:2:0, load this (.y4m) file into cinelerra, render it again as
uncompressed YCbCr 4:2:0, then reload it into avisynth and compare with the
original, there's also no difference between original and twice-rendered
versions of the video.
avisynth -> .y4m -> cinelerra -> .yuv -> avisynth = exactly the same video
stream
(Hope that's understandable...)
What it means (I guess) :
1. The difference that appeared in my previous test only means that cinelerra
and avisynth/DGDecode decode mpeg2 in a slightly different way - the two file
loaders produce a slighlty different video stream from the same mpeg2 file.
2. Using "YUVA-8 Bit" or "YUV-8 Bit" as "Color model" in cinelerra definitely
avoids colorspace conversion when working with YCbCr video, and therefore allow
some kind of "lossless" editing inside the video editing workflow.
-> Good news :-)
- Mail Original -
De: "julien cynober"
À: cinelerra@skolelinux.no
Envoyé: Mardi 16 Novembre 2010 20h24:27 GMT +01:00 Amsterdam / Berlin / Berne /
Rome / Stockholm / Vienne
Objet: Re: [CinCV] help choosing a video camera compatible with gnu/linux
Thank you Monty for your clear and informative explanations !
De: "Monty Montgomery" :
>> Furthermore, am I right to think that colorspace conversion can be
>> avoided in cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as
>> Color model in the project parameters, when working with 8-bits
>> YCbCr footage ?
>
> No, unfortunately. You could minimize the loss by working in floating
> point intermediaries, but Cinelerra doesn't support them AFAIR. The
> chroma resampling aspects complicate it further (floating point won't
> save you there).
You're right - as usual.
I did a little test to know if I could avoid colorspace conversions, and if
not, how much loss it would induce.
My typical workflow for SD video editing is :
1. Load footage (mpeg2 from my camcorder, sometimes DV from another one) into
cinelerra using "YUVA 8-Bit" as color model ; edit video ; render it with
yuv4mpegpipe to uncompressed "YUV" 4:2:0 stream.
2. Load this uncompressed stream into avisynth (running under wine) with
RawSource() ; apply some nice postprocessing filters.
3. Pipe frames served by avisynth to an encoder (usually x264) with avs2yuv.exe.
I reproduced steps 1 and 2 of this workflow in my test :
1. Cinelerra load & render
1.1. Load mpeg2 footage into cinelerra ("YUVA 8-Bit" color model)
1.2. Render -> File format : YUV4MPEG Stream, Use Pipe : 'ffmpeg -i - -an
-vcodec rawvideo %'
2. Comparison with avisynth
2.1. Load original mpeg2 footage (with DGDecode plugin) as "src"
2.2. Load uncompressed "YUV" file rendered by cinelerra (with RawSource
plugin) as "rdr"
2.3. Create clip "a" containing the difference between src and rdr, using
Subtract()
2.4. Create clip "b" by increasing contrast of clip a difference to make it
blatantly obvious, using Levels()
2.5. Display a and b side-by-side + timecode information
(hours:minutes:seconds:frame)
Here's my avisynth script :
"""
src = DGDecode_MPEG2Source("D:\M2U00070.d2v")
rdr = RawSource("D:\render1.yuv",pixel_type="I420")
a = Subtract( src , rdr ).Subtitle("visible differences")
b = a.Levels(127, 1, 129, 0, 255).Subtitle("amplified differences")
StackHorizontal( a , b )
ShowSMPTE()
"""
Here's a still image (png) showing the output of this script :
http://img241.imageshack.us/img241/2590/000310.png
Only grey pixels can be considered identical between the two clips. The left
part of the screenshot is totally grey, with only very slight noise, meaning
differences are almost not noticeable. But when these differences are
(over)amplified, they become clearly visible on the right part of the picture.
Conclusion : there are very slight differences between original footage and
uncompressed "YUV" file rendered b
Re: [CinCV] help choosing a video camera compatible with gnu/linux
On 16/11/10 19:24, julien.cyno...@free.fr wrote: > Thank you Monty for your clear and informative explanations ! > You're right - as usual. > I did a little test to know if I could avoid colorspace conversions, and if > not, how much loss it would induce. I'm quite new to this, so in principle I wouldn't be very worried about the quality loss per conversion stage. However, it also happens that I'm a bit of a psycho with this kind of thing, so I've done some tests recently. Basically I loaded into Cinelerra the best quality encoding I had available and rendered it to YUV 4:2:0 planar. Then I re-encoded it to mpeg4 using the same quantisers. Visual comparison of the three clips revealed nothing initially. Rendering the same frames to pngs and comparing them with imagemagick did show clear differences after "stretching" the contrast. Once I learned what to look at I could spot the changes by flipping between frames quickly. My (obviously subjective) conclusion was that I can withstand two conversion steps quite happily for my own use case. Jose ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Thank you Monty for your clear and informative explanations !
De: "Monty Montgomery" :
>> Furthermore, am I right to think that colorspace conversion can be
>> avoided in cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as
>> Color model in the project parameters, when working with 8-bits
>> YCbCr footage ?
>
> No, unfortunately. You could minimize the loss by working in floating
> point intermediaries, but Cinelerra doesn't support them AFAIR. The
> chroma resampling aspects complicate it further (floating point won't
> save you there).
You're right - as usual.
I did a little test to know if I could avoid colorspace conversions, and if
not, how much loss it would induce.
My typical workflow for SD video editing is :
1. Load footage (mpeg2 from my camcorder, sometimes DV from another one) into
cinelerra using "YUVA 8-Bit" as color model ; edit video ; render it with
yuv4mpegpipe to uncompressed "YUV" 4:2:0 stream.
2. Load this uncompressed stream into avisynth (running under wine) with
RawSource() ; apply some nice postprocessing filters.
3. Pipe frames served by avisynth to an encoder (usually x264) with avs2yuv.exe.
I reproduced steps 1 and 2 of this workflow in my test :
1. Cinelerra load & render
1.1. Load mpeg2 footage into cinelerra ("YUVA 8-Bit" color model)
1.2. Render -> File format : YUV4MPEG Stream, Use Pipe : 'ffmpeg -i - -an
-vcodec rawvideo %'
2. Comparison with avisynth
2.1. Load original mpeg2 footage (with DGDecode plugin) as "src"
2.2. Load uncompressed "YUV" file rendered by cinelerra (with RawSource
plugin) as "rdr"
2.3. Create clip "a" containing the difference between src and rdr, using
Subtract()
2.4. Create clip "b" by increasing contrast of clip a difference to make it
blatantly obvious, using Levels()
2.5. Display a and b side-by-side + timecode information
(hours:minutes:seconds:frame)
Here's my avisynth script :
"""
src = DGDecode_MPEG2Source("D:\M2U00070.d2v")
rdr = RawSource("D:\render1.yuv",pixel_type="I420")
a = Subtract( src , rdr ).Subtitle("visible differences")
b = a.Levels(127, 1, 129, 0, 255).Subtitle("amplified differences")
StackHorizontal( a , b )
ShowSMPTE()
"""
Here's a still image (png) showing the output of this script :
http://img241.imageshack.us/img241/2590/000310.png
Only grey pixels can be considered identical between the two clips. The left
part of the screenshot is totally grey, with only very slight noise, meaning
differences are almost not noticeable. But when these differences are
(over)amplified, they become clearly visible on the right part of the picture.
Conclusion : there are very slight differences between original footage and
uncompressed "YUV" file rendered by cinelerra. Since these differences are
almost unnoticeable to the human eye, I think I won't change my workflow for
that :-)
-
De: "Monty Montgomery" :
> In the last vid I made, I had Cinelerra accidentally set to use RGB
> internally for editing. No compression involved. My source was HDV
> (a YUVish colorspace). I was rendering out to YUV4MPEG (which allows
> the same colorspace as HDV, so it should be zero conversion). The
> difference in output quality between the 'Use RGB for rendering',
> which caused Cinelerra to convert to 8-bit RGB and back, and 'Use YUV
> for rendering', which involved no conversion, was stark. I'd be happy
> to post an example if people care, though I'd have to load the raw
> video back off the USB drive and rerender.
I also noticed a visible color shift when I used RGB for editing and YUV4MPEG
for rendering.
-
De "Burkhard Plaum" :
> yuv420p has video range for luma and chroma. yuvj420p has full range
> (0..255). So the conversion simply maps the video range values to full
> range (e.g. with a loopup table).
It seems to me that yuv420p has full range (0-255) for luma and chroma. It can
be demonstrated with an histogram.
>> Furthermore, am I right to think that colorspace conversion can be
>> avoided in cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as Color
>> model in the project parameters, when working with 8-bits YCbCr
>> footage ?
>
> You save the conversion to RGB if you use these.
> But these colormodels are 4:4:4, so you'll upsample the chroma planes,
> which doubles the memory footprint of the video frames compared to 4:2:0.
You're right, but choosing another "Color model" (eg. "RGB 8-Bit" or "RGBA
8-Bit") would also at least double the memory footprint, so there's no way to
avoid it.
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Yes People this conversation is very interesting. I would like to know if is there any web site or book you know on this subject (transcodings and particularity of differents normes) which might make this knowledge more rich and stable or continious i might say. Because a very important point in my eyes. I've already learned and discovered a lot but still hungry to learn from the basements to the upstairs. I'll be interested in your exemple Monty. I shot also in HDV but edit on DV because of my old computer but that will change someday (I hope) Haldun Le 16/11/2010 08:58, Monty Montgomery a écrit : Huh? I would say that anything more than having a hardly noticeable difference in the noise level is either a bug in the transcoder or a painful (but sometimes necessary) reduction in the bit rate. The latter should result in chunks, blocks and noise, but changes in colors and brightness? Pixel shifts? Yes. The colorspace conversions themselves are not lossless, and you lose more with each conversion. You only have eight bits to start with... Example: pixel shifts. The different colorspaces do not put subsampled color pixels in the same places. EG, MPEG2 chroma is shifted one half pixel to the left compared to MJPEG/MPEG1/Theora. Either the transcoder has to account for this (and resampling the chroma plane to shift it will always introduce additional loss/aliasing) or just ignore the shift, and all your edges start picking up colored fringes (this is what Cinelerra does). I am fully aware of the YUV vs. YCbCr flavors issue, but transcoders should handle that gracefully. The terminology there is confused. 'YUV' by definition is analog, though it's often used as a generic term. 'YCbCr' is by definition digital. Most people just use YUV to refer to both, but when both appear in the same sentence... well, I'm not sure what you're trying to say. :-) Coversion between different YCbCr flavors is not and cannot be lossless. EG, the range of the MJPEG Y channel is 256 steps. The range of an MPEG-2 Y channel is only 218 steps (less than a full eight bits). If you convert from MJPEG to MPEG-2 colorspace, you either have to live with the fact that your Y steps are no longer evenly spaced, or add the additional noise of a dither to avoid banding. 'graceful' means different things depending on what you need. Will one conversion ruin a video? No, of course not (though the difference will be visible even on a cheap consumer display). Will 2? If you hit 4, just about anyone paying attention to vid quality is going to notice something is up even if they don't have an original to compare against. As for those 8-bit issues and extra noise that is added when moving from one lossy format to another All the conversions I'm talking about are lossy even when there's no lossy compression involved! They bite even if you never compress the video. I would say that as long as the target format is given a generous bitrate, there's no reason to get a significant difference when the target is MPEG-2 or MJPEG, possibly even with MPEG-4 derivatives (H.264 and DIVX). And when I say "significant" I compare with the original noise generated by the sensor or the camera's own coding. Which may be low with professional cameras used in good lighting conditions. On a good day. The loss involved in lossy compression steps is a completely different topic, and the results are also a little different. Even with a huge bitrate (say, 100Mbit), you're going to notice differences after just a few compression round trips, depending on codec; most codec bases lose energy (h.264 is a little different; it tends to *gain* HF energy, more like real film, at least with the popular encoders). Compress the same video over and over in the same encoder with the same settings and watch it decay. It's going to the 10x worse if it's going between different codecs each time, as they way each one fudges the numbers is completely different. The noise generated by a sensor is very different from the 'noise' introduced by codecs. In general, codecs lose random energy, they don't add it. Edges soften, grain gets lost, flat areas get lumpy or blocky, you start seeing basis noise (usually blocks or 'tweeds') and each format's loss characteristics are different. In the last vid I made, I had Cinelerra accidentally set to use RGB internally for editing. No compression involved. My source was HDV (a YUVish colorspace). I was rendering out to YUV4MPEG (which allows the same colorspace as HDV, so it should be zero conversion). The difference in output quality between the 'Use RGB for rendering', which caused Cinelerra to convert to 8-bit RGB and back, and 'Use YUV for rendering', which involved no conversion, was stark. I'd be happy to post an example if people care, though I'd have to load the raw video back off the USB drive and rerender. Monty ___ Cinele
Re: [CinCV] help choosing a video camera compatible with gnu/linux
> Huh? I would say that anything more than having a hardly noticeable > difference in the noise level is either a bug in the transcoder or a painful > (but sometimes necessary) reduction in the bit rate. The latter should > result in chunks, blocks and noise, but changes in colors and brightness? > Pixel shifts? Yes. The colorspace conversions themselves are not lossless, and you lose more with each conversion. You only have eight bits to start with... Example: pixel shifts. The different colorspaces do not put subsampled color pixels in the same places. EG, MPEG2 chroma is shifted one half pixel to the left compared to MJPEG/MPEG1/Theora. Either the transcoder has to account for this (and resampling the chroma plane to shift it will always introduce additional loss/aliasing) or just ignore the shift, and all your edges start picking up colored fringes (this is what Cinelerra does). > I am fully aware of the YUV vs. YCbCr flavors issue, but transcoders should > handle that gracefully. The terminology there is confused. 'YUV' by definition is analog, though it's often used as a generic term. 'YCbCr' is by definition digital. Most people just use YUV to refer to both, but when both appear in the same sentence... well, I'm not sure what you're trying to say. :-) Coversion between different YCbCr flavors is not and cannot be lossless. EG, the range of the MJPEG Y channel is 256 steps. The range of an MPEG-2 Y channel is only 218 steps (less than a full eight bits). If you convert from MJPEG to MPEG-2 colorspace, you either have to live with the fact that your Y steps are no longer evenly spaced, or add the additional noise of a dither to avoid banding. 'graceful' means different things depending on what you need. Will one conversion ruin a video? No, of course not (though the difference will be visible even on a cheap consumer display). Will 2? If you hit 4, just about anyone paying attention to vid quality is going to notice something is up even if they don't have an original to compare against. > As for those 8-bit issues and extra noise that is > added when moving from one lossy format to another All the conversions I'm talking about are lossy even when there's no lossy compression involved! They bite even if you never compress the video. > I would say that as long > as the target format is given a generous bitrate, there's no reason to get a > significant difference when the target is MPEG-2 or MJPEG, possibly even > with MPEG-4 derivatives (H.264 and DIVX). And when I say "significant" I > compare with the original noise generated by the sensor or the camera's own > coding. Which may be low with professional cameras used in good lighting > conditions. On a good day. The loss involved in lossy compression steps is a completely different topic, and the results are also a little different. Even with a huge bitrate (say, 100Mbit), you're going to notice differences after just a few compression round trips, depending on codec; most codec bases lose energy (h.264 is a little different; it tends to *gain* HF energy, more like real film, at least with the popular encoders). Compress the same video over and over in the same encoder with the same settings and watch it decay. It's going to the 10x worse if it's going between different codecs each time, as they way each one fudges the numbers is completely different. The noise generated by a sensor is very different from the 'noise' introduced by codecs. In general, codecs lose random energy, they don't add it. Edges soften, grain gets lost, flat areas get lumpy or blocky, you start seeing basis noise (usually blocks or 'tweeds') and each format's loss characteristics are different. In the last vid I made, I had Cinelerra accidentally set to use RGB internally for editing. No compression involved. My source was HDV (a YUVish colorspace). I was rendering out to YUV4MPEG (which allows the same colorspace as HDV, so it should be zero conversion). The difference in output quality between the 'Use RGB for rendering', which caused Cinelerra to convert to 8-bit RGB and back, and 'Use YUV for rendering', which involved no conversion, was stark. I'd be happy to post an example if people care, though I'd have to load the raw video back off the USB drive and rerender. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Monty Montgomery wrote: You allow your DSLR to choose automatically? I run every setting manual *period* :-) Unfortunately, my Canon 500D only has automatic mode, or one can freeze whatever it picked and see the values by pressing the ISO button in video mode. That's it. Which kind-of shows that the video mode was mostly intended for those who buy a DSLR but have no idea about exposure time and aperture. Given the typical video quality, I'm not surprised. But anyone who's noticed things like... "Why is it getting noisier each time I work on it? Why are the colors shifting? Why did it get fuzzier? Why are all the colors shifted left half a pixel? or a whole pixel? Why did it get washed out when i exported it? Why does it keep getting brighter (or darker) when I don't think I changed anything? Why is there all this color banding in the output? Why are the dark colors blocky/noisy?" and so one and so forth should start asking, because there are good answers. Huh? I would say that anything more than having a hardly noticeable difference in the noise level is either a bug in the transcoder or a painful (but sometimes necessary) reduction in the bit rate. The latter should result in chunks, blocks and noise, but changes in colors and brightness? Pixel shifts? I am fully aware of the YUV vs. YCbCr flavors issue, but transcoders should handle that gracefully. As for those 8-bit issues and extra noise that is added when moving from one lossy format to another, I would say that as long as the target format is given a generous bitrate, there's no reason to get a significant difference when the target is MPEG-2 or MJPEG, possibly even with MPEG-4 derivatives (H.264 and DIVX). And when I say "significant" I compare with the original noise generated by the sensor or the camera's own coding. Which may be low with professional cameras used in good lighting conditions. On a good day. Eli -- Web: http://www.billauer.co.il ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
On Mon, 2010-11-15 at 19:16 -0500, Monty Montgomery wrote: > There are plenty of people who've read this thread and don't know > anything about most of what we've talked about; they're thinking "but > it always looked ok I guess." These folks should probably continue > not to worry about it. > > But anyone who's noticed things like... > "Why is it getting noisier each time I work on it? Why are the colors > shifting? Why did it get fuzzier? Why are all the colors shifted > left half a pixel? or a whole pixel? Why did it get washed out when i > exported it? Why does it keep getting brighter (or darker) when I > don't think I changed anything? Why is there all this color banding in > the output? Why are the dark colors blocky/noisy?" and so one and so > forth should start asking, because there are good answers. > > ...and if you're doing any of this professionally and anything in this > thread made you say 'huh?' you definitely need to get a little pickier > about the details ASAP :-) The world has too many mediocre > 'professionals' already, and most of them will do a better job of > muddling through haphazardly in Final Cut or Premiere. > > Monty Monty, As always, thanks for the clear explanations and insights. Very much appreciated by the acolytes, of which I am one. scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
> But > how many of those who use DSLRs as their video source pay attention to the > automatically picked ISO level, which has a huge impact on the noisiness of > the image? (Well, I do.) You allow your DSLR to choose automatically? I run every setting manual *period* :-) > So I think that the bottom line is each one to his > (or her) own source quality, and even more important, destination quality. > If either isn't necessarily high, transcoding is no big deal, and makes life > easier. > > If the target is a video in Youtube, quality may not be such an issue. If > it's for national TV, that's a different story. Yes, that's a good take. There are plenty of people who've read this thread and don't know anything about most of what we've talked about; they're thinking "but it always looked ok I guess." These folks should probably continue not to worry about it. But anyone who's noticed things like... "Why is it getting noisier each time I work on it? Why are the colors shifting? Why did it get fuzzier? Why are all the colors shifted left half a pixel? or a whole pixel? Why did it get washed out when i exported it? Why does it keep getting brighter (or darker) when I don't think I changed anything? Why is there all this color banding in the output? Why are the dark colors blocky/noisy?" and so one and so forth should start asking, because there are good answers. ...and if you're doing any of this professionally and anything in this thread made you say 'huh?' you definitely need to get a little pickier about the details ASAP :-) The world has too many mediocre 'professionals' already, and most of them will do a better job of muddling through haphazardly in Final Cut or Premiere. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Monty Montgomery wrote: AFAIK mjpeg can handle different colorspaces, including YCbCr, so it seems to me that transcoding video (footage) to mjpeg doesn't necessarily imply colorspace conversion, or at least a "lossy" colorspace conversion (independently of the loss due to the codec itself). Almost any conversion between formats is going to take its toll. Depending on the transcoder and the involved formats, the level of impact varies. But how many of those who use DSLRs as their video source pay attention to the automatically picked ISO level, which has a huge impact on the noisiness of the image? (Well, I do.) So I think that the bottom line is each one to his (or her) own source quality, and even more important, destination quality. If either isn't necessarily high, transcoding is no big deal, and makes life easier. If the target is a video in Youtube, quality may not be such an issue. If it's for national TV, that's a different story. Eli -- Web: http://www.billauer.co.il
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Hi, Am 15.11.2010 14:03, schrieb julien.cyno...@free.fr: As an example, this is what I get when I transcode AVCHD to mjpeg with ffmpeg : $ ffmpeg -i 20100520101256.m2ts -an -vcodec mjpeg -b 24000k render.mov FFmpeg version SVN-r25679, Copyright (c) 2000-2010 the FFmpeg developers built on Nov 5 2010 09:22:10 with gcc 4.5.1 [... snip ...] Input #0, mpegts, from '20100520101256.m2ts': Duration: 00:00:11.46, start: 1.33, bitrate: 21952 kb/s Program 1 Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s Stream #0.2[0x1200]: Subtitle: pgssub [buffer @ 0xc53920] w:1920 h:1080 pixfmt:yuv420p [ffsink @ 0xc1a010] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 0xc1ddf0] w:1920 h:1080 fmt:yuv420p -> w:1920 h:1080 fmt:yuvj420p flags:0x4 Output #0, mov, to 'render.mov': Metadata: encoder : Lavf52.84.0 Stream #0.0: Video: mjpeg, yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 24000 kb/s, 50 tbn, 50 tbc Stream mapping: Stream #0.0 -> #0.0 [... snip ...] In this case, there's a colorspace conversion from 'yuv420p' to 'yuvj420p', but is it really "lossy" in itself since colorspace "family" and chroma subsampling are the same (YCbCr and 4:2:0 respectively) ? yuv420p has video range for luma and chroma. yuvj420p has full range (0..255). So the conversion simply maps the video range values to full range (e.g. with a loopup table). Furthermore, am I right to think that colorspace conversion can be avoided in cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as Color model in the project parameters, when working with 8-bits YCbCr footage ? You save the conversion to RGB if you use these. But these colormodels are 4:4:4, so you'll upsample the chroma planes, which doubles the memory footprint of the video frames compared to 4:2:0. Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
> AFAIK mjpeg can handle different colorspaces, including YCbCr, so it seems to > me that transcoding video (footage) to mjpeg doesn't necessarily imply > colorspace conversion, or at least a "lossy" colorspace conversion > (independently of the loss due to the codec itself). YCbCr is a family of colorspaces. MJPEG uses a different set of primary weightings, and a different scale range than most other video codecs. > In this case, there's a colorspace conversion from 'yuv420p' to 'yuvj420p', > but is it really "lossy" in itself since colorspace "family" and chroma > subsampling are the same (YCbCr and 4:2:0 respectively) ? Yes, it is lossy. The weights, the representation range and the chroma pixel sitings are all different between AVCHD and MJPEG. > Furthermore, am I right to think that colorspace conversion can be avoided in > cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as Color model in the > project parameters, when working with 8-bits YCbCr footage ? No, unfortunately. You could minimize the loss by working in floating point intermediaries, but Cinelerra doesn't support them AFAIR. The chroma resampling aspects complicate it further (floating point won't save you there). Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
De: "Monty Montgomery" : > > On Sat, Nov 13, 2010 at 8:36 AM, Eli Billauer wrote: >> The truth is that I don't understand why people are so uptight about having >> their original footage going directly into Cinelerra. I mean, it's nice that >> Cinelerra supports several video formats, but somehow I'm only really calm >> when I feed it with MJPEGs. Meaning, take the original video, convert it to >> MJPEG using ffmpeg or mencoder and then use that file with Cinelerra. > > The vast majority of digital video, uless you're a studio using > cameras that cost more than most cars, is 8 bit. 8 bit is not quite > enough dynamic resolution to avoid reasonably easy to see artifacts, > one reason that pro production people are so concerned with dither and > de-banding filters in production renders. > > The problem with MJPEG is that it uses a different color space than > all other video formats, and the conversion isn't lossless. Going > from any of the MPEG formats to MJPEG increases banding and > quantization noise, and it is noticable. Every conversion from one > format to another, even the uncompressed formats, is doing lossy > colorspace conversion. You lose a fraction of a bit (out of only > eight bits!) on every colorspace conversion. > > That doesn't even get into the fact that converting from lossy format > to lossy format is also adding quantization noise and losing detail > because each conversion is... well... lossy. There's no consumer > camera out there using a bitrate high enough to be completely > transparent as it is, and now conversion... plus conversion... plus > conversion... each genration is losing more and more. > > Oh, and Cinelerra's colorspace conversion code is also subtly wrong at > practically every step, so you're losing more than you would be > otherwise because of that too... > > Monty AFAIK mjpeg can handle different colorspaces, including YCbCr, so it seems to me that transcoding video (footage) to mjpeg doesn't necessarily imply colorspace conversion, or at least a "lossy" colorspace conversion (independently of the loss due to the codec itself). As an example, this is what I get when I transcode AVCHD to mjpeg with ffmpeg : $ ffmpeg -i 20100520101256.m2ts -an -vcodec mjpeg -b 24000k render.mov FFmpeg version SVN-r25679, Copyright (c) 2000-2010 the FFmpeg developers built on Nov 5 2010 09:22:10 with gcc 4.5.1 [... snip ...] Input #0, mpegts, from '20100520101256.m2ts': Duration: 00:00:11.46, start: 1.33, bitrate: 21952 kb/s Program 1 Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s Stream #0.2[0x1200]: Subtitle: pgssub [buffer @ 0xc53920] w:1920 h:1080 pixfmt:yuv420p [ffsink @ 0xc1a010] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 0xc1ddf0] w:1920 h:1080 fmt:yuv420p -> w:1920 h:1080 fmt:yuvj420p flags:0x4 Output #0, mov, to 'render.mov': Metadata: encoder : Lavf52.84.0 Stream #0.0: Video: mjpeg, yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 24000 kb/s, 50 tbn, 50 tbc Stream mapping: Stream #0.0 -> #0.0 [... snip ...] In this case, there's a colorspace conversion from 'yuv420p' to 'yuvj420p', but is it really "lossy" in itself since colorspace "family" and chroma subsampling are the same (YCbCr and 4:2:0 respectively) ? Furthermore, am I right to think that colorspace conversion can be avoided in cinelerra by choosing "YUV-8 Bit" or "YUVA-8 Bit" as Color model in the project parameters, when working with 8-bits YCbCr footage ? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
thanks to all that have shared your knowledge with us :) El 11/11/10 22:16, candela escribió: hello i am using around 5 years cinelerra. thanks for your tutorials and list. and also for the program, of course :) i am not a profesional on video. i edit video one or two times a year. now, in my work, an immigrants ngo in barcelona, they want to buy a video camera for next week. i work there 10h/week among other works. they have not much money and they are in a hurry because x. they have choosen this model sony handycam hd-cx118 that cost 500€ but i dont know if it is compatible with gnu/linux -> cinelerra. i have search in internet but i there is not information. PLEASE, can you help us to know if it is compatible or not? another alternative? they want it to be usb because we work with young people and sometimes we dont have firewire on the computers that we use. THANKS A LOT, for any help :) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
> I understand those points. But I have a further question. As you know, > I'm using Canon 5D footage. In order to get it into Cinelerra, I've > been converting the original H264 footage via a number of steps: With my SOWT patch, I can read in 7D files directly. I believe that patch will be included and 5D files should work too. On output, however, I can only successfully render to uncompressed RGB, and have a 2TB disk just for intermediate files. Mark ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
> So, I'm guessing the takeaways of your discussion are: > -if at all possible, avoid converting your videos to different formats > or try to keep the conversions to a minimum > -if you do convert, stay in the same colorspace as the original footage yup. or work in a floating point (non-8-bit) colorspace. > This strategy seems to yield decent quality material. But in your work > with Cinelerra, specifically: > 1) Given unlimited disk, would you recommend a different intermediate > format for higher quality, rather than the MPEG-PS? One trip to another format using a high enough bitrate is not an awful thing. Given that I've got enough fast storage, I use yuv4mpeg as an intermediate right now. > 2) Would your recommendation change if I had limited disk space to store > intermediates? What you're doing right now actually sounds like a good compromise. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
On Sun, 2010-11-14 at 20:01 -0500, Monty Montgomery wrote: > The problem with MJPEG is that it uses a different color space than > all other video formats, and the conversion isn't lossless. Going > from any of the MPEG formats to MJPEG increases banding and > quantization noise, and it is noticable. Every conversion from one > format to another, even the uncompressed formats, is doing lossy > colorspace conversion. You lose a fraction of a bit (out of only > eight bits!) on every colorspace conversion. > > That doesn't even get into the fact that converting from lossy format > to lossy format is also adding quantization noise and losing detail > because each conversion is... well... lossy. There's no consumer > camera out there using a bitrate high enough to be completely > transparent as it is, and now conversion... plus conversion... plus > conversion... each genration is losing more and more. > > Oh, and Cinelerra's colorspace conversion code is also subtly wrong at > practically every step, so you're losing more than you would be > otherwise because of that too... Monty, So, I'm guessing the takeaways of your discussion are: -if at all possible, avoid converting your videos to different formats or try to keep the conversions to a minimum -if you do convert, stay in the same colorspace as the original footage I understand those points. But I have a further question. As you know, I'm using Canon 5D footage. In order to get it into Cinelerra, I've been converting the original H264 footage via a number of steps: -ffmpeg yuv4mpegpipe through to an mpeg2video stream via mpeg2enc -render out audio via ffmpeg -mux the two streams with mplex into an MPEG-PS -import the PS into Cinelerra Monty and edit -final output will be rendered to various formats: -h264 via ffmpeg, two pass encode -hdv via a similar ffmpeg yuv4mpegipe/mpeg2enc render This strategy seems to yield decent quality material. But in your work with Cinelerra, specifically: 1) Given unlimited disk, would you recommend a different intermediate format for higher quality, rather than the MPEG-PS? 2) Would your recommendation change if I had limited disk space to store intermediates? scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
On Sat, Nov 13, 2010 at 8:36 AM, Eli Billauer wrote: > The truth is that I don't understand why people are so uptight about having > their original footage going directly into Cinelerra. I mean, it's nice that > Cinelerra supports several video formats, but somehow I'm only really calm > when I feed it with MJPEGs. Meaning, take the original video, convert it to > MJPEG using ffmpeg or mencoder and then use that file with Cinelerra. The vast majority of digital video, uless you're a studio using cameras that cost more than most cars, is 8 bit. 8 bit is not quite enough dynamic resolution to avoid reasonably easy to see artifacts, one reason that pro production people are so concerned with dither and de-banding filters in production renders. The problem with MJPEG is that it uses a different color space than all other video formats, and the conversion isn't lossless. Going from any of the MPEG formats to MJPEG increases banding and quantization noise, and it is noticable. Every conversion from one format to another, even the uncompressed formats, is doing lossy colorspace conversion. You lose a fraction of a bit (out of only eight bits!) on every colorspace conversion. That doesn't even get into the fact that converting from lossy format to lossy format is also adding quantization noise and losing detail because each conversion is... well... lossy. There's no consumer camera out there using a bitrate high enough to be completely transparent as it is, and now conversion... plus conversion... plus conversion... each genration is losing more and more. Oh, and Cinelerra's colorspace conversion code is also subtly wrong at practically every step, so you're losing more than you would be otherwise because of that too... Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
On 13/11/10 22:07, Raffaella Traniello wrote: On 13/11/10 13:22, blinge wrote: I would like to see a kind of ogg-video-camera in my life by the way. Have a look at the Elphel, the open source camera. http://www3.elphel.com ¡Fantastico! http://cinema.elphel.com/ http://www3.elphel.com/about_us "This freedom extends from the convenience of the out-of-the-box usage of the cameras with the intuitive GUI to the possibility to modify any parts of them." That sounds like a custom camera future... Very nice, thanks for the link. Ciao! Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
On 13/11/10 13:22, blinge wrote: I would like to see a kind of ogg-video-camera in my life by the way. Have a look at the Elphel, the open source camera. http://www3.elphel.com Ciao! Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
DV is well suited for SD video, and it's compression method is very similar to mjpeg's (intraframe compression using Discrete Cosine Transform) so there's no big difference in picture quality. File size should also be similar, depending on the audio track (DV uses uncompressed PCM audio). To edit HD video, nevertheless, I think DNxHD is preferable since it's less lossy than mjpeg (with the drawback of a bigger file size). It has been designed specifically for video editing and is well supported by cinelerra (and other free tools). - Mail Original - De: "Haldun ALTAN" À: cinelerra@skolelinux.no Envoyé: Samedi 13 Novembre 2010 14h56:34 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [CinCV] help choosing a video camera compatible with gnu/linux I always used .dv. What's the advantage of mjpeg ? Please ... Le 13/11/2010 14:36, Eli Billauer a écrit : > > The truth is that I don't understand why people are so uptight about > having their original footage going directly into Cinelerra. I mean, > it's nice that Cinelerra supports several video formats, but somehow > I'm only really calm when I feed it with MJPEGs. Meaning, take the > original video, convert it to MJPEG using ffmpeg or mencoder and then > use that file with Cinelerra. > > One of the huge problems with all video cameras is that even though > they claim supporting some video format, they are very likely to > produce a non compliant video stream as a result of some software > and/or hardware bugs. Or just because nobody cares. Since players are > keen on playing the video smoothly despite those errors in the stream, > these problems go away unnoticed, or maybe with some minor artifacts, > which most of us don't care about when watching the video for the > interest of its content. > > So what happens is that you get these artifacts in your rendered video > all of the sudden. And then what? > > Solution: Convert to MJPEG first, and check the converted video. Since > MJPEG is such a simple format, it's very unlikely that something a > video player showed correctly will break in Cinelerra. If it's OK, go > ahead editing it. If not, look for another video transcoder. It's that > simple. It's the long way to getting the work done quickly. > > So my suggesting is: Just buy the camera that fits your needs. > > Eli > ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
There is nothing wrong with DV or any other format. If it works well for you, there's no need to change anything in your practice. As a matter of fact, there's a slight degradation in quality when transcoding, so that's the advantage of working directly with the original format. But my experience is that adopting a new source of video tends to be a bumpy road. That's why I convert them all to a known-to-work format (MJPEG), and go on from there. Eli Haldun ALTAN wrote: I always used .dv. What's the advantage of mjpeg ? Please ... -- Web: http://www.billauer.co.il ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
I always used .dv. What's the advantage of mjpeg ? Please ... Le 13/11/2010 14:36, Eli Billauer a écrit : The truth is that I don't understand why people are so uptight about having their original footage going directly into Cinelerra. I mean, it's nice that Cinelerra supports several video formats, but somehow I'm only really calm when I feed it with MJPEGs. Meaning, take the original video, convert it to MJPEG using ffmpeg or mencoder and then use that file with Cinelerra. One of the huge problems with all video cameras is that even though they claim supporting some video format, they are very likely to produce a non compliant video stream as a result of some software and/or hardware bugs. Or just because nobody cares. Since players are keen on playing the video smoothly despite those errors in the stream, these problems go away unnoticed, or maybe with some minor artifacts, which most of us don't care about when watching the video for the interest of its content. So what happens is that you get these artifacts in your rendered video all of the sudden. And then what? Solution: Convert to MJPEG first, and check the converted video. Since MJPEG is such a simple format, it's very unlikely that something a video player showed correctly will break in Cinelerra. If it's OK, go ahead editing it. If not, look for another video transcoder. It's that simple. It's the long way to getting the work done quickly. So my suggesting is: Just buy the camera that fits your needs. Eli ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
The truth is that I don't understand why people are so uptight about having their original footage going directly into Cinelerra. I mean, it's nice that Cinelerra supports several video formats, but somehow I'm only really calm when I feed it with MJPEGs. Meaning, take the original video, convert it to MJPEG using ffmpeg or mencoder and then use that file with Cinelerra. One of the huge problems with all video cameras is that even though they claim supporting some video format, they are very likely to produce a non compliant video stream as a result of some software and/or hardware bugs. Or just because nobody cares. Since players are keen on playing the video smoothly despite those errors in the stream, these problems go away unnoticed, or maybe with some minor artifacts, which most of us don't care about when watching the video for the interest of its content. So what happens is that you get these artifacts in your rendered video all of the sudden. And then what? Solution: Convert to MJPEG first, and check the converted video. Since MJPEG is such a simple format, it's very unlikely that something a video player showed correctly will break in Cinelerra. If it's OK, go ahead editing it. If not, look for another video transcoder. It's that simple. It's the long way to getting the work done quickly. So my suggesting is: Just buy the camera that fits your needs. Eli -- Web: http://www.billauer.co.il ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
Thanks for the links. I would like to complete this thread by adding some questions: As we should know, nowadays all the video cameras in the market have its own properties and bugs/features. Its very pretty useful to think about which kind of image we want to get and due to that, what kind of specifications we would like to find in our next video camera. I use my mobile phone video camera to get some pieces of the unespected actions in the daily life in my city because i like to get the videos instantly and i like the bug/feature that my mobile phone camera does when the lights are changing quickly, as an effect than reinforces the concept of new cheap technologies in the city life. But another very important aspect for the election of a video camera, is to take in consideration which hardware and software combination we will manage during the edition of the files. For quick works and cheapest productions should be interesting to know which video camera gets the images in the quickest and better "cinelerreable" format. Are we able to work directly with "cinelerra" using the video formats that the modern handy cams record? mp4 is my mobile phone camera format and most of the cameras nowadays uses this 'standard'. Except that cameras that are giving us specific and unsupported or not 'standard formats'. I will choose that video camera format and Im mostly sure I would not use "cinelerra" for a quick edition or in an amateur or first-timer production, as imho "cinelerra" is a little more focused on more complex assemblies that require tons of video edition and heavy renders. I suggest such programs http://www.openshotvideo.com/ combined with mp4 'standards' And i suggest to take your computer to the camera shop and try if the camera format recorded is easily manipulable by it. I would like to see a kind of ogg-video-camera in my life by the way. Greetings. On 12/11/10 08:51, Asmo Koskinen wrote: 11.11.2010 23:16, candela kirjoitti: PLEASE, can you help us to know if it is compatible or not? Here is some kind of database for camcorders. http://www.kdenlive.org/video-editor Mine is this one: http://www.kdenlive.org/video-editor/canon-hfs100 Best Regards Asmo Koskinen. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] help choosing a video camera compatible with gnu/linux
11.11.2010 23:16, candela kirjoitti: PLEASE, can you help us to know if it is compatible or not? Here is some kind of database for camcorders. http://www.kdenlive.org/video-editor Mine is this one: http://www.kdenlive.org/video-editor/canon-hfs100 Best Regards Asmo Koskinen. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] help choosing a video camera compatible with gnu/linux
hello i am using around 5 years cinelerra. thanks for your tutorials and list. and also for the program, of course :) i am not a profesional on video. i edit video one or two times a year. now, in my work, an immigrants ngo in barcelona, they want to buy a video camera for next week. i work there 10h/week among other works. they have not much money and they are in a hurry because x. they have choosen this model sony handycam hd-cx118 that cost 500€ but i dont know if it is compatible with gnu/linux -> cinelerra. i have search in internet but i there is not information. PLEASE, can you help us to know if it is compatible or not? another alternative? they want it to be usb because we work with young people and sometimes we dont have firewire on the computers that we use. THANKS A LOT, for any help :) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
