Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - LRF

#1
I read somewhere that those additional files that appear might have influence on results, so I was deleting them. Each attempt was made with only three source files in folder.
As far as I remember, 1.3.4 was working fine, when I gave it a short try some time ago.

Files were 650-750 MB each, recorded with 5D3.
#2
First of all, thanks for excellent program. Ability to see thumbnails is great.

I was trying to make some tests with v.1.4.3 on WIN7 64-bit and my results are quite random.
Three test files were located in folder G:\MLV. Two 24fps MLVs recorded in autumn, one 25fps RAW from newest ML build.

Can't find any repetitive pattern; sometimes converting MLV or RAWs to MOV hangs at 0.79%, sometimes at 0.23% or so, and 0:00:00s long mov file is created. While closing, program alerts that there's some conversion going on. Sometimes conversion is just fine. In last 10 attempts I had approx 30% success rate. All initial attempts failed. Recent ones worked fine. All within 10 minutes. Nothing has changed in the meantime.

Converting RAW to DNG doesn't work in my case. Empty folder is created, sometimes static progress information with 0:00:00 is displayed, (usually not) then disappears.
Converting MLV to DNG works fine.

Tried both "C" and "E" keys.
With "C", when exporting to DNG, only MLVs show up in progress list. When exporting to MOV, all the files are displayed. Sometimes RAW file hangs at 0.96% and prevents following files from being processed, sometimes all three convert fine. Once one of MLVs hanged at 99.7%.
#3
General Chat / Re: Apertus Axiom Beta
October 15, 2014, 10:35:42 AM
In my humble opinion, when it comes to discussion about details of a "Professional Digital Cinema" camera for film makers and not scientists after it has been funded, one can propose various button shapes or layout, menu structure options, interface variations or body colors, but thinking IF it might have casing allowing it to be taken outdoor (which demo shots clearly imply) is simply ridiculous.

Quote from: chmee on October 15, 2014, 09:28:24 AM
its up to you, magically transforming your sarcasm/pessimism into positive critique and kind of community-driven energy.

I would be pessimist if I started talking about future, that it's not going to work, there will be delays etc. But I don't. I don't have to worry about it. But I think that discussing most basic construction principles of something that's supposed to be a professional film making device and not a developer toy, is a joke. And I suppose that most of the backers imagined to have ability to take the camera out, not just keep it open on the desk and connected to computer to play with codes and switches.
Philip B. backed it to enjoy open source coding freedom? Sure.

That's how I see it. To let "community-driven energy" flow, I promise not to write any more sarcastic/pessimist comments regarding AXIOM Beta  ;D
#4
General Chat / Re: Apertus Axiom Beta
October 15, 2014, 12:52:34 AM
Quote from: Sebastian on October 13, 2014, 10:53:15 PM
the AXIOM Beta IS a developer kit / prototype so we do not want to "trick" people into believing anything else

Strange, because while collecting money you stated: Meet AXIOM Beta. Professional Digital Cinema Hardware.

Oh, well, let's hope that backers got the difference and it's not a spectacular... misunderstanding.

Quote from: Sebastian on October 13, 2014, 10:53:15 PM
-) the cheap box for people who don't care about the enclosure and use the Beta in a lab or just for development/testing

Spend thousands of Euros on Beta and on additional professional equipment just to make it work and then keep it in a lab for testing? If you say so...

Quote from: Sebastian on October 13, 2014, 10:53:15 PM
-) the more sophisticated and more expensive cage/camera outdoor shooting enclosure

:D
AXIOM Beta: Professional Digital Cinema Hardware - for shooting outdoors pay extra.

Which option is planned for backers for their "developer kit/prototype", by the way?

Sorry, guys, but it somehow sounds like an expensive joke.
#5
General Chat / Re: Apertus Axiom Beta
October 02, 2014, 11:29:29 AM
Quote from: aombk on October 02, 2014, 02:49:13 AM
the beta will cost 2300 for backers.

I'm glad for you, that you don't have to count money before spending  ;)
The Beta will cost an European backer around 3 200 EUR, not 2 300 EUR.

Why? 2300 EUR + 350 EUR perk cost + (circa) 20% VAT, because, as far as I understand this sentence correctly, prices shown are prices netto: "Local taxes (VAT), custom fees or duties may apply when receiving your AXIOM Beta."
Total - 3 180 EUR.

