I have been using KDEnlive on Linux for years to edit video, but this week I was presented a new challenge that I can't seem to find a solution for.

I've been asked to edit a project and the footage came from a RED camera. I found this great article on offline editing: https://opensource.com/life/16/1/offlin ... g-kdenlive

However KDEnlive doesn't recognize the clips (*.r3d) so I am stuck at the "import video" stage.

I found a download for something called "REDline" on red.com which apparently is in Beta, but no documention on what it does, how to install it, no nothing.

Long story short: if anybody in the KDEnlive community has experience with working with RED footage or can direct me to online resources on how to convert the footage in Linux to something I can work with, that would be fantastic!

A quick search led me to this:
https://video.stackexchange.com/questio ... les-ffmpeg

Basically Kdenlive will work with anything that ffmpeg does:
https://www.ffmpeg.org/general.html

Yeah, the free RedCine X Pro utility mentioned in that first link Farid posted is really the tool you want to use for converting native Red .r3d files to video formats compatible with other NLE's, including ProRes and DNxHR - Cineform also if you have GoPro Studio installed:

https://www.red.com/downloads?category= ... ease=final

If and how it's possible to transcode the .r3d files with ffmpeg I'm not sure, but it's certainly not as straightforward as the command suggested in that link.

With all respect though, you might want to consider if KDenLive is really the right editing tool for the job. Don't get me wrong KDenLive is a quite capable editing software with a fairly comprehensive range of color correction and grading features, but it processes in 8-bit only, and to do justice to the high grade (super-resolution and high color depth) raw footage recorded on these professional cinematography cameras you really need to be editing and grading with software that has high bit depth support and 32-bit float processing.

Actually the RedCine X Pro software itself is quite a comprehensive editor and CC/grading suite. Otherwise maybe look at the free version of DaVinci Resolve (for Windows or Mac), which was designed to work with native footage from studio production cameras like these - Red, Arri and of course their own BlackMagic compact cinema cameras. If you want to look into that, I'd suggest going with Resolve 12.5.5 rather than the latest 14 beta update, at least until the official version of 14 is released. You could also use Resolve purely to convert the .r3d files to ProRes, DNxHR/HD, GrassValley HQX/HQ or Cineform for editing in KdenLive, if you so wish.

Incidentally, there is also a linux version of Resolve that was designed for Red Hat and CentOS specifically. I did manage to get the Resolve 12.5.5 and 14 beta (free) linux builds to install on Kubuntu 16.10. But there was no audio playback, H264 import/export was not supported and the program crashed attempting to import or render DNxHD/DNxHR or use the latter as the 'optimized media' (proxy) format. ProRes import was also not supported. Cineform (avi and mov) and Grass Valley HQ/HQX files were accepted, but neither can be encoded with ffmpeg (decode only) and Cineform export is not an option (requiring GoPro Studio). So as a 'dedicated linux system' you are basically left with Uncompressed 422 (8-bit or 10-bit) as the only workable exchange intermediate. I didn't think to check whether it imports native Red .r3d files. The lack of audio alone was a deal breaker for me.

Anyhow, just some suggestions.

Inapickle wrote: I didn't think to check whether it imports native Red .r3d files.

I don't know which Red camera your footage is from but I just tested a sample 4K/29.97 .r3d clip from a Red One (Mysterium) and Resolve 12.5.5 (which I still had installed on Kubuntu 16.10) imported it just fine. What's more I was able to transcode to Grass Valley (Canopus) HQX (using the built-in transcode function under Media Management) which is a high quality 'virtually lossless' 10-bit 422 'intermediate' format that KdenLive will import. So, potentially, there is a way of converting your .r3d footage 'within linux'.

If you want to have a go at installing the linux Resolve build, here's the procedure I used:

https://forum.blackmagicdesign.com/view ... 21&t=58668

And then the command here to fix the Resolve desktop launch icon:

https://www.thefanclub.co.za/how-to/how ... u-1604-lts

I'd be very interested to hear a bit more detail on this point. Does that mean that Kdenlive is not a good choice for any codec with greater colour depth than 8 bit?

