Messages

Processed a number of std and mlv_lite mlv files through v1.7.5.

All files processed successfully. No lost frames and spot checks of various frames showed no abnormalities.

@Walter,  thanks it works a treat. I was just doing it back to front.... must be getting old and senile.

A couple of questions re: raw video recording (MLV and MLV_lite) on a 7D using the latest 24/02/2016 nightlies if I may.

With either of the raw video modules I'm no longer able to select resolutions above the 7D's rated maximum of 1728 x 972. I can highlight them but they won't select. From memory I've been able to do this in the past and capture a few frames before the buffers overflowed and the recording crashed. I'm using 128gb KB 1000x CF cards tested at a continuous write speed of 110 MByte/s so they should be capable of handling anything the 7D can throw at them.

Also, with either of the raw video modules enabled and before starting recording: I am able to enable both 5x and 10x crop modes. 5x crop mode works fine however when I press record start in 10x the message "Raw detected error" or "Raw Defect error" flashes up and disappears really quickly and the recording fails. A 1kb mlv file is created for each attempt.
Is this potentially a bug in ML or is the 7D not capable of 10x crop recording?

I don't do a lot of video but I was trying to generate variety of test MLV_lite files with as many different capture settings as possible. I'm reasonable certain that I have done both of the above scenarios successfully in the (distant) past and was surprised when I couldn't do them today.

Any thoughts, enlightenments, guidance will be much appreciated. If I need to log a bug report just point me in the right direction and I'll get that done.

Thanks in advance.

Tested MLV-Lite again today to see if the current version of raw_rec.mo still generates errors when mounting in mlvfs.

I generated a variety of MLV_Lite generated files that included single/multi-chunk mlvs, auto stopped mlvs due to frame skipping and one crash mlv when it tried to switch from 5x to 10x whilst it was recording. it was 41degrees C in the shade today and I got my first ever camera overheat warning so rather than risk harming the camera, I didn't test to see what happens when the card fills up.

Happy to report that there was no repeat of the error messages or bad frames reported in my previous tests.

Camera is a 7D

Put MLVFS through its paces again today with a variety of MLV_Lite generated files that included single/multi-chunk mlvs, auto stopped mlvs due to frame skipping and one crash mlv when it tried to switch from 5x to 10 recording. All good, no bad frames that I could find and no error messages in the mlvfs cmd window.

Camera is a 7D.

@dmilligan

A promising result from Dane.  Will rerun tests on my 7d when I get back home (2 days).

@Dmilligan

A big thumbs up from me as well for your Windows version.

I've been giving it a solid try out during the mlv lite testing and love the on the fly the processing.

Took me a while to figure out that that I had to set the parameters before opening the Dokan mounted file. [Facepalm].

@Dmilligan

Great explaination for what is happening in the file structure.

From my testing,  the common activity that the working tools e.g.: MLVFS and MLVP have is...

They prebuild an index file that is used to access the individual frames.

Unless it is building it in ram, mlv_dump doesn't seem to do this.

Might be another option to consider if changes are needed for mlv_dump.

["Not Existing"]

@Danne  @Dmilligan

5)  Via the Dokan v1rc mounts I can successfully import the DNG's into my Photo and video editing applications. A quick visual scan of the individual frames didn't spot
     any bad or pink frames.

Correction to the above.  Upon closer inspection I found that for the recordings that were in progress at the time that the CF card ran out of space: the last frame of each was corrupt.


I processed all of the multi-chunk mlvs and a couple of single chunk ones through mlv_dump. The tests resulted in a mixed bag of outcomes.

At launch, mlv_dump listed all of the available file chunks to be processed but listed the next logical one in the chain as "Not Existing" Ref: to the linked screen shots for examples. I suspect that this is standard mlv_dump behaviour.

A number of files failed to process all of the available chunks with a common error message:  ERROR VIDF: File ends in the middle of a block

The following links are the mlv-dump screenshots for the files related to the recordings that were in progress at the time the CF cards ran out of space. Both of these files suffered the above error however, it was on the last (and corrupt) frame that it occurred.