Regular price will be 5 990 EUR + VAT = circa 7 200 EUR
Again, please correct me about VAT if I'm wrong.

Quote from: aombk on October 02, 2014, 02:49:13 AM
you then need an external recorder and viewfinder or monitor and batteries. do you want links for these solutions to check their prices?

No, thank you. I did it long ago, when deciding what system I'm going to need and what I want to carry around with me while shooting.

Quote from: aombk on October 02, 2014, 02:49:13 AM
you trust the manufacturers and the engineers and the developers of airplanes and cars (...) why dont you trust these apertus (and ML) people as much?

Because I buy my cars and airplanes when they are already built and tested by crash test dummies and highly paid tests pilots. Call me a miser ;) And ML team has absolutely nothing to do in that sentence.

Quote from: KurtAugust on October 02, 2014, 09:35:34 AM
LRF: The Magic Lantern team has done so much for us. If they were asking for ice cream, I'd say "Hell, have two."

Tell me where to send money (not Bitcoins which I don't have) for Magic Lantern development, and I add a fruit salad to you ice cream for them.


I don't want to start a flame war, just trying to explain my (maybe shortsighted) point of view. Good luck.
#6
General Chat / Re: Apertus Axiom Beta
October 02, 2014, 01:23:36 AM
Quote from: Walter Schulz on October 01, 2014, 10:41:59 PM
As of today we failed to reach "the masses" to convince them throwing in small amounts.

I'm afraid that the "masses" are not likely to appreciate effort of producing something that is not directed to them. After all we are talking about Beta camera, which will cost 5990EUR +VAT in its bare, most desirable version. And it relies on external recorder even to capture sound. Not to mention cost of additional stuff like batteries, viewfinder(?) etc. And in fact Beta prototype doesn't even exist, yet, as far as I understand, so nobody knows how much will battery last, will it overheat or not, will picture quality be better than what we can see now...

I understand that supporting this open source initiative might have some positive influence on ML development, but to convince an average DSLR shooter to take part in it, it needs to offer a bit more than "Social karma" or a T-shirt. To be honest, I'd prefer to spent that money directly to development of ML, rather than on a camera that is clearly addressed to a totally different market.

Sorry if my opinion is disappoints you, but I wish you all success, regardless.
#7
Discussing GPL nuances with Mr. Rhodes seems to be rather... fatuous:

"GPL is all about showing off how clever you've been then spitefully forcing people to re-invent said circular rotary object unless they're capable of living on fresh air and sleeping in a cardboard box. Which is so fatuous it makes me weep."

Post #2:
http://forums.bit-tech.net/showthread.php?p=2145159#post2145159

#8
Raw Video Postprocessing / Re: MLVFS windows client
September 23, 2014, 10:22:09 AM
I didn't finish previous tests, so still don't have precise data, but it might be insignificant since I didn't manage to get realtime playback with previous build anyways.

With this build still no luck with realtime, but numbers seem to be lower.

Here's data from "GET" properties in Explorer:
283,0162 ms
321,0184 ms
2,0001 ms
3,0002 ms
3,0001 ms
4,0002 ms
3,0002 ms
3,0002 ms
3,0002 ms
0 ms
0 ms
0 ms
0 ms
0 ms
15,6 ms
0 ms
0 ms
0 ms

Precache set to 150.
Where there is 0 ms, I was still getting preview and properties without problem.

In Resolve it took 36 seconds for first play. But there as a lot of skipping and black frames. Second half of the clip black. Some error and .NET crash at the end, so wasn't able to collect results.

I also benchmarked the storage hard drive, and more or less it keeps manufacturer's parameters: Average Seek Time 8.9ms (10.3 in my case), Average Latency 4.17ms, Interface  SATA 3.0Gb/s, 1TB 7200 RPM, 32MB Cache.
But since it's obvious that the whole system can't cope with such amount of data, my results might be totally misleading.
#9
Raw Video Postprocessing / Re: MLVFS windows client
September 19, 2014, 11:29:20 PM
I'm making some more tests, checking if location of mapped folder makes any difference. Just noticed, that times can go as low as 10ms or 20ms, and then for example 80,000 for several times, and then again 10. Will let you know if I reach any conclusions.
#10
Raw Video Postprocessing / Re: MLVFS windows client
September 19, 2014, 10:36:05 PM
Yep, that's what i suspected. So far, for h264 it was more than enough. But since I started experimenting with RAW recently, looks like it's time for serious upgrade.
Anyways, thanks a lot, g3gg0.
#11
Quote from: N/A on September 19, 2014, 01:31:37 PM
a mission statement and set of principles for the ML project, as to clarify to third parties what our intentions are and the type of respect and acknowledgement we expect from others.

http://www.magiclantern.fm/forum/index.php?topic=13335.0


"Our intention:
To drive forward the Magic Lantern project through open sourced development.  Be that through development of the core code, modules, post processing applications, or any other applications designed to work primarily with the Magic Lantern project.

The only things we ask in return:

    Contribute back to the Magic Lantern project if you make improvements to it.
    Honor our decision that this code is free, and help to establish and support the free nature of Magic Lantern.
    If you use the code, or parts of it and distribute it (or even sell it), you must release this code (per the GPL).
    Don't act against common sense.

What does this mean for developers:
We prefer open sourced development, whether through the use of the code base already available from this project, or entirely on your own.
And of course we tolerate any closed source application as long it doesn't violate GPL terms, even if it is commercial.
But we will definitely take actions against commercial closed source tools that use GPLed code without asking the affected devs before to get an exclusive license.

Compressed view of categories:
a) open source, using our code [preferred]
b) open source, not using our code [preferred]
c) closed source, not using our code [tolerated]
d) closed source, commercial, not using our code [tolerated]
e) closed source, using our code [asked to publish source, ban likely]
f) closed source, commercial, using our code [banned]

