Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Quicktime 7.4.5 - so far so good...

Brad Wilson

Brad Wilson

Active member
Joined
Apr 3, 2008
Messages
37
Reaction score
0
Points
0
Location
Culver City, CA
Website
www.keslowcamera.com
Running Quicktime proxies now on Tiger with the new QT 7.4.5 and its actually working! Anyone else having the same good luck?
 
Brooks spot on.. no 16:9 support yet, but it does fix some other bugs.
 
Running O.K. also.
Dose anyone know if we might see 16:9 support before the end of the month?
 
Brook Willard said:
I doubt it [prove me wrong...]. Apparently it requires an entire rewrite of the codec for some reason?
Click to expand...

Is it known what exact codec Red is using? I looked at an R3D file downloaded from JBeale's website and it has some headers similar to JPEG2000 headers (for e.g. OpenJPEG):

00000160 0d 0a 87 0a 00 00 00 14 66 74 79 70 6a 70 32 20 |........ftypjp2 |
00000170 00 00 00 00 6a 70 32 20 00 00 00 2d 6a 70 32 68 |....jp2 ...-jp2h|
00000180 00 00 00 16 69 68 64 72 00 00 04 80 00 00 08 00 |....ihdr........|
00000190 00 04 0b 07 00 00 00 00 00 0f 63 6f 6c 72 01 00 |..........colr..|
 
Red apparently wrote their own custom code, I presume for speed, and apparently they hardwired the Y = 2048 pixel limit (4k 2:1). Redcode image frames use the standard JPEG2k format as a container although they put some special sauce of their own into it as well. Several third parties have already reverse-engineered the format (at least to some extent), but Jim requested that they wait until the project is out of beta, so the alternative codec softwares are not currently being distributed.
 
thanks apple... kind of.

thanks apple... kind of.

i'm glad it works again on my 8 core mac pro running tiger. probably shouldn't have ever not worked, but oh well.
 
:detective2: I reckon the delay on the proxies working in 16:9 instead of 2:1 is a subtle way of making Univisium/2:1 catch on :wink: (apparently Jim's a big fan of the aspect ratio). A good example of this is a pop promo we shot recently in 4K 2:1 with 16:9 viewfinder markings - by the post stage the director had really fallen in love with the extra widescreen look of 2:1 and didn't want to crop it off to 16:9 (fortunately there were no nasty light stands or set edges to scupper us).

I don't know why but there's something kind of psychologically cinematic about seeing black bars top & bottom (probably comes from childhood days of watching letterboxed films on 4:3 tv's or even 2:35 films on 16:9 tv's). Obviously some people hate it, find it distracting and want the whole of their screens put to use! Horses for courses...
 
Brook Willard said:
I doubt it [prove me wrong...]. Apparently it requires an entire rewrite of the codec for some reason?
Click to expand...

It should just require an updated RED QT component... The current one is months old and I'm hoping a new one will come with NAB and build 16? :biggrin:

Anyway, QT 7.4.5 working fine here. My proxies play back smoother in the QT player, but still stutter a bit. Overall seems to work good. I think we can remove the warnings about not upgrading to QT 7.4.
 
Please, Please RED tell us when we can expect QT 16:9 support.

This is the one thing my clients can't get over.
 
Jeff Kilgroe said:
It should just require an updated RED QT component... The current one is months old and I'm hoping a new one will come with NAB and build 16? :biggrin:
Click to expand...

It'll have to, considering the pre-compression curve that I expect they'll have to put into the camera to keep the noise levels down. Camera makes the curve... QT makes it go away... it's invisible to the user and lowers noise without lowering detail [aka NR]! Everybody wins.
 
You must log in or register to reply here.
Back
Top