Welcome to our community

Be a part of something great, join today!

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

Red Render Farm

BASSAM MSSALATIE said:
thans for calculating this for me so
WHAT IS THE RELATION WITH LOCAL LAW HERE ?:sick:
is there is something agains law ?
Click to expand...

apples license forbid its user to use the licensed osx on non-apple manufactured pcs.

Restricting license use to that degree is ruled out by law in many nations, rendering apple license void in that part.

Other nations however allow softwarecompanies to have such strict licneses.
 
Joofa said:
OSX runs on Darwin, which is open source and freely available, thanks to Apple. I wonder if somebody has tried putting just Darwin and create render farms.
Click to expand...
Darwin is just a modification of 4.4BSD, the Berkeley Software Distribution Unix which is free. So are many commercial other OS, SunOS was also BSD basing iirc.
 
Actually that is an interesting idea, as REDline isn't reliant on any of the GUI layer of OS X, I might compile on straight Darwin core, or even Free/NetBSD, but as RED aren't providing source, only compiled code, it would likely to be difficult.

That said, it hopefully won't be too long until a Linux version comes out, shouldn't be a huge leap from the OS X one, although Linux lacks the QT support that OS X provides, so could be more difficult depending on the reliance on that, and whether the QT code available for Linux would be sufficient.

I think a Linux commandline tool will provide the most effective render farm option. Not to mention there are quite a few Linux multi-node farms available for rental jobs.
 
Not really worth the effort to compile just for darwin as is at the moment. There's alot of stuff that depends on mac libraries at the moment which is why we're rewriting much of it so it's more easily portable to other platforms and why it's taking time to do.

Once that's done, we'll have support first for win and then for linux as soon as we can do it.
 
Hey Deanan, does it rely on the Quicktime libs? Because I know that has hampered other apps being ported to Linux. There are three opensource QT libs for linux, but none it fully compatible with Apple's implementation.

If RED wants to implement REDCODE support for FFMpeg, I will... Um... I dunno, do something nice.
 
It doesn't need QT for Linux but that would also mean no QT support under linux. The downside to the linux QT libs is that some important things are missing like timecode tracks (or the were the last time I looked at them).

FFMpeg is a wildcard because it's LGPL and we'd have to look at what we'd need to do in detail from a legal standpoint.
 
Oh well, I wait with baited breath anyway... Whatever that means.

I wouldn't have thought LGPL licencing of FFMpeg would be a problem...

As for timecode in QT in Linux - there was talk on a dev list for one of the libs about adding support for writing TC tracks - still not clear on reading them though? Presumably that'd come along with the writing part...
 
Deanan said:
It doesn't need QT for Linux but that would also mean no QT support under linux. The downside to the linux QT libs is that some important things are missing like timecode tracks (or the were the last time I looked at them).

FFMpeg is a wildcard because it's LGPL and we'd have to look at what we'd need to do in detail from a legal standpoint.
Click to expand...

My understanding is that you can link with LGPL libraries dynamically without making your source code publicly available. However, static linking will force you to open your source code.

Timecode track may not be too difficult to put in on Linux -- its just 4 bytes in the "mdat" atom assuming that you have put in the track structure in the "moov" atom successfully.

Also, Timecode can be put in / removed / changed anytime very easily, at least on the Mac / Windows. Please Google QTTimeCode for that.
 
What are your plans for QT/red on linux?
(it helps for us understand what people want to use things for and
how to prioritize requests).
 
Putting in TC track is easy on mac win but then it means touching everything twice or doing it wine. Possible but then it starts to get cumbersome.

Adding the atom wont be too hard but that always snowballs into something much more complex.

If we have to change anything in ffmpeg then we start having problems with the license.
 
you talking to me?

sorry, was asking Dylan because I imagine he's looking for QT support on his backup device.
 
Deanan said:
Putting in TC track is easy on mac win but then it means touching everything twice or doing it wine. Possible but then it starts to get cumbersome.

Adding the atom wont be too hard but that always snowballs into something much more complex.

If we have to change anything in ffmpeg then we start having problems with the license.
Click to expand...

Trust me, you won't have a problem with the license, as long as you don't use the GPL parts of mostly LGPL ffmpeg, mplayer libraries, (and perhaps mpeg4ip project also). For e.g., please do not use libpostproc which is built with libavcodec and libavformat under the ffmpeg container, link *dynamically* and you are fine with the LGPL license.
 
One relatively significant undertaking you may have to do is the reference samples in QT files. I have never played around with your reference proxies, but I tend to believe that they are reference samples pointing to "mdat" atom data in separate files. As of my last playing around with ffmpeg libraries (libavcodec/libavformat) that was about some time ago, I did not see support for reference samples. But they might have it now.
 
Deanan,

In addition, libavcode/libavformat from ffmpeg container is the one of the fastest encoder set of tools I have seen. Much faster than Quicktime components in case you are using the QT components SDK on mac/windows to encode to Quicktime files. There are several reason Quicktime is slower, not all of them connected to bad coding.

For high-bit rate libavcodec rocks. I have heard that for MPEG encoding at low bit rates libmpeg is better. However, I would presume that you would go for higher bitrates.

One nasty thing about ffmpeg code is that its written quite horribly. The architecture is very nice, but codec implementation, though I can see they are aiming for optimized code and not beautiful code, is not easy reading.
 
Sycophant said:
Oh well, I wait with baited breath anyway... Whatever that means.
Click to expand...

You seem to have the linux side of things under control, so I thought I'd chime in on the linguistics side. It means "lessened" - but you've got to spell it "bated" in order for that to make intuitive sense. (Think "abate".)

Apparently, Shakespeare was the first to use it, in the Merchant of Venice - so even though I'm the one uselessly dumping linguistic pedantry into this thread, you arguably get points for appearing well-read. :biggrin:

Now if you can just explain this "rattle your dags" business, we'll be even.
 
Also, in case you are already not using it, its worth having a look at the Perian (aka the swiss army of everything Quicktime codecs) for mac / windows. They have an open source implementation of ffmpeg libraries for Quicktime components.
 
Deanan said:
you talking to me?

sorry, was asking Dylan because I imagine he's looking for QT support on his backup device.
Click to expand...

You talkin' to me? You must be talkin.. Ahh forget it, I can't do a DeNiro impression, even in text...

Yeah, immediately I have no plans for it really, it all depends on what comes out I guess.

The SolidStore is Linux based, so potentially we'd look at some further red support.

One thing I'd like is to be able to pull a thumbnail from each clip (this is already provided in P2 footage, and can be fairly easily extracted from XDCAM EX, which are the other two formats we're targeting (although in a later release).

The basic file copying functions are pretty similar obviously, so I'm keen to put whatever useful bits and pieces that I can on board.

As and when the tools allow, I'd also like to be able to generate useful metadata on the box (things like Avid ALE, REDCINE XML, Clip logs).

Down the line we'll also be introducing other products to assist these sorts of file-based workflows (for RED and other formats) so I'll be keeping my eyes open for options there.
 
You must log in or register to reply here.
Back
Top