What does this mean for end users:
From now on, we discourage everyone from using those applications that have their threads closed.
Using, testing and providing your bug reports for the remaining applications, helps drive forward the Magic Lantern project.
To clarify, only two tools fall into categories e) and f) and will face actions against them, both of them are kind of "better wrappers GUIs".
The professional tools are not affected at all, they know how to behave."
#12
Raw Video Postprocessing / Re: MLVFS windows client
September 19, 2014, 01:48:44 PM
They look like this:

312,0006 ms
62,4001 ms
62,4001 m
62,4001 ms
62,4001 ms
78,0001 ms
78,0001 ms
78,0001 ms
78,0001 ms
15,6 ms
0 ms
31,2 ms
78,0001 ms

The file is in mapped folder on a hard drive. OS and apps are on separate disk in different partitions.
#13
Raw Video Postprocessing / Re: MLVFS windows client
September 19, 2014, 11:12:03 AM
If you mean MLV file i used for the test, it's 767 MB, 10 seconds 9 frames long. No color correction applied.
#14
Raw Video Postprocessing / Re: MLVFS windows client
September 19, 2014, 10:37:29 AM
Here are some values from the beginning of the log:
412,0236 ms
470,0268 ms
1531,0876 ms
1585,0907 ms
2219,1269 ms
2263,1295 ms
451,0258 ms
2981,1705 ms
5494,3143 ms
5596,3201 ms
2016,1153 ms
2953,1689 ms
596,0341 ms
424,0242 ms
186,0106 ms
553,0316 ms
10284,5883 ms

Prefetch 150, no render cache in Resolve.
Smallest value i noticed is 52,003 ms. Biggest, the last one in log, is11354,6495 ms. The numbers seem quite high. Did I win something?  ;)
#15
Raw Video Postprocessing / Re: MLVFS windows client
September 19, 2014, 12:50:49 AM
Quote from: g3gg0 on September 18, 2014, 11:42:04 PM
can you (...) enable request logging and look for the GET ....dng requests, how long they take?

If you tell me how to to it, of course.
I tried to figure out what am I supposed to do, but have no clue, sorry.
#16
Raw Video Postprocessing / Re: MLVFS windows client
September 18, 2014, 11:22:24 PM
I wish I had good news, but...

Prefetch set to 150.
It took 3 minutes 7 seconds to play the clip. A lot of frozen frames, jumps, and blacks. Practically no playback at all. This time also some pink artifacts like horizontal lines and parts of the frame in stylish "pink and white" color palette  ;)

At the end Microsoft .NET Framework has reported  unhandled exception.

