Welcome to our community

Be a part of something great, join today!

  • 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! Baselight Transfer

I saw BLT demo at LA Red Camera meeting and came away very impressed with the package, it's capabilities and pricing. BUT, a big but... Now, that one will be able to combine the ScratchCine with Red Rocket on pretty much any PC with some fast RAID enclosure, wouldn't it be just about equal in it's capability to BLT, BUT at about half price? Or how about at about the same price as BLT, ScratchCine could be swapped for a standard Scratch and end up with much more capable finishing system? I know, that BLT will work with Red Rocked as well, but why would you want to, when you already have plenty of horsepower with 16 CPU cores? Until Red Rocket, BLT was super value, but now I wonder...
 
Lack of usable QT codecs

Lack of usable QT codecs

We use BLT for two months. It's very useful and reliable for 2K realtime R3D playback and for TIFF, DPX and MXF renders, but it suffers from a lack of QT codecs for rushes and for FCP offlines.

For rushes we prefer H.264, but it's not possible to manualy set bit-rate of this codec and automatic bit-rate is too low (for PAL only 0,2 mbps!) so the result is unusable. Render of quicktimes with this codec is also inconceivably slow (only about 10fps for PAL and low debayer - and all cores of CPU works at level about 20% only). Other low bit-rate codecs are unusable for us or result is inferior. Fast render with quality result offer uncompressed RGB or high bit-rate codecs (DV or DVCPRO50) only.

And also it would be very helpful for us to integrate Apple ProRes 422 codec into the system. I heard, that it can be solved by conecting of MacOS X machine to BaseLight cloud, but don't know any details...
 
Jan Zahradníček;428189 said:
We use BLT for two months. It's very useful and reliable for 2K realtime R3D playback and for TIFF, DPX and MXF renders, but it suffers from a lack of QT codecs for rushes and for FCP offlines.

For rushes we prefer H.264, but it's not possible to manualy set bit-rate of this codec and automatic bit-rate is too low (for PAL only 0,2 mbps!) so the result is unusable. Render of quicktimes with this codec is also inconceivably slow (only about 10fps for PAL and low debayer - and all cores of CPU works at level about 20% only). Other low bit-rate codecs are unusable for us or result is inferior. Fast render with quality result offer uncompressed RGB or high bit-rate codecs (DV or DVCPRO50) only.

And also it would be very helpful for us to integrate Apple ProRes 422 codec into the system. I heard, that it can be solved by conecting of MacOS X machine to BaseLight cloud, but don't know any details...
Shouldn't you be contacting FilmLight with all these questions and requests? I'm sure they will gladly help you out with the Mac set up. Yes, you will need it, if you want to create ProRes files, but it will have to be the Xserve. That's what FilmLight recommends.
 
Jan Zahradníček;428189 said:
And also it would be very helpful for us to integrate Apple ProRes 422 codec into the system. I heard, that it can be solved by conecting of MacOS X machine to BaseLight cloud, but don't know any details...

Not all codecs are available for each platform. Linux especially is problematic because QT is limited to a partial non-apple implementation. Using wine on linux presents other licensing issues.
 
Not all codecs are available for each platform. Linux especially is problematic because QT is limited to a partial non-apple implementation. Using wine on linux presents other licensing issues.

Yes. BLT Render call it QT, but in fact it is Libquicktime. I have no problem with playback of MOVs made by this library (neither on MacOS nor the PC), but ProRes is not on the list of supported codecs.
 
Jan Zahradníček;429216 said:
Yes. BLT Render call it QT, but in fact it is Libquicktime. I have no problem with playback of MOVs made by this library (neither on MacOS nor the PC), but ProRes is not on the list of supported codecs.

ProRes can be done ONLY on the computer running OS X. Period. That is why FilmLight MUST use Mac (Xserve) connected to BLT in order to do this. There is no way around that for strictly legal reasons.
 
ProRes can be done ONLY on the computer running OS X. Period. That is why FilmLight MUST use Mac (Xserve) connected to BLT in order to do this. There is no way around that for strictly legal reasons.

Jake, thank you for the explanation. And forgive my ineptitude ;-). But still not understand, if it is computing power of Mac or BLT, which creates QT with this codec. If Mac, it does not solve my intention - BLT has lot of power of its 16 cores/16GB RAM and harness these horses for ProRes render would be very useful for us...
 
Jan Zahradníček;429332 said:
Jake, thank you for the explanation. And forgive my ineptitude ;-). But still not understand, if it is computing power of Mac or BLT, which creates QT with this codec. If Mac, it does not solve my intention - BLT has lot of power of its 16 cores/16GB RAM and harness these horses for ProRes render would be very useful for us...

This has absolutely nothing to do with computing power. Apple has not released the codec for any platform other than its own OSX, with the sole exception being a decoding component (NOT an encoding component) for Windows. Since it is a proprietary codec, it is Apple's decision as to what platforms to support. And we know how Apple feels about that (at least most of us do...).
 
Jan Zahradníček;429332 said:
Jake, thank you for the explanation. And forgive my ineptitude ;-). But still not understand, if it is computing power of Mac or BLT, which creates QT with this codec. If Mac, it does not solve my intention - BLT has lot of power of its 16 cores/16GB RAM and harness these horses for ProRes render would be very useful for us...

My understanding, that is right now only CPUs are used for the debayer with GPU used for QT encoding. If I'm correct, than you shouldn't have to much of a performance hit, as all of the heavy lifting of debayer is still done with 16 cores of BLT. So, here is my understanding as how it's done with Xserve. First on the Xserve under Parallels you'll ned to install FilmLight OS (FLOS). Within the FLOS you'll need to install the renderer app. This app can reside on any computer running FLOS and it needs to be connected to the cloud. You'll have to sort out the renderer license with FilmLight. All then you have to do is to run remote render and the QT part is handled by OS X. That's basic idea, as I understand it.
 
RED Rocket in BLT?

RED Rocket in BLT?

What about RED Rocket card support in BLT for full debayering acceleration? Current full debayer of 4K 16:9 R3Ds is only around 1.5 fps on BLT...
 
Jan Zahradníček;451637 said:
What about RED Rocket™ card support in BLT for full debayering acceleration? Current full debayer of 4K 16:9 R3Ds is only around 1.5 fps on BLT...

According to Filmlight, they will support RedRocket, once SDK becomes aavailable.
 
Linux R3D SDK for RED Rocket?

Linux R3D SDK for RED Rocket?

According to Filmlight, they will support RedRocket, once SDK becomes aavailable.

We are very excited. But according to an interview with people from Filmlight at this year's IBC, SKD neccessary for RED Rocket™ support in BL Transfer is still not available.

This means that Linux R3D SDK v2.3 is not enough? When we can expect the publication of required SDK?
 
Back
Top