M18-1704.mlv and last file on the 8gb card:      http://1drv.ms/1oO2276   1 Chunk, 1399 of 1400 frames processed
M18-1856.mlv and last file on the 128gb card:  http://1drv.ms/1Qpej7U    9 chunks, 13508 of 13509 frames processed

The following links are for files where mlv_dump failed to process all of the available frames.

M18-1658.mlv:  http://1drv.ms/1oO2rXh     2 chunks, only processed the first 3276 of 4050 frames before erroring out
M18-1805.mlv:  http://1drv.ms/1oO2Rgh     3 chunks, only processed the first 1458 of 44214 frames before erroring out

The following links are for files processed through mlv_dump that processed error free.

M18-1655.mlv: http://1drv.ms/1Ktv59V         1 chunk,    1031 frames processed
M18-1808.mlv: http://1drv.ms/1oO37fd       16 chunks, 23150 frames processed
M18-1826.mlv: http://1drv.ms/1XATnR8        1 chunk,      601 frames processed (fps 1 frame per second)

I was running multiple instances of mlv_dump. To verify the results I re-ran a number of the mlvs with a single instance of mlv_dump running and got the same results.


My thoughts are that mlv_dump is not able to handle the mlv_lite files that had skipped frames or where the mlv_lite file closes abruptly due to things like non default resolutions and high resolution crop mode.

Cheers... Otto

@Danne

I haven't tried this. I'll give it a go in the morning and report back.

MLVLite Tests
--------------------
Camera:   7D
ML Build:   magiclantern-Nightly.2016Feb13.7D203
raw_rec.mo  (2nd lite build)

Cards used: Sandisk Extreme III 8GB 30MB/s
                  KB 128gb 1000x

PC:    ASUS Intel i5 quad core laptop


Tested with:
    -    Default raw resolution with continuous recording to generate spanned file mlv, m00, m01... etc. The longest went to m14.
    -    Some alternate resolutions
    -    5x and 10x crops
    -    fps override
    -    ettr "always on" for all tests
    -    global draw off for all tests
    -    kept recording and creating files unill both cards ran out of space

General observations

1)    When in 10x crop mode recording failed to start when pressing the record start button.
       There are 14 MLV files (M18.1841-1855) created with a 1kb size and in the same time window there is a file called backup.raw 512kb that was created. I believe
       that these files are all related the 10x recording failure.
       Whilst pressing the start record button, I ultimately managed to observe the following message that flickered onto the screen after each button press:
                  "Raw detected error".

      Link to backup.raw file: http://1drv.ms/1R9MEeo

2)    When the card ran out of space the following occured:
      :    The message "Movie recording stoped automatically, Data corruption @slot nn, frame nnnnn (where nn  is a numeric number)
           This message appeared a few times before ultimately staying on screen. The frame number changed for each occurance of
           the message, can't remember whether the slot numumber did.
      :    The CF access LED remained lit.
      :    I pressed the stop recording button, waited a bit but nothing changed so I powered the camera off (the LED stayed lit).
    At this stage,
      :    for the 1st (8gb) card, I removed and reinserted both the battery and the CF card (thnking that the camera had frozen).
           -  Powered the camera backup and receive a message that the camera had not been shut down correctly. Otherwise the camera
              booted normally, including ML.
      :    for the second (128gb) card I just powered the camera backup again.
              I received a "CF Card is Full" message, however the camera booted normally, including ML.
      :    I was able to copy all files off the CF cards to my local harddrive.

    From this, my inital observation would be that for the 7D at least, running out of space whilst recording will not brick the camera
    or corrupt the CF card.

3)  With the exception of the 1kb size MLV files all of the others mounted without error in MLVFS.

     localhost view:   http://1drv.ms/1Lv3NLp

     CMD Lin view:   http://1drv.ms/1Lv3TlY

4)  Excluding the 1kb size MLV files all of the others successfully loaded into and played in MLVProducer (version: mlvp.alpha.build2224b.INTEL)

5)  Via the Dokan v1rc mounts I can successfully import the DNG's into my Photo and video editing applications. A quick visual scan of the individual frames didn't spot
     any bad or pink frames.