************** Exception Text **************
System.ArgumentOutOfRangeException: Value of '1004' is not valid for 'Value'. 'Value' should be between 'minimum' and 'maximum'.
Parameter name: Value
   at System.Windows.Forms.ProgressBar.set_Value(Int32 value)
   at WebDAVServer.WebDAVServerForm.RefreshBar()
   at WebDAVServer.WebDAVServerForm.UpdateTimer_Tick(Object sender, EventArgs e)
   at System.Windows.Forms.Timer.OnTick(EventArgs e)
   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

After that Resolve refused to cooperate. Damn  :D
#17
Raw Video Postprocessing / Re: MLVFS windows client
September 18, 2014, 08:25:04 PM
Hmm... I'd say that if it wouldn't be possible to have realtime playback regardless of computer parameters, then it becomes quite problematic.

If one can't see the edit or color corrected clips in realtime, usefulness of such solution is rather limited, in my opinion.
#18
Raw Video Postprocessing / Re: MLVFS windows client
September 18, 2014, 07:56:00 PM
Testing new update.
Antivir and other stuff - off
Power plan - High performance

10s MLV clip (almost static scene)
Resolve render cache off:
first play - 1 min 12s (approx 50% of black frames)
2nd - 30s (80% black frames)
3rd - 12s (only few frames visible, the rest is black)

With Smart render cache:
1st play - 24s (approx 10% of frames visible, rest is black)
2nd - 24s (few frames visible)
3rd - 24s (few frames visible)

When cursor is randomly placed on timeline, if the that frame was black during playback, remains black. Doesn't show preview.

So, in my case, too many bottlenecks to review the app properly. GTX 275 with 850MB VRAM and 7200rpm 1TB HD is OK for H264, but not in this case. Let me know if I can help in some way, but I think my results are not representative because of hardware limitations.
#19
Raw Video Postprocessing / Re: MLVFS windows client
September 18, 2014, 10:02:30 AM
I'll give it a try later today. Thanks.
Everything that might have reduced performance was off, as far as I remember.
#20
Raw Video Postprocessing / Re: MLVFS windows client
September 17, 2014, 11:55:21 AM
I cleaned caches and mounted MLVFS again.
Without render cache in Resolve, it takes 50 seconds to play 10s MLV clip for the first time, 44 secs for the second time. But second play keeps the same omitted frames pattern as the first one. Now it takes long to render frames at the beginning, then more or less in the middle longer black gaps appear, and last third of the clip plays black.

With Smart Render Cache, after waiting for clip to be cached, it takes 22 secs to play it. But again, black or omitted frames seem to appear in the same moments, like when Resolve cache was disabled. Second play looks the same.
#21
Raw Video Postprocessing / Re: MLVFS windows client
September 17, 2014, 10:50:17 AM
I checked the last version and I'm afraid you need feedback from someone with a higher-end editing station, to reach some conclusions.

Now, with default values, I get only flashes of single frames on timeline, the rest is skipped. HD spins like crazy, obviously can't deal with so much data. I didn't try to change the caching parameters, yet.
#22
Raw Video Postprocessing / Re: MLVFS windows client
September 16, 2014, 11:09:17 AM
It is faster, indeed, however now I have more skipped (black or blank) frames during timeline playback. Seems that hard drive can't write data fast enough (disks not in RAID).
With previous version there was maybe 4 or 5 black frames in total, now it's like 20% of all.

Again, this comp is far from being an editing machine, so just want to confirm that everything seems to work as intended  ;)
#23
For those who don't realize how much work, knowledge and own "free" time devs like Alex, g3gg0 and others put into this project and free apps connected to it, just take a look here and use "Next" button. It's really eye-opening:

https://bitbucket.org/hudson/magic-lantern/commits/all?page=6

And now imagine that there's ONE greedy f***** who sabotages the whole project by leeching on it.

I'm just... I don't know. What kind of... person one has to be to not respect such effort and people behind it?!
#24
Raw Video Postprocessing / Re: MLVFS windows client
September 15, 2014, 04:51:51 PM
Short feedback after installation: the tool works (what kind of wizardry is this?  ??? ).

Playback in Resolve is choppy in my case - I'd say around 0.5 fps, but it's most likely because of suboptimal hardware platform (i7 920 @2.66, 6GB RAM, W7 64).
Attempt to open MLVs in Premiere ends with "File format not supported" message.

Didn't experience any problems during setup process.
Thanks a lot, g3gg0.
#25
Nice work.

What maximum ISO did you use?