Inapickle wrote:
With all respect though, you might want to consider if KDenLive is really the right editing tool for the job. Don't get me wrong KDenLive is a quite capable editing software with a fairly comprehensive range of color correction and grading features, but it processes in 8-bit only, and to do justice to the high grade (super-resolution and high color depth) raw footage recorded on these professional cinematography cameras you really need to be editing and grading with software that has high bit depth support and 32-bit float processing.

brodie wrote: Does that mean that Kdenlive is not a good choice for any codec with greater colour depth than 8 bit?

I wouldn't go so far as to say that. And that's a consideration that could be applied to most NLE's out there, at least at the 'consumer level'. Let's put it this way, if you were to be editing for broadcast distribution you would certainly want to be exporting (minumum) 10-bit and preserving high bit depth in the process. Yes, KDenLive can import some 10-bit native and/or compatible 10-bit intermediate formats (like ProRes and DNxHD-10bit) and export the latter. But the 10-bit input is going to get dithered down to 8-bit on import, which is what ffmpeg (and so MLT) does by default. And then on export that dithered 8-bit output is simply padded to 10-bit - ffmepg does not try to re-scale data, it just inserts 8-bit into 10-bit as is, with 2-bit padding. So you are not really gaining anything by it.

That said, if the intent is to simply ingest the 10-bit footage, edit and export to the usual delivery targets - AVC (H264), MPEG-2 and now HEVC (H265), or whatever - you are going to be converting to 8-bit anyway. And one saving grace is that KDenLive uses x264 as the built-in H264 encoder, which can be custom configured as required. DaVinci Resolve on the other hand uses a Main Concept H264 encoder implementation that just can't match x264 for quality, at least at the bitrates one would normally use in practice. So you are left with having to export to an exchange intermediate (whether 10-bit or 8bit) for external H264 encoding. That said, Resolve was not designed to be a target delivery platform. It was designed primarily for studio cinematography professionals who are using high resolution/bit depth exchange formats.

It would be nice if KDenLive could at least move to 8-bit floating point processing at some point - but I can't see that happening anytime soon and would likely require someone at the MLT development level with a vested interest in driving such a project.

So I am not in any way suggesting that KDenLive should not be considered for editing 10-bit footage. Just bear in mind though that it is going to be edited dithered to 8-bit with integer (fixed point) processing. And if it's 4K material, the same holds whether you go for a 4K project with custom proxy or a down-sized resolution project.

BTW - depending on the model these Red cameras record up to 8K and 16-bit RAW. And the codec itself, although based on JPEG2000, is rather complex, making it very doubtful that an ffmpeg decoder will be implemented for it.

Odd that the OP hasn't even acknowledged these replies. Seems to happen a lot around here. Makes you wonder why bother taking the time and effort to respond to such queries.

Inapickle wrote:
Odd that the OP hasn't even acknowledged these replies. Seems to happen a lot around here. Makes you wonder why bother taking the time and effort to respond to such queries.

Well I certainly appreciate you taking the time to share that full and enlightening response!

Off to re read it now...

Very many thanks!

You're welcome.

Inapickle wrote:
... that's a consideration that could be applied to most NLE's out there, at least at the 'consumer level'.

At the risk of taking this thread off topic briefly, I assume that you would regard Resolve and Avid as 'Pro Level' NLEs, but how about FCPX and Premiere Pro?

Thanks!

brodie wrote:

Inapickle wrote:
... that's a consideration that could be applied to most NLE's out there, at least at the 'consumer level'.

At the risk of taking this thread off topic briefly, I assume that you would regard Resolve and Avid as 'Pro Level' NLEs, but how about FCPX and Premiere Pro?

FCPX and Premiere Pro certainly, and you might add to that Vegas Pro, Edius Pro, Lightworks Pro and HitFilm Pro, maybe - although I'd still consider that essentially a compositor for creating film effects. I've only ever tried the free version, Hitfilm Express, with a couple of the purchased add-on packs, and that is definitely consumer level with a very little choice of export formats.

By 'consumer level' NLE though I was primarily referring to the likes of Corel VideoStudio Pro (but not really 'pro'), Cyberlink Power Director, iMovie, Premiere Elements, Vegas Movie Studio and Pinnacle Studio.

In some respects I suppose you could view KDenLive as being in the 'middle ground' in that it supports only 8-bit processing but has some 'pro-level' features that you don't find in 'consumer level' NLE's, like Videoscopes, Curves, LUT support and of course the capacity to export custom (ffmpeg supported) formats.

Granted, some of the 'consumer level' NLE's do have basic primary and secondary color correction tools or provide them by way of 'add-ons' (like Hitfilm Express) or third party plugins (like NewBlueFX ColorFast) bundled in the 'premium' packages, but you could hardly call them 'pro' grade and there are no videoscopes to guide accurate adjustment.

Thanks again for this, very helpful information indeed!

You're welcome. I hope my comments will be taken in context though and not viewed as discouraging people from using KDenLive. I'm sure there are many people editing native 10-bit material from camcorders/DSLR's or whatever with KDenLive and are very satisfied with the results. We're really just talking about the finer points of 'pro-level' color correction/grading here.

I think the comments were clear and well balanced. Personally I have been looking to incorporate as many open source tools as possible into my workflow and wondering if I can get along without Creative Cloud. Being aware of the 8 bit limit of ffmpeg and mlt is helpful in understanding when these tools are appropriate and can be expected to deliver good results, and when something else might be more appropriate.
I wonder if, with the spread of 10bit codecs in cameras (e.g.GH5), there might be a groundswell of demand for ffmpeg and mlt to accommodate this? But I know nothing of the technicalities involved, and how challenging this would be!

Thanks again for the helpful information!

Periodic requests for native 10-bit support have been coming up on the forum for nigh-on 8 years now - the first that I could find:

viewtopic.php?f=265&t=112573&p=270839&hilit=mlt+10+bit#p270839

.....and the last in January this year, prompted by the impending launch of the Pana GH5:

https://forum.kde.org/viewtopic.php?f=265&t=138514

...where I added my view on the subject. Actually it was that initial set of tests with greyscale gradients that prompted me to look more closely at how KDenLive handles 10-bit inputs. There I speculated that they are dithered to 8-bit on input, because that's what ffmpeg does. There are better ways to show that that is indeed the case. Also the comment I made there :

So yes, with 10-bit full range inputs there is greater precision in the compression to 16-235 range that occurs on import....

viewtopic.php?f=265&t=138514#p370765

..in hindsight, is not quite correct. There is a semblance of higher "precision" as judged by the smoothness of the histograms, but what you are seeing there is the effect of dithering, not true 10-bit scaling precision.

The further point I was making though is that what also limits KDenLive as a 'professional grade' editor and grading software is that it is constrained to processing at 'broadcast safe' levels (8-bit Y'CbCr 16-235) , which is fine for most of the Rec709 4K/HD AVC footage coming off consumer grade and lower-end pro-line video cameras. But for footage recorded with full range YUV luminance (0-255), and flagged as such by the pixel format designation, the luma will become compressed to 16-235 range and processed as such. And if it doesn't carry the full-range flag it will get clamped/clipped to 16-235 range - which is the case for full range 10-bit 422 sources because there is no full range pixel format designation for 10-bit 422. That can be circumvented by invoking the 'Full Luma' option in Clip Properties, but the outcome is still compression. And clearly, one needs to be aware of this behaviour, which I suspect most users of KDenLive won't be - assuming, quite reasonably, that their camcorder/camera footage is interpreted and processed as it should be.

So it is not just a matter of native 10-bit support. There needs to be the option to process at full data levels as well. What makes DaVinci Resolve so flexible is that it normalizes inputs to a proprietary YRGB format ('DaVinci color science') and all background processing is performed in 32-bit float at full 'data levels'. So even if one chooses to work at 'Video' (Broadcast Safe, Limited, Y'CbCr) levels, no data is lost and any useful outlying data can be pulled in to range, and one can easily switch between 'Full' and 'Video' data levels. That's the benefit of floating point processing.

To my mind, that's what KDenLive needs to move to for proper handling of footage coming off cameras like the GH5, which (like the GH4) has optional luminance range recording modes, not to mention the higher level data scaling precision needed for manipulating footage recorded in log and other flat picture profiles, as is becoming the increasing trend.

As to whether a 'groundswell of demand' for these higher level features would be enough to change the status quo, I really don't know. I've said my bit. Like I said, my feeling is that:

...... the only way I can see either becoming a reality is if there is someone with a vested interest, able and willing to champion the cause at the MLT development level

The KdenLive developers can only work with the "hand they are dealt" by MLT. Added to which it would involve a massive overhaul of all the existing effects and transitions to work with higher bit depth and/or float processing.

And then there's the question of how the sense of 'demand' for these features can be gauged and communicated to those in a position to make a difference - a forum poll maybe ? Not something I'm particularly interested to initiate and promote myself, when there are other options available.

Sorry - I know my posts tend to be a bit long winded - probably why, for the most part, they go unheeded . I do try to be brief but am often driven by the need to explain things in full. Whether that's a blessing or a curse I guess depends on the perspective of the reader.

Edit: Just a side note. If you have or are considering a Pana GH5 and are of a mind to use DaVinci Resolve, a couple of things to be aware of. Firstly, support for native import of the GH5 UHD 10-bit 422.mp4 files has just be added with the latest version upgrade - 14 beta (emphasize beta) - but only the licensed Studio version, which will put you back US$ 299. To edit/grade these files with the free version requires transcoding to a 10-bit 422 intermediate. The UHD AVC (8bit 420).mp4 format clips import OK though.

Secondly, Resolve is heavily GPU dependent, and this latest update is even more GPU memory hungry than the last, so you need to be sure your hardware is up to it, and you are on Windows 10. By contrast I am able to run KDenLive on Kubuntu 16.10 adequately on a PC with relatively modest hardware - AMD 6300 x64 processor, 8GB RAM, NVidia GeForce GT730.

DoomDahDoomDoom wrote:I found a download for something called "REDline" on red.com which apparently is in Beta, but no documentation on what it does, how to install it, no nothing.

I don't think you can use ffmpeg to directly convert the r3d files, but you can do it using a combination of redline and ffmpeg to get something more Linux-friendly.

I don't know the details about these cameras or this format, but I've successfully tried this using some 4k .r3d files on the web (from YouTube channel IRIS32FREE via download.iris32.com). They come with a "color grading profile" .RMD file in addition to the .R3D file.

First, use redline to export to an Apple ProRes .mov file. This seems to be one of the best choices in terms of disk space and ffmpeg compatibility.

My main input file is "A026_C083_09103K.R3D" and the following assumes it's in the same dir as REDline (modify as necessary):

Code: Select all

./REDline --i A026_C083_09103K.R3D --o myvideo --format 201 --loadRMD A026_C083_09103K.RMD

"--format 201" is Apple ProRES. Other possibilites are "DPX=0, Tiff=1, OpenEXR=2, JPEG=3, SGI=4, R3D Trim=102, Apple ProRes=201, Avid DNX=204, [default = DPX]"

You should now get a myvideo.mov file. (If this is enough, great!)

Now you can use ffmpeg to transcode this to H.264 MP4 or whatever you like (maybe something less lossy if needed):

Code: Select all

ffmpeg -i myvideo.mov -vf scale=3840:-1 -sws_flags lanczos -pix_fmt yuv420p -movflags +faststart -vcodec libx264 -profile:v high -preset slow myvideo.mp4

I'm using scale=3840:-1 to resize the videos here to 3840x1648 from a 4480x1920 wide screen format. Note you will need to check whatever -pix_fmt settings, presets etc. are suitable for your use.

I'm not exactly sure how the bit depth/chroma sub-sampling gets handled throughout all of this right now, I'm just using the common 8-bit yuv420p setting when outputting the mp4 at the end, so you might need to investigate this at each point.