Let me know if there are any other specific tests that you would like me to do.

3. What happens when card runs out of space?

Just a thought, that could also be applied to mlv_rec.mo.

When enabling the module, why not:
1.     check the available space on the card
2.     calculate how many minutes of recording time is available based on the resolution and crop mode set at the time of pressing the
        start recording button. (Max recording)
3.     reduce the calculated available time by say 1 minute (to maintain some free space overhead) - (Allowed Recording)
4.     display this on the screen with a continue y/n? option.
5.     Automatically stop recording when the allowed recording time has been reached.

I think that this would allow the MLV file/last segment to be closed correctly thereby eliminating the number of "Card full" issues raised with MLV recording. Step 4 would give the operator a chance to clear space on the card or swap it out for a larger capacity one if the allowed capacity was insufficient for their needs and/or rethink their filming strategy to work around the space constraint.

I use komputerbay 128gb cards without any issues.

@jogodedentro

2nd link in my original post to you.

@jogodedentro

I had problems with a flaky Visual studio Redistribution 2015 runtime library install that was causing the application to fail.

The problem was fixed by re-installing all of the MS redistributable runtimes via the package advised to me by Licaon_Kter in the following post:
http://www.magiclantern.fm/forum/index.php?topic=13152.msg162133#msg162133

The following post contains guidance by Mothaibaphoto on how to run it.
http://www.magiclantern.fm/forum/index.php?topic=13152.msg162127#msg162127

There is a wealth of information within this topic that will help with your understanding. My suggestion, if you haven't already done so is, read the 1st couple of posts and then as the Windows developments are more recent go to the last post and work your way backwards.

A small tip, If you have already installed dokany and MLVFS open a cmd line window. Then:

for Dokany - cd /d C:\Program Files\Dokan\DokanLibrary
                   dokanctl.exe [enter]
and

for MLVFS - CD to wherever you have unpacked MLVFS to
                  mlvfs.exe [enter]

Both applications will present you with a list of applicable parameters.

Hope this helps.

@dimilligan.... Thanks

A possible bug and some questions please.

Today I have launched MLVFS_x64_avx to a local directory containing a single MLV file mapped as drive X: All is well as confirmed via the localhost:8000 view in my browser.

     http://1drv.ms/1o7Mtqk

While I was randomly viewing individual frames (by double clicking on them) I noticed in the MLVFS cmd screen a number of loadchunk error messages. These related to mlv files tested yesterday that reside in a different (external HD) location. This suggests that MLVFS is storing previously analysed MLV file names/details somewhere. In itself, these error messages are not an issue however from a performance perspective MLVFS probably shouldn't be trying to open MLV files other than those in the mapped directory.

    http://1drv.ms/1o7OHpy

Edit:
  The generated errors messages may have been my fault. I had originally launched:
      mlvfs_x64_avx2.exe X: --mlv-dir=H:\Video\20150825_Banff_Surrouds\MLVs (where the 4  MLVs related to the error messages reside - it crashed),  I then launched

      mlvfs_x64_avx.exe X: --mlv-dir=D:\MLVs (where the single MLV resided)

  As there was no appreciable delay between the crashing of the mlvfs_x64_avx2 instance vs the launching of the mlvfs_x64_avx instance it suggests that maybe I should
  have waited a bit longer to allow the first instance to clean up after itself.


Questions

Where does MLVFS store details of historical MLVs processed? (Maybe irrelevant).
Configuration options set in the localhost view don't appear to be persistent. Is this the expected behaviour?
Having set the configuration options in localhost at what point will they apply e.g: on the fly upon opening, viewing  or extracting the frames?
MLVS caters for a number of parameters:
     - what are the defaults settings?
     - what the purpose of --port and is its sub-parameter a directory name or port number (or both)?

Possibly the above questions could be answered by adding a little more commentary to the options list provided when running MLVFS without parameters.
     
      http://1drv.ms/1TgUrdK

Thanks in advance.... Otto

@g3gg0

Thanks. Absolutely correct,  I just didn't wait long enough to observe this.

@mothaibaphoto  @g3gg0

Thanks for your replies. I've got it working albeit I'm still driving it manually via the cmd line. I'll set-up the batch file and figure out how to point the application to my web browser after I've had some zzz's

One thought/suggestion: I've had to manually run dokanctl to unmount the mapped drive (i.e.: X) which in turn automatically closes the MLVFS application. However, if I exit the MLVFS application via say ctl/c then I'm unable to unmount the mapped drive letter via Dokanctl.

Does MLVFS monitor for a hidden/undocumented "quit" command that would send the unmount command to DOKAN and then gracefully exit MLVFS? or is that part of the web GUI that I've yet to figure out how to set up?

Other than that, fantastic job porting this to windows to all involved. I've successfully tested it with normal and FRSP mlvs. I use Cyberlink photo and video editing software and both happily imported the dngs from the mounted mlv's. one less step in the workflow. Who could complain about that.

Will play some more with the optimized builds tomorrow. mlvfs_x64_rc_avx2.exe crashes but mlvfs_x64_rc_avx.exe seems to work.

Tomorrows another day.  Thanks again gentlemen.

@g3gg0

I have ben watching this thread with interest for some time now and decided to try mlvfs.

My Gear:
---------------------------------------
CPU:            Intel i5-3317U quad core
Ram:           6GB
Graphics:     Intel HD 4000
OS:             w10 Pro 64bit updated with the most recent patches.

I did have Pismo file mount for Windows installed but uninstalled it to avoid any potential conflicts with DOKAN.

The initial installation of DOKAN (v1) displayed the following message;

     http://1drv.ms/1WfsIs3
    (note the screen shot was from v0.800 but apart from the version number in the message, the message was the same).

I clicked "YES" then proceeded to download and install MS Visual C++ - Redistributable (x64). It installed without error.

DOKAN v1 appears to have installed correctly as verified via the cmd line screenshot below.

     http://1drv.ms/1KGNvnA
     Note: version was checked before and after manually starting the Driver and network service. Given the absence of error messages I
              assume that this is working correctly.

When I try to launch MLVFS.exe I initially had errors re: vcruntime140.dll and msvcp140.dll not found yet both of these files were in the C:\Windows\System32 directory. Based on some google research I moved copies of these files into the C:\Windows\SysWOW64 directory.

Subsequent to this the "dll not Found" error messages no longer appears but the following one does.
     http://1drv.ms/1KGO0xG

I acknowledge the error and the application fails to launch. Note that I have tried to launch it at the cmd line level with the same results.

Any thoughts, ideas? Is there an architecture dependency (e.g.: graphics card) that I'm missing?

Edit add;  If I run dokanctl.exe from the C:\Program Files\Dokan\DokanLibrary directory it appears to work correctly. However,
                 If I run it from the C:\Program Files (x86)\Dokan\DokanLibrary directory, it fails with the same error as mlvfs.exe.


Might be a clue to what is going on.


Cheers... Otto

@brawl

I'd suggest a variable ND filter. google or search ebay for a variable nd filter for your lens. (58mm for the standard kit lens that came with the 7D).

it is also extremely useful for capturing full frame silent pics during in bright light environments.

@zachgoodwin
So what did you do with the screw? Put a shorter/longer one in or something else?

A detailed explaination may help others with a similar problem.

What happens if you turn the camera on without a CF card inserted?

@AWPStar

In MLVP.test.build2164.INTEL version I am able to browse and choose a colour LUT on the filters menu however the selected LUT does not get applied. Selected LUTs were either *.cube or *.3dl type.

Any chance of making the scrollbar for the scrollable tools a bit thicker/wider. It can be a bit of a challenge to pick up the slider or line up the pointer within the slide channel. More often than not I pick up the edge of the tools frame instead of the scrollbar.

Whilst on the tools, has no impact on the actual size/presentation of the tools themselves. Personally, I'm happy with the default sizes and don't there is a need to be able to stretch them. Maybe this is something that can be disabled. It might make the scrollable tools a little less hit or miss.

@AWPStar, Enjoy your drunk days