Worried about depending on RED codec
- Thread starter stokestack
- Start date
Fred Lumiere
RED team
D_and_G your post dissapeared for some reason.
You mentioned something about Avid's DNxHD. Here's a perfect example in my opinion as an opportunity for a third party company to develop a RED DNxHD Recording accessory.
You mentioned something about Avid's DNxHD. Here's a perfect example in my opinion as an opportunity for a third party company to develop a RED DNxHD Recording accessory.
Emanuel
Cross-Examiner
Following this post and this debate -- 'cause the relevance of the subject, I opened a new thread here:Fred Lumiere said:
http://www.dvxuser.com/V6/showthread.php?t=55688
...'cause to have a NLE solution now it can be very important to many of us that are thinking to invest in post equipment during the coming months -- (already) prepping in order to the RED purchase.
Can you help us? :dankk2: in advance!
ChrisForbes
Well-known member
What an awsome forum. Post a question and get not one but 2 members of the development team to answer you.
I agree that the codec doesnt matter as long as it works. The HDV codec is different from the JVC HDV codec which is different from the HVX200 codec which is different from. . . well you get the idea. I think not being constrained by existing technology is the entire basis of this revolution.
Viva la redvolution.
I agree that the codec doesnt matter as long as it works. The HDV codec is different from the JVC HDV codec which is different from the HVX200 codec which is different from. . . well you get the idea. I think not being constrained by existing technology is the entire basis of this revolution.
Viva la redvolution.
Graeme_Nattress
Red Team
Again, I don't see any reason why a small converter program would not be made available if it's necessary to conver the RED Code codec files to another codec, but I really don't think that's going to be necessary.
Graeme
Graeme
Stephen W
Well-known member
Graeme_Nattress said:
In order for REDCODE to work natively with FCP, would you need support/permission from Apple or could you just provide the codec as an add-on? I know you provide various filters etc. for FCP but I was wondering if Codecs worked the same way as other plug-ins.
Graeme_Nattress
Red Team
Any codec you write can be used in FCP without Apple's help, but you can get access to some of the FCP innards, like RT performance with Apple's help.
Graeme
Graeme
stokestack
Active member
What kind of codec?
What kind of codec?
So presumably you're planning a QuickTime version, but do you guys plan to have both QuickTime and Windows Media versions of the codec ready by the time of the camera's release? This would cover most, if not all, of the NLEs out there.
What kind of codec?
Graeme_Nattress said:
So presumably you're planning a QuickTime version, but do you guys plan to have both QuickTime and Windows Media versions of the codec ready by the time of the camera's release? This would cover most, if not all, of the NLEs out there.
Fred Lumiere
RED team
stokestack said:
Yes, the plan is to cover all the major NLEs
Frederic
toke lahti
Well-known member
Ever heard about super-white or super-black? Or set the zebras to 105%?Graeme_Nattress said:
Most at least prosumer videocameras can record 0-255 samples.
0-15 and 236-255 (Y) & 241-255 (Cb & Cr) are just outside analog broadcast safe colors.
Codec this is quite a tradeoff between lots of things.
If you use very modern and efficient compression, you need a lot of cpu power, which needs a lot of battery power and creates a lot of heat which leads to noisy cooling system.
Ever seen a face of camera operator who owns a cinealta and is asked to turn of the cooling while shooting? "Well this could break the camera, but okay..."
Those who would like to test how intesive it is to compress images to wavelet compression, try compressing a 11Mpx tiff to jpeg2000 in photoshop. 60 times per second with in-camera cpu sounds really hard...
Still there's tradeoff between luma resolution, chroma resolution, color depth and datarate (=storage time).
If it really is (I'm not so sure) like it has been commonly said that eye detects luma more accurately than chroma, then 4:2:0 is tempting choise if you'd have to choose between 4:4:4 & 10:1 compression ratio and 4:2:0 & 5:1 compression ratio.
RED will anyway use bayer chip so it really isn't 4:4:4 with the cmos original resolution anyway.
Best thing once again is to give the users the choise of their codec settings. I hope you can make a codec that you don't have to restrict color resolution, bit depth or compression ratio in the factory, but instead users can make their decisions in the field.
RAW 12bit is only 12 bits per pixel, 4:4:4 10bit is 30 bits per pixel.
Latter one needs processing in-camera and real-time, what's the benefit?
4:2:0 12 bit is still 18 bits per pixel, so maybe we should forget about these X:X:X modes and stick with RAW capturing and RAW compression...
Graeme_Nattress
Red Team
Well, even if a camera does superwhite and superblack, you're still stuck to the 1-254 range as 0 and 255 are reserved and not used for image data. I know most cameras will do super-white, but I've never seen any do superblack though. Still, it's the YCBCR component transform that does most of the damage...
J2k is a bad example to use when you talk about wavelets in general. J2k is not just wavlet, but has some pretty serious entropy encoding also, which is the slow part. The wavelet transform itself, is not particularly intensive or slow.
2K RGB is scaled down from full sensor, so really is full RGB 4:4:4 colour. And you'd get better results keeping it so, and adjusting the compression on the chroma-like components after a reversible component transform, rather than going to YCbCr and doing 4:2:2 or 4:2:0.
When the video is either full sensor or cropped, it's best to use a form of RAW compression rather than de-mosaicing in camera, as that will give you a 1/3 size head start. For scaled modes, they will be RGB by necessity.
Graeme
J2k is a bad example to use when you talk about wavelets in general. J2k is not just wavlet, but has some pretty serious entropy encoding also, which is the slow part. The wavelet transform itself, is not particularly intensive or slow.
2K RGB is scaled down from full sensor, so really is full RGB 4:4:4 colour. And you'd get better results keeping it so, and adjusting the compression on the chroma-like components after a reversible component transform, rather than going to YCbCr and doing 4:2:2 or 4:2:0.
When the video is either full sensor or cropped, it's best to use a form of RAW compression rather than de-mosaicing in camera, as that will give you a 1/3 size head start. For scaled modes, they will be RGB by necessity.
Graeme
Martin Hill
Active member
Will we be able to upgrade RED CODE ourselves? e.g. Plug a firewire cable into our computer + RED ONE, then upload the new firmware?
Is third-party development restricted in any way or is it open to any company/person?
Is third-party development restricted in any way or is it open to any company/person?
Fred Lumiere
RED team
_MR_ said:
Yes, makes sense.
Fred Lumiere
RED team
Martin Hill said:
Martin,
No details on how to upgrade REDCODE yet. We want to make it as easy and painless as possible.
No official word on third party development either but the idea is the more the merrier.
toke lahti
Well-known member
Graeme_Nattress said:
If I remember correctly some cameras have option to stretch black to levels 1-16 or "super-black".
Can you elaborate what damage YUV makes? Isn't the problem about color spaces? So if you keep a wide color space, there's actually no loss with RGB->YUV conversion?
I'm just thinking about cost effective ways to save storage space with low compression codec and 2k resolution.
If 4:2:0 with "natural images" (not green screen etc.) is as visually lossless compared to 4:4:4 as some visually lossless compression codecs, it could save 50% of storage space.
About wavelet, I thought that idea of using it was to benefit from efficiency of its entropy encoding, but without too heavy entropy (or completely without it) I guess it will be very good choise.
Anyway GVT uses j2k in Infinity, so with proper settings it is usable.
Btw, have RED team thought about using some "standard" codecs like AVC FRExt? "Standard" codec might have support from others so you wouldn't have to write everything from the scratch for every application and platform.
Waiting for apple/panny support for hvxE has made me dream about more widely used codecs than every camera has its own...
Graeme_Nattress
Red Team
YCbCr is such a much bigger colour space than RGB, that you find that only a small percentage of YCbCr values lead to legal (and / or unique) RGB values. So, if you remain in floating point, RGB <-> YCbCr <-> RGB is essentially lossless, but when you go to fixed precision 8bit or 10bit, you start to really loose on those conversions. Given that the sensor, the monitor and the eye are all RGB, it makes total sense to stay in RGB as much as possible, unless you're in a floating point compositing environment.
Given the data-rate of the Infinity J2k, I'd expect playback to take a lot of processor power, and they're maxing out at 30p or 60i - no where near the 60p 2k we're doing, never mind 4k.
You'll have to point me at a specific reference for AVC FRExt for me to comment, but the major issue with most codecs out there is lack of >8bit support, and not designed for editing.
Graeme
Given the data-rate of the Infinity J2k, I'd expect playback to take a lot of processor power, and they're maxing out at 30p or 60i - no where near the 60p 2k we're doing, never mind 4k.
You'll have to point me at a specific reference for AVC FRExt for me to comment, but the major issue with most codecs out there is lack of >8bit support, and not designed for editing.
Graeme
Fred Lumiere said:
now that is what i like to hear.
toke lahti
Well-known member
Graeme_Nattress said:
What rgb space are you referring? There's lots of them and others are wider than others.
I think the whole idea of using more color depth is to give possibility for conversions and finally still have 8-10bit colors. So it really doesn't matter if you loose one bit in component conversion and two in cc'ing, if you start with 12bits.
About FRExt:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
http://www.fastvdo.com/spie04/spie04-h264OverviewPaper.pdf