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 :)

new REDCINE-X feedback

edl import to redcine : problem

edl import to redcine : problem

Hi, how can I import save edl from my cs5 (windows) in redcine-x. please give me some detail.Thanks in advance
 
Anyone else having trouble applying a watermark in 351? I have an export preset for a watermarked jpeg which works in 348 but does not appear in 351....
 
Sorry if this is a stupid question: is there any type of noise reduction in RCX? I've had some noise patterns in low-light clouds.
 
There's some chroma denoising, but rather get Neatvideo for serious noise reduction.
 
Let me apologize in advance if this has already been addressed somewhere else on Reduser...didn't see it in this thread.

I've been working on a project that required long takes, so have been disabling camera-generated quicktime proxies, and generating those using RC-X. For the most part, easy to do and smooth sailing.

One particular scene did require somewhat more extensive futzing with the image, and in the end the DP and I felt that RedColor 2 and RedGamma 2 provided a much more pleasing image, so I wanted to generate proxies that reflected the best of this new color science development.

Unfortunately, my reference proxies show up as a green block (audio still intact)...is it safe to assume this is due to an outdated QT redcode plug-in? I tried re-installing the latest QT RC plug-in (4.2, I believe), but still the same result. Transcoding to prores works, however (though the transcoded quicktimes don't match what I see in RC-X, to my dismay...I'm guessing that's a result of the Apple Gamma problem, no?)...

Any updates for the quicktime redcode plug-in coming down the pike? I'd be happy to experiment with any betas you guys have up your sleeve, as I would love to be able to apply the best of these new color science developments to the reference proxies... Or better yet, any chance we'll see RC2 becoming an option at the camera level?

On a side note, I'm loving where RC-X is at, in terms of stability, usefulness, UI, etc. I just did a quick color pass on a short we shot a few months back, and I was so excited to have a pain-free experience importing an EDL from FCP and seeing the film in the timeline. Now if only the ProRes files I exported would look as lovely! Great progress, though, guys. Thank you for all you've continued to do on your customer's behalf.

Best,
Clint
 
Clint: yes, that is due to outdated QT codec. We're working on getting that out together with a Color plugin update, should be early next week.

The camera will also get RC2 and RG2, I don't have an ETA on that.
 
Many thanks for the update, Rob. Love the work you guys are doing to consistently make this camera better.

Cheers,
Clint

Psst...if you need anyone to look at beta stuff, I'm available...;)
 
RCX (build 351) doesn't export MXF with the burn-in TC without crashing. I've tried every single different way (including QT with TC burn-in, and without) and it works ok, but when as a MXF it crashes after just a few clips.
I'm getting quite frustrated as a burn-in timecode is ESSENTIAL to what I'm doing (3D).
Is this a known problem or is it just me?
 
Mark Farinha said:
RCX (build 351) doesn't export MXF with the burn-in TC without crashing. I've tried every single different way (including QT with TC burn-in, and without) and it works ok, but when as a MXF it crashes after just a few clips.
I'm getting quite frustrated as a burn-in timecode is ESSENTIAL to what I'm doing (3D).
Is this a known problem or is it just me?
Click to expand...

Can you send your logs to redcinex at red . com

We've done a number of recent improvements to MXF and 3D. We'll try to push a build out soon.
 
RC-X 356: no "watermark" burn-in

RC-X 356: no "watermark" burn-in

Using REDCINE-X build 356 64-bit on Mac OX 10.6.4 with current REDROCKET drivers / firmware. I'm able to export the clip currently in the viewer to a Quicktime movie with a "general" burn-in (reel name, timecode, etc.), but the "watermark" burn-in, where I can type in my own text, doesn't appear, whether used alone or in combination with the "general" burn-in.
 
RC-X build 356: export filenames may be truncated at periods

RC-X build 356: export filenames may be truncated at periods

In RC-X 356 64-bit on OS X, using an export preset that asks for a filename: if I supply a filename with a period in it, the name will be truncated at the final period if I do not specify the extension correctly.

Examples of what I type, and what gets written to disk:

thisisatest.mov -> thisisatest.mov (.mov left in place)
thisisatest -> thisisatest.mov (.mov correctly added)
this.is.a.test.mov -> this.is.a.test.mov (.mov left in place)
this.is.a.test -> this.is.a.mov (.test dropped and .mov added)

(Arguable whether this is a bug or a feature. I would argue it's a bug; on Mac I'm used to an exporter either leaving a name alone or adding an extension; I'm not used to having one remove an existing "extension" and add its own.)
 
Adam Wilt said:
Using REDCINE-X build 356 64-bit on Mac OX 10.6.4 with current REDROCKET drivers / firmware. I'm able to export the clip currently in the viewer to a Quicktime movie with a "general" burn-in (reel name, timecode, etc.), but the "watermark" burn-in, where I can type in my own text, doesn't appear, whether used alone or in combination with the "general" burn-in.
Click to expand...

Thanks. We recently fixed a bug that might be the same thing.
 
Adam Wilt said:
In RC-X 356 64-bit on OS X, using an export preset that asks for a filename: if I supply a filename with a period in it, the name will be truncated at the final period if I do not specify the extension correctly.

Examples of what I type, and what gets written to disk:

thisisatest.mov -> thisisatest.mov (.mov left in place)
thisisatest -> thisisatest.mov (.mov correctly added)
this.is.a.test.mov -> this.is.a.test.mov (.mov left in place)
this.is.a.test -> this.is.a.mov (.test dropped and .mov added)

(Arguable whether this is a bug or a feature. I would argue it's a bug; on Mac I'm used to an exporter either leaving a name alone or adding an extension; I'm not used to having one remove an existing "extension" and add its own.)
Click to expand...

looks like 3 features and 1 bug.
 
Adam,

Two bug fixes will be in the next release:
1. Fix for the this.is.a.test -> this.is.a.mov bug.
(Should be this.is.a.test -> this.is.a.test.mov)
2. Fix for watermarks not appearing at some font sizes.

Thanks for reporting these.
 
Is there any way I can increase the length of the "buffer bar" in RCX so it can play 1/4 or 1/2 res clips for longer durations? I have a 6-core i7-980X PC with a GTX 285 and 12GB of DDR3 1600 RAM. Are there any settings to change? Would a better CUDA card help?
 
Tom Lowe said:
Is there any way I can increase the length of the "buffer bar" in RCX so it can play 1/4 or 1/2 res clips for longer durations? I have a 6-core i7-980X PC with a GTX 285 and 12GB of DDR3 1600 RAM. Are there any settings to change? Would a better CUDA card help?
Click to expand...

Yeah, we're planning on adding a control for that so you can set how much ram you want RCX to use.
 
Deanan said:
Yeah, we're planning on adding a control for that so you can set how much ram you want RCX to use.
Click to expand...

I don't know if the current build is multithreaded, but one of the things I like about Tweak's RV software is the ability to tailor both the number of threads and the cache size to the particular machine being used. You end up settling on a number for both that allows the cache to be small enough that it's not using up a lot of resources, but enough threads that the playback never overruns the cache. It also allows for tailoring the position of the playhead to be anywhere in the cache range, a nice little feature. Of course, RedcineX is doing a lot more than simply playing RGB images, but if you're not familiar with RV you might want to take a look at it, if only to see how these things are implemented there. Makes it pretty effective on a wide range of hardware.
 
M Most said:
I don't know if the current build is multithreaded, but one of the things I like about Tweak's RV software is the ability to tailor both the number of threads and the cache size to the particular machine being used. You end up settling on a number for both that allows the cache to be small enough that it's not using up a lot of resources, but enough threads that the playback never overruns the cache. It also allows for tailoring the position of the playhead to be anywhere in the cache range, a nice little feature. Of course, RedcineX is doing a lot more than simply playing RGB images, but if you're not familiar with RV you might want to take a look at it, if only to see how these things are implemented there. Makes it pretty effective on a wide range of hardware.
Click to expand...

RV is pretty nice.

RCX is both multi threaded and multi-process because of stuff like quicktime was keeping us stuck with 32bit.
Now that the 64bit version is getting more mature, we can push the memory usage up. The cache system is fairly complex because of things it needs to balance between decoding, debayer, timeline, etc.
Tailoring the cache behind/ahead of the playhead should be possible. It's currently biased mostly forward.
 
You must log in or register to reply here.
Back
Top