Messages

I just tried the new version 1.1.3 of MlRawViewer, exported a couple of DNG sequences, and then imported the DNG sequences into Premiere Pro CC.  Unfortunately, the highlights are pink, making footage unusable in Premiere unless there are no strong highlights in the footage.  I tried both MLV and RAW files and both had the same issue.  I can send you sample DNGs exhibiting this issue if you find it useful to your development.  You are soooo close to providing a post processing tool that allows working directly with the DNGs in Premiere.

When I use the "A" key to desqueeze my 1920 x 672 (60p) footage, the 1.4x de-squeeze is not enough to reach a vertical height of 1080.  I believe you would need a 1.61 (1.6072 to be more precise) vertical stretch in order to bring the vertical height from 672 to 1080.  Would it be possible for you to add 1.61 as another vertical stretch factor when toggling using the "A" key?

An updated build.  This one comes with the same warranty  as the last build.


https://dl.dropboxusercontent.com/u/34113196/ML/Builds/magiclantern-v2.3.NEXT.2014Feb11.5D3123.zip

Does this build include the pink frame fix Alex recently implemented?

Looking forward to it!  I just voted up batch encoding and browser file listing in Bitbucket, as well as Log output.  With that combination of enhancements, this would likely become my goto post-processing workflow... bye bye After Effects. 

The current code in git should pass the frame rate from the source file to the encoder, but only the Mac 1.0.3 DMG binary includes that - not the current windows binary - and I have to admit I haven't tested it with 23.976. If you are using Mac, upgrade to the 1.0.3 to try that. If you are using Win, you'll need to wait for a new installer or install from source.

Will the next release you are working on contain the new installer for Windows that supports Prores output encoding to 23.976?  This is the only thing preventing me from utilizing the encoding capablility.  Also, will there be a way of batch encoding a group of files, such as all the files in a folder (I'm a windows user)?

well, the tv is in a different room which makes it hard to do some tests.

I wish I had an extra HDMI monitor to send you... I definitely would    I appreciate all your efforts though.

the hdmi bug is confirmed, but its hard to debug it. I just have one hdmi monitor, that's the,one on my PC.
need a small screen, some like you use.

I just tried connecting my 5D3 to 2 different TVs which have HDMI out (both a Plasma and LCD).  The same exact 2 issues occur on both TVs as well (crashing on exiting playback & offset image).  Doos your TV have an HDMI port?  Hopefully, you would be able to recreate it that way without needing a specialized HDMI monitor for cameras.  Just trying to offer suggestions that might yield a solution to this issue.

I recall that the first version of MLVPlay you put out that supported HDMI playback did not crash, only later versions introduced the crashing upon exiting playback.  I'm not sure exactly in what build when it started however.

If you are using Win, you'll need to wait for a new installer or install from source.

I'm running Window 7 64bit.  It always outputs 25fps, even though my source files are 23.976.  I understand why now.   I guess I'll wait for the new windows installer.

It would be possible to up-scale the content when encoding, but I suppose we aren't 100% confident right now that we know the correct scale factors for all cameras so that this could work reliably automatically.

Thanks for the clarification.

Awesome viewer!  The performance and quality of playback is really amazing.  Is there a way to change the encoding output to 23.976 fps?  If not, is this something that is planned?  Also, are there plans to allow vertical scaling of the prores output to unsquash 50/60p files?  Again, well done!

update:
- added mlv_snd which adds audio recording to mlv_rec

Great work g3gg0!  I just tested this and it worked very well... I had perfect sync when post-processed.  I only recorded 25 seconds so I'll try to record something much longer to test that sync is maintained for an extended period.

can you test the next nightly build, if it works with .raw as expected?

Yes... playback of last recorded file now works well with .raw

It still often crashes often exiting playback mode when using an HDMI monitor.  I have been trying to recreate this, but so far, it seems to occur randomly.  When it happens, it always requires taking out the battery.

added playback of last recorded file and some progress bar when creating an index.

Just tried this with raw_rec using the latest nightly (commit 9d367a5) which included these new changes to mlv_play and raw_rec.  Pressing the Canon play button no longer lauches mlv_play.  I just get the "No Image" message.

Also, can you upload an updated pre-built mlv_rec file?

added playback of last recorded file and some progress bar when creating an index.

This is very helpful.  Another suggestion would be to allow navigating past the last recording and continuing to the first recording.  And the same behavior if navigating in the opposite direction.  On a 64gb card I often end up with 40+ short video clips and this would make it much easier to navigate through lots of footage.

[5d III crashes every time I want to exit the playback.]

By the way I tested HDMI, it has got really bad...
1) 5d III crashes every time I want to exit the playback. I have to pull out the battery.
2) There is overlay "no image" bar again that overlays the playback.
3) The weird lines on the top and bottom of the frame are now colored and have some strange flickering with strange  pink blinks.
4) There is the offset toward the left side of the screen of overall playback window.

I am experiencing the same exact issues for all the points you listed.  Using 5d3 as well. The crashing while exiting playback being the most problematic of course.  Regarding the image being offset, this makes it difficult to judge if I nailed composition.

@ chmee is it possible to incorporate RAW2GPCF.exe into raw2cdng or the upcoming mlv2cdng?

+1... This would be ideal.

Now with the play button being assigned to playback mlv files, was the function to select/deselect individual files in the file browser reassigned to another key?  If not, can it be?

Makes sense. Sometimes obvious escapes me. 

I'm not sure if this is helpful, but here's a short iphone video demonstrating the HDMI playback issue others have observed (5D Mark III, SmallHD DP-4)...

On first playback, the no image message blocks the display.  If you switch to another clip using the top dial, it clears up the "No Image" issue but the image remains cut off on the left side and offset.

Also, the playback speed drops dramatically compared to in-camera playback.  You can get a sense of the playback speed in the video example.

Will test tonight on my SmallHD monitor and report back to you.

thanks for testing

I just tested mlv_rec for a couple hours.  I noticed the following on my 5D Mark III and using my SmallHD DP-4 HDMI monitor...

- Playback via HDMI crashes
- Crop mode does not work via HDMI when Memory Hack is enabled. It doesn't crash, it just stops right away.  I always need Memory Hack enabled to achieve a usable number of frames for 29.970 or higher framerates.
- Corrupt/Pink frames occur when fps are set to 29.970.  I typically get 1 to 2 bad frames on at least half the clips I shot (I shot at least 50 clips).  I use 29.970 for at least half my work.
- The good news is that when Canon fps is set to 60p mode, I get no bad frames.  I tested both 48fps and 60fps.  I guess the last update you released really helped with that.
- 16:9 black framing bars at top and bottom disappear when recording starts.  These are the built in canon ones.
- If you set Global Draw to OFF (within raw settings), when you stop recording, global draw stays OFF (even though it show GD is on in ml menu).  I needed to reboot camera to restore GD.
- Card spanning doesn't seem to offer much improvement though in past versions I had tested, it had given a much better better improvement in frames that could be recorded.
-The new mlv_play features which link playback to the Canon play button is much appreciated and works well when used without an HDMI monitor attached.  Since I have personally committed to using ML raw for many of my profession projects, I cannot stress enough the importance of workable HDMI functionality for professional work.  Up to now, I have been using workarounds for issues like playback crashing the camera, by unplugging the monitor to play back footage.  It really makes it hard to work this way when on a project.  I have thus far resisted switching to the MLV format because performance isn't as good and rec_raw (though improving). 

Wish list
- More performance when shooting 29.970.
- Recording indicator settings to match raw_rec would be great (small recording icon without distracting status verbage).
- A beep when recording begins would be useful

I'm happy to help test MLV on the 5D3 as much as necessary if it helps MLV become a bit more conducive to production work.  Thank you for all your efforts g3gg0.

did you try it?
the whole effort of the ML crew (in total literally 0,5 full time devlopers) is useless if there is no testing from those who have the setup

I can confirm that playback always immediately freezes the camera (Error 80) when using an HDMI monitor. 

I have just tested the latest build of MLV and found a few issues issues during my brief tests.

On 5D Mark III (using a SmallHD DP-4 monitor)
- playback via HDMI crashes
- some pink/corrupt frames (I still need to confirm which framerates this occurs most often).
- crop mode does not work via HDMI when Memory Hack is enabled. It doesn't crash, it just stops right away.
- 16:9 black framing bars at top and bottom disappear when recording starts.  These are the built in canon ones.

I will perform more extensive tests tonight and report back to you everything I found.

Using Usb 3 Lexar card Reader (w/UDMA 7 firmware update):

And here's the strange result I got w/CrystalDisk Mark;  sweet baby Jesus 137mb/s!!

This is the first I see someone show these type of CF write speeds benchmarked via CrystalDiskMark.  Are you getting this consistently? Curious to know the source of the bottleneck since the DMA controllers (EDMAC) are capable of 700 MB/s.

@MA Visuals,

oops, Sorry I wasn't able to reply to your question and request.
No I did not perform extensive tests outside the camera as the Card is very picky with card readers, more than the 128gigs. The 256 from KB at the time of testing was only compatible to transcend and lexar usb 3 CF readers. I did a limited testing with a friend who had the mkIII and a transcend reader but only to format the card, install ML and do benchmarks on his mkIII.

Upon realizing that the major cameras that use ML (mkII,mkIII, 7D) can't support more than the 128gig versions of KB cards, I was no longer interested in pursuing further testing.

Even when you format the 256 as 256gig, the camera can't record more than 128gig worth of data on it.

The moment you perform an in-camera format it reduces it to 128.

I saw no benefit using it so I sent it back already.

Thank you Ted.  For the price vs your tested performance, I would have returned it as well. 

That's actually very good news since it's no longer established that the camera is the limiting factor.  There is a possibility that the sustained write speed of the card you tested was just very similar to their other cards.

Regardless of what Canon literature says, this doesn't seem to be reflected in real-world tests. 1200X CF cards clock in higher than 100mb/sec write speeds with test apps when connected to a computer through a USB 3 CF reader, yet on the 5D3 they can't get anywhere close to that.

What is going on?

May I ask where have you read that the cards tested faster via separate test apps?  I've only seen screenshot results of those type of tests coming from Komputerbay themselves.  I had asked Ted Ramasola if he tested externally using a utility such as CrystalDiskMark but I didn't receive a response, so I'm still unsure if the camera is the limiting factor or the just that the cards themselves are not performing anywhere near their claimed write speed.

Could you please do a benchmark write test on your 1200x using a USB3 card reader and a software program and compare the results of that to a 1000x card in the same test so we can really understand if the camera is a limiting factor here?

+1

This is critical to gaining insight as to whether the camera is the limiting factor or not.