Messages

Test done, you are right: re-changing back the name to the original form Mdd-hhmm.MLV solves the issue: now the original MLV goes finally in the A_ORIGINALS folder. I tried importing into Davinci both DNG-folders: the one converted from the Mdd-hhmm.MLV file, and the other one converted from the renamed mess-mess.mess.MLV file. The result seems pretty the same (I can't notice any difference in preview, nor in scopes). But you wrote:

Renaming adding punctuations, white space or other strange symbols will often mess things up.

And that worried me a bit: do you mean simply that original MLV will be placed into the DNGs folder? (That's honestly a minor problem.) Or do you mean that something in the DNGs themselves (code, list order) could be messed up? (That would be a pretty dramatic thing because I should rename my MLVs to their original name, that's a rapid thing in itself but implies loosing my detailed system of identification for all that amount of MLVs...)

Second question: I converted MLV to DNGs once in Switch (leaving all default), and once in MLV-App specifing Cineon tonemapping and Alexa gamut. I imported both results in Davinci: in RAW Panel I set both with BMD Film in Color Space and Gamma. Since I was using DNG files, I naively expected to see the same visual result, instead I noticed a huge difference. So, the question is simply: which is the "right" way of converting the MLVs? Should I specify a profile (BMD Film, since the target is Davinci?) or leaving all default (MLV-App's default gamut is Rec.709, but which is Switch's default gamut?)

Thanks a lot for your help.

Screen recording...

Here we are
https://youtu.be/dpOBfOc5seU

Mea culpa, Danne: yes, the original MLV file is still in the folder of all the dngs. Anyway, what actually happens is that Switch creates the A_ORIGINALS folder, then immediately after starting the conversion it moves the original dual-iso MLV file into the dngs' folder. When Switch is near to have finished, it removes the A_ORIGINALS folder. Then arrives the "finish" window.
I believed that at the end of the conversion I'll have found the MLV into the A_ORIGINALS folder (like when I used old versions of Switch, if I remember correctly). Anyway, is it all normal?

Hi Danne, sorry I meant MLV to DNG! I made various tests: MLV (dual-iso) to DNG. Running the task, MLV disappears almost immediately from its native folder. After the conversion is terminated, MLV is not in the A_ORIGINALS folder neither...
Never happened with old versions of Switch... It's strange.

Hi everyone, my dual-iso clips have lines and flickering also after the conversion (MLV to DNG)...
When I upload the dual-iso clip, MLV-App's dual-iso panel is grey. The only button I can clic is "Force". So, I clic on Force and then on ON. I tested both Interpolation_Mean + Alias_Off and Interpolation_AMaZE + Alias_ON. The result is that after the onversion from MLV to DNG, lines are still visible together with flickering.
I tried also Swicth (all defaults, but 15 dualiso automation enabled) and the result is the same...
Any advice, please?
Thanks in advance.

Sorry guys, surely a stupid question: I've downloaded the last Switch and now, converting MOVs into DNGs, it deletes the MLV originals (the A_ORIGINALS folder is empty). I reset Switch to defaults, but it continues to delete the MLV originals...
How can I avoid that?
Thanks in advance.

Wow guys, really thank you both reddeercity and masc for your fantastic informations!

@reddeercity: Your system blows my mind: very smart! And FreeNAS is very interesting!!! Thanks also for the tip on raid5 vs raid6. Surely my current-project-RAID is slowed down by both the fact that it's full as an egg (48TB in raid6 is 36TB and I have more than 33TB of data inside...) and the configuration raid6 itself. I wanted raid6 because for this project I was terrified of losing data, and this indirectly is also one of the reasons I'm avoiding mlvfs: I want to do my proxy-edit (and the future DNG-edit) without the external-raid always turned on (for extending its life, and avoiding the noise of its fans. The proxies (now) and the definitive selected DNGs (future) will be placed onto an internal 8TB 4-NVMEs raid-0 (HPT with 4x EVO-2TB drives) that is my secret weapon together with the two Radeon VII GPUs (I've tested grading uncompressed 14bit DNGs with a bunch of nodes, temporal denoise, effects... and the preview in Davinci goes always in real-time! Like a boss

@masc: yes, I was surprised by the "limit" of about 220 long clips before the uploading slows-down. It's strange. Anyway, that's what I did to make the job:
1. I uploaded "packs" of 220 long clips in MLVApp (it took me around 2 minutes per-pack) and I simply created the MAPPs (more than 30 minutes per pack, so it has been a looong 12-hours work-day);
2. I opened 10 instances of MLVApp and I uploaded 334 long clips into each instance (I have a total of 3340 clips to be converted);
3. With all the instances standing, I ran the first just for letting it recap all the clips, and once it started the actual conversion I aborted;
4. I repeated point 3 with every other instance;
5. After all the recaps were done, I ran all the instances together (Activity Monitor says 'round 160% of CPU for each instance).
Now my sweet hackintosh is working... alone... in the darkness of its tiny bedroom, dreaming (perhaps) a magic lantern. We'll meet again in three days. Good night

Luther, your reply is hugely informative! Many thanks.
I understand your point. Thinking a migration to Debian is now a bit problematic for me (various things hold me on OSX, not only Davinci), but surely for a next project I'll think about it, seriously.

Thanks Luther for your advices.

transcoding to CDNG.

Unfortunately, I haven't enough free space to convert all the clips to DNGs. My idea is to convert the clips directly to a proxy code just to experiment various editing hypothesis, and only once I'll know which are the clips I actually need, I'll convert them few MLV-to-DNG. But now I need a MLV-to-MOV direct solution.

Transkoder can take full advantage of GPU using CUDA.

I said sadly goodbye to Nvidia one year ago (I sold 3 Titan X GPUs) because it seems that latest Davinci needs a recent OSX, but Mojave can't work well with Nvidia, right? So I went for a couple of Radeon VII GPUs.

Consider using ZFS instead.

That's interesting! But how can I re-format my external storage without deleting my mlvs inside??? Is it possible???

I'd say it's time for you to invest in something like Transkoder.

Hi Luther, thanks for the reply. It seems that Transkoder doesn't handle MLV codec. I've seen an mlv-to-mov software for Windows that – they say – works on GPU (here), but I'm stupid (too stupid) because, ab illo tempore, I formatted my mlv-storage with HFS+ (if I had exFAT I could switch to Win if required), and also I've sold my Nvidia cards... Another option is slimRAW but it seems limited to MLV-to-cDNG (no MOV, no proxy).
So, up to now, the most realistic option for me remains MLV-App.

Running apps in parallel is only recommended if you have many cores which are far away from beeing used 100%

I'm using an hackintosh with an i7-extreme with 10-physical cores. I've tested multiple parallel Apps running and I've noticed the following:
1 App: T(ime);
4 Apps: T/2 (roughly);
8 Apps: T/2.66;
10 Apps: around T/2.88.
In a scenario with 33 TB to be converted, even the little difference of 2.88 over 2.66 is welcome (because means less hours).

The time for parsing the information of a clip relates to the clip length, and the speed of your disk.

I'd say that could be the real bottleneck, since all my mlvs are stored into an 8-HDDs 48TB RAID6 thunderb.2, that is only "relatively" fast, but surely not fast as even a single SSD. But in your test you are using a USB2 HDD that should be pretty slower than my RAID, so the mistery of my slowness remains unsolved...

On my 2010 MBP (OSX 10.9.5) + external USB2.0 HDD each clip took around 1-2sec (without MAPP). MAPP creation also took around 1-2sec per clip (clip lengths 5-20sec, FHD).

Perhaps the answer to the mistery is the clips' duration: my clips (around 3400 for this last single project) are from a minimum of 1 minute to a max. of 40 minutes per-clip.
I've noticed that if I drag up to 220 "unknown" clips into MLV-App it can take 1'45" to start seeing the clips added into the Session panel. Then, opening a single clip can take 10 seconds (with MAPP it's only slightly faster). Creating a MAPP can take from 1" to 20" (for every single clip) but creating MAPPs seems to be the ONLY solution for me: in fact, without MAPPs, I confirm that I can upload up to a max of 220 clips (also if distributed into various parallel instances of MLV-App running together), i.e. I "could" upload more clips, but once the conversion starts the App recaps all the clips before the conversion, then from the 221th clip the time of recap increases monstrously (the App "seems" crashed). Instead, WITH the MAPPs, I can upload many more clips without "recap stoppage" (of course, the recap time of 1-10 seconds per clip remains, but at least there isn't a stoppage anymore).

Happens the same, if you remove the first 200 from the project?

Yes.

Is it slow then also for the first mlvs in the session? Or also starting from ~200th mlv? I'll try to reproduce this evening.

Only from ~200th mlv, both in single App running and in parallel Apps scenarios: if I have 2 Apps running in parallel, and – let say – I have 200 mlvs in the first App, only the second App slows down (almost still).

I'll try to reproduce this evening.

Many many thanks, masc!

P.S. I tried to create MAPPs loading packs of 200 mlvs. This trick helped for the first 400/450 mlvs, after that – even quitting and restarting the App – the following packs of 200 mlvs slowed down a lot. Anyway, while doing the MAPPs, I noticed that CPUs work non-continuously: i.e. Activity Monitor says that at one moment the CPUs for MLVApp work at 200%, but the following moment the CPUs for MLVApp are at 4% (like if they have intervals of still).

Hi masc, thanks for your kind reply.
I'm on OSX.
I have a total of 3400 mlvs (much less than 2^31). My initial idea was to open 10 instances of MLV-App, each one with 340 loaded mlvs, and let all the 10 instances working in parallel. Up to now, it works only if the total amount of the MLVs is 200 (i.e. 200 for a single running App, or a total of 200 distributed between the parallel running Apps).
Up to now I never used MAPP, but now I'll test it.
I've just tried to create MAPP files for all the mlvs uploaded: I uploaded 348 mlvs in a single App, then "Create all MAPP...": all went rapidly until 200th/250th mlv, then the App slowed down dramatically...

Some limit in number of MLVs uploadable into MLV-App?
That's what happened to me: I tried to upload about 400 MLVs (about 3.3 TB) into a single MLV App. The App uploads correctly all the MLVs, then I select all them and clic the export button (prores code). The exporting bar appears saying something like "in preparation", and I can see the Cut in/out panel changing rapidly the "out" number (because the App is rapidly reading the MLVs durations, clip by clip, as expected). After passing about 200 MLVs, suddenly the App slows down dramatically (i.e. the Cut out numbers changes, but VERY slowly), the computer's processors seem not working anymore (iStat menus), instead the external RAID (with the MLVs) is still noisy but the App seems dead.
If I open another parallel instance of MLV-App, and I upload a single MLV to be converted (just for test), this parallel instance works without problems.
My question: is it possible that a single MLV-App has a limit of 200 uploadable MLVs?
Thanks.

Well, good luck solving your issues.

Psychiatrically speaking? Ahahah...

Whatever proxy export chosen you need to match starting point as close as possible in resolve, color space, gamma etc.

Perfect! I'll do so. Thanks a lot.

I would grade the proxies directly in resolve. Rec709 - to whatever in resolve using nodes.

Thanks as always, Danne.

On a sidenote I don't see why you won't export proxies directly from resolve if you still gonna use dng files in the end. Mixing programs will be far from correct imo.

You are right, Danne, it's not a strictly correct workflow. The reason is that MLVs are stored in an old external RAID that for "safety" reason I'd like to keep turned off during the long time of the proxy-editing (so, no MLVFS). If I had enought space I would have converted directly MLVs into DNGs, but I haven't (I'll have only the space to convert into DNGs those MLVs I'll verify – with the proxies – they will be actually used in the final editing). So the only thing I can do now is converting all the MLVs into small Prores Proxies, then trying an editing "hypothesis", then re-converting the fewer corresponding shots from MLVs to DNGs to remake both the editing and the grading.
For me, at the moment, it's important that the Prores Proxies give me simply an "idea" of the DNG-grading, not a strict method for replacing the proxies with the DNGs.

Thanks Danne and Luther!

I'd go with Alexa Log-C.

Ah, that's interesting: is yours a genuine preference, or is there some reason to prefer Alexa Log over Cineon Log (with Alexa gamut)?

@Danne: Thanks again for your replay. Your advice is perfect, but actually I don't try to match the "proxy-grade" with the following "DNG-grade", I simply (and perhaps naively) try to have a "good-to-grade" proxy that gives me as room as possible to be graded in Davinci, and at the same time is as easy as possible to be graded. Rec.709 doesn't give to me the same room as a log profile. (Obviously, once I'll replace the proxies with the DNGs I'll have to remake all the grading... But I can image that DNGs will give me "at least" the same room as the proxies – naturally a much more large room.)

I just use Reinhardt with AP1 matrix. Increase saturation and play with curves. This is the fastest way of processing.
I used to use Log-C, but skin midtones gets trashed for some reason.

Thanks a lot, Luther. But I understand that your advice refers to grading directly into MLV App, right? My bad: I didn't specify correctly my former question: actually my question is «Which profile do you recommend (to be graded after in Davinci)?» (Now I correct the question also in my former message.)
i.e. my idea is to find which log profile outputs the best "log-proxy-for-room-grading-in-davinci-with-few-nodes" file (so that once I'll finish grading in prores, I should be able to replace the proxies with the DNGs having the possibility of obtaining a very similar – or even the same – result.)

Hi everybody and MANY congras to the author of this wonderful piece of software. MLV App is definitively in my workflow.
My question: I work on RAW files from 5D3, and I'm using MLV App to obtain Prores Proxy files to make a preliminary/sketchy grade in Davinci. I tried 3 Profiles: Alexa, Cineon and BMDfilm. My first impression is that with a bit of patience, you can achieve the same result with the 3 profiles. But since I'd convert a big bunch of RAWs with a single profile – for convenience – I'm try to understand which is the "good-enough-for-every-shot" profile that is possibly also a "less-nodes-for-a-good-grade" profile!
In short, my question is: which profile do you recommend (to be graded after in Davinci)?
I try to elaborate (forgive the non-technical terms):
A) Cineon seems to compress the histogram slightly pushing it towards the right (that should be good because it "saves" informations in a no-noise area);
B) Alexa does a similar thing but toward the left (theoretically not good because it's a noisy area, right?);
C) BMDfilm instead stretches the histogram with blacks starting on the very left.
It seems to me that BMD gives the fastest "couple-of-clics" good result (after Davinci grading) because of its contrasty histogram and "filmy" tone, BUT (for my taste) it's more difficult to obtain a less-contrasted look, and grass-greens seem to be flattened into a single unnatural color (even in Davinci...)
For my taste, Cineon and Alexa logs give the most pleasant results (always after Davinci grading): Alexa is faster for grading dark shots without great contrast (where Cineon adds always a bit of "halo"), whilst Cineon wins hands down in highly contrasted shots, also thanks to a creamy/screeny/gaussian rendition of lights when near to clipping.
For these first-and-rapid impressions, I'd decide go for Cineon for converting all my shots into proxies, but I'd like to know what you think about. Any advice?
Thanks a lot.

Dear Danne, I've made a test (perhaps could be useful sharing this):
My hackintosh has an old i7-6950X Extreme 3GHz 10-cores.
Two tests:
1. A single MLV App converting a list of 4 different 27GB MLVs to MOVs in about 37': CPU usage is 1750-1800% (Activity Monitor) and all the cores seem working equally (iStat Menus);
2. Four MLV App instances running in parallel, each one converting 1 single 27GB MLV to MOV in 19-20': each instance's CPU usage is around only 400% and all the cores seem working equally.

So, it seems there is a strange discrepancy: the CPU usage of a single App running in "solo" is more than the sum of the CPU usage of 4 apps running in parallel (so a single App seems to be more efficient because it use more CPU), BUT 4 Apps do the job in about half the time (even if using less CPU...)
It's a bit strange, isn't it?

[you can happily ignore it]

Dear Danne, THANKS (really) for your guide and your patience!

You can start two or three Mlv app apps in prallell to speed up conversion.

That's VERY interesting: sorry I can image it's a dummy question, but how can I run 2 or 3 MLV App apps in parallel? Some script from the Terminal? Or via Switch? (Up to now I can simply run a single window of that app...)
...Now I know: Script Editor Great advice, Danne, thanks a lot!

For proxy workflow you will still need dng files in the end either virtually or physically exported. [...] Don´t see why you don´t want the dng folders if you are using a proxy workflow in resolve.

[I want to give you an asnwer about this, but I honestly warn all the people in the forum that the following section is boring, not-technical and unuseful, so you can happily ignore it ] Actually I don't plan to follow a regular proxy workflow in Davinci, but simply use a prores proxy version of my MLVs, because my current project in based on about 3500 MLVs that means around 34 TB stored in a single 8-drives external RAID6 thunderb.2 full as an egg, and in my 2nd external RAID I haven't enough free space to store all the converted-DNGs. Surely I could use MLVFS but it means keeping the 1st RAID always on, that's I'd avoid for various "safety" reason (first of all the content's safety). It's a huge project to handle for a newbie total-indie like me, mainly because I have NO screenplay: in fact the footage is a sort-of-documentary thing simply based on a concept, not on a story. My "freely-artistic" approach (clearly this is a non-business thing) is "discovering" the form of the film (the screenplay) directly from the "timeline-lab", where I hope to understand which (FEW!) shots to keep, and which others (many, I hope) to cut out. For the few "survivors", I finally will do the actual MLV-to-DNG convertions, and this selected DNG-footage will be placed onto a pretty fast internal 4-NVMe 8TB RAID (should be sufficiently roomy). Then I'll redo the editing following the former proxies-based editing. It's not actually a workflow... i.e. it would not have been strictly efficient for an eventual paid job

Thanks again Danne.

Actually, there's built in mlvfs support in Switch. In main menu select (ml) Then select (A) to activate virtual dng files and go from there.

I had seen it. Unfortunately in my current case mlvfs seems not to be a solution because all the (too many) original MLV files are in a relatively old (and noisy) external RAID. I would be oriented keeping my external-draisine (dRAIDsine could be an appropriate neologism) "safely" off during the looong time of the preliminary video-editing in Davinci I'll have to face. So I'd prefer having indipendent proxies on a faster (and smaller) internal drive. The only problem is the huge amount of time for the conversion... I'm on Mac, but I've read something about a Win software that should be very fast in MLV-MOV conversion since it's GPU-based (for proxy-things should be great). I'm hoping into something similar for Mac too...

Thank you so much zeek! So, if an high gamma value (in MLV App for Prores) is not "technical" but a "benefit", which is the limit? I can image that the limit is "just before cutting anything in the histogram to the right", is that right? So, the idea is to push the histogram as to-the-right as possible, in order to enlarge the room of color-grading possibilities (and reducing teh noise).

Thanks Danne (my hero!)

If there´s an MLV it will first convert into dng files then start encoding to prores. Switch cannot pipe MLV to prores directly but created dng intermiediates to work from.

This is yet the answer I was looking for: actually I was searching for an app that converts MLV-to-Proxy without producing DNGs (for lack of space) and faster than MLV App.
Up to now, I've noticed that the only app that can convert MLV-to-Proxy a little faster than MLV App is MLVFS+Davinci-optimized-media. BUT... Davinci optimized media are sort of weird/folderish/internal files, and if I disconnect the MLVFS-virtual-drive then I lose the preview image on the timeline footage...
So... it seems MLV App is the only way to go at the moment... (but it takes 8 days for a basic-bilinear MLV-to-Proxy conversion...)

Do you know if there is a Mac app that can do the job via GPU? It should be a faster solution, right? Expecially for something like producing proxies.

Try setting gamma to 3.15.
Bring down exposure a little, then increase dark strength to get the blacks back.

Thank you. Is there a sort of technical reason to maintain gamma so high, or it's just to push the histogram to the right?
I try to elaborate: my purpose is to obtain a flat image out of MLV App for working after in Davinci on exposure and blacks and others... So my purpose is NOT to obtain a "final" result directly out of MLV App.
In this particular case I'm doing a bunch of prores proxies from some MLV files, to work with in Davinci. I'll use these proxies for a preliminary editing in Davinci, then I'll replace them with the real c-DNGs instead.
Both proxies and c-DNGs will be produced by MLV App.

So my question is: should I set MLV App with BMD Film and gamma 3.15, for both prores proxies AND the future c-DNGs? Or it's important to set gamma only for prores proxies (since in Davinci it's also possible to set c-DNGs with BMD Film for obtaining flatting the image)?

And: If I convert in MLV App my MLVs to c-DNGs without changing anything, and then I set BMD Film in Davinci, I'll obtain a sort-of-flat image that is LOT LESS flat then the prores proxies produced by MLV App set with BMD Film and gamma 3.15. Is it because I HAVE to set MLV App to BMD Film gamma 3.15 ALSO for converting to c-DNGs?

Thanks