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 - MGerard


Quote from: a1ex on May 22, 2014, 10:06:33 PM
We have 40 fps in 1080p RAW, test it out!

Tests needed:
- push FPS to the maximum values and make sure you can record safely in RAW, MLV and H.264. If there are artifacts, that's a bug.
- try all the video modes (1080p, 720p, 480p, zoom, photo...)

Tried it out very quickly with the latest Nightly, 1080p h264 seems to work at max fps so far, camera movement (panning) results in freeze frames.

Thanks for unlocking yet another marvelous possibility!
Thank you very much for the comment. There is indeed a slight difference when using custom bitrate & quality settings, but it's quite unstable (camera crashes with error and needs to be restarted). All the internal shots were done that way (ipb 55-100 mbit/sec). There is a difference concerning compression artifacts, but nothing that justifies crashing the camera. All the externals were all-i but decoded to prores via 5DtoRGB which makes an amazing difference. There is some post sharpening on the final footage to give the impression that it was shot with a true hd camera ;).
Hi there,
I recently shot a report for a local TV station about a concert on the 1st of May that I would like to share with you. It was shot using ML's custom H264.ini settings.



Quote from: troy_e on May 07, 2014, 01:58:45 PM
MGerard, what is the difference between the 50 and 70 files you have created? Are they just the Mbps?
No, the settings are completely different. If you want to, the zip file should still be available for download until tomorrow, so you can take a look at the inis. Else, just send me a pm and I will mail them to you.

Quote from: Audionut on May 01, 2014, 08:59:16 AM
Explain steps to reproduce the problem, consistently.
I should be able to follow your step by step guide, and reproduce the problem.

For instance, "a small chance of crashing when changing the angle", is pretty poor bug reporting.

Thanks, and thanks for the zip.  Will take a look at it.

Thank you for your answer, the steps when proceeding to film by using a higher bitrate via the utilization of H264.ini are the following:

- switch on camera
- load H264.ini once ML has bootet, wait for the on-screen info about this process to disappear
- start the recording
- stop the recording

Now it comes to the hefty part: When pressing record again, there is a high chance that the Err70 pops up, recording stops, mirror flips back and the camera needs a proper reset (pull out and re-insert battery). This happens sometimes but not all of the time, which is obviously annoying.

I am totally aware of the fact that my explanations are not sufficient for a proper "bug report", but then, again, the error seems to happen on a random basis (?), so we might need to approach the problem from a multiple perspectives.

Is it related to stressing the encoder or is it related to the implementation of the "load h264.ini" option within ML? [I have been filming an event last night for TV with higher bitrate and there are no obvious errors in the playback of the material, which I would interpret as the encoder being able to deal with the settings]

Might there be any part of Magic Lantern that is utilizing resources that inhibit the encoding and streaming once the bitrate is higher than standard?

On a different turf, the question might arise why we need a bitrate improvement for h.264 capture now that we have the incredible possibilities of raw recording:
As you may or may not have seen in the zip file I put online in the morning, a comparison between uncompressed 422 hdmi out and standard h.264 capture was included. What can be seen is that a) the uncompressed hdmi out contains the same color information (only spread over a 422 bandwidth) but b) without the macro-blocking of the onboard h.264 compression, which, from my point of view, increases the clarity and "perceived resolution" of the recorded material.
Onboard encoding at a higher h.264 bitrate will give a similar result (or at least a tendency towards it) which will be beneficial for 5D3 film recordings in situations where raw is not an option.
In my case it is uncertain whether or not the camera stalls when using those settings.

You can download a ZIP file until the 8th of May here: It includes the .ini files, cropped framegrabs and one of the error logs. Please switch the 5D3 to IPB mode first.

What you can see in closeup detail is the lesser blocking which greatly improves the "noise appearance" of the overall "motion picture" and should add clarity (please also see the comparison of standard h.264 recording and Prores HQ via uncompressed HDMi out). If anybody could come up with a solution for the error 70 it would be heartily appreciated. Have a nice day!
I found some usable settings for the h264.ini that give a small but noticeable differences in the clarity of the picture (on the 5D3), meaning less blocking.

Unfortunately, as reported before, there is a great chance for error 70, especially when pressing record again after the first recording. It seems to me that changing the image itself, altering the angle etc. gives a small chance that the error 70 will not happen. Maybe it has to do with some buffer not being cleared before the recording starts or something like that - reloading the .ini also gives a greater chance that the error will not happen, but that is pure speculation on one side as it happens or not... It would be cool if some devs may take a look at this problem.

If anyone wants to see the results I got, please PM me.

Thanks in advance!
Shoot Preparation / Auto-load h264.ini
April 30, 2014, 10:51:19 AM
Is there a way to load custom h264.ini settings directly on camera start for the 5D3? Maybe this topic has already been dealt with but I was not able to find any relevant information in a search. Thank you very much!
General Help Q&A / Re: Mark III and ML
April 28, 2014, 07:42:38 PM
I have work experience with the 5D2, 5D3 (which I own now) and the 7D:
The 5D3 uses binning instead of line skipping to downsize the sensor resolution to HD, which reduces moiré and aliasing by an incredible amount. There is some aliasing in overblown highlights which is a problem that all single large frame sensor cameras share (including the Arri Alexa), but there are ways to get rid of that in post.
Except for a lack of resolution in comparison to the C100 / C300, which also operate in an 8bit color space, the 5D3 is a capable video camera, probably the first DSLRs really made for it. Apart from that the audio circuitry is also much better than the 5D2 (if that would matter). What might improve the resolution a little bit is to tweak the h264.ini settings with ML. Mine is stable (also on complex scenes) recording at an inter-frame data rate between 69 - 120 mbit/s, and there is a definitive increase in detail, especially when sharpening is applied in post. In addition, you could also use a cheap external HDMi recorder (like the soon-to-be-available Ninja Star by Atomos) to record from the "4:2:2 uncompressed" HDMi out, but apart from getting rid of the h.264 blocking, it doesn't really give you anything "more" color- or resolution-wise.

When it comes to ML raw recording is where the 5D3 really shines (again, more detail and of course high color depth). Recording at (true) 1080-25p is possible with the right CF cards. In total, the image quality blows away the C300 and the 1D-C. But that comes at the price of a more demanding / time consuming post workflow. 

In my opinion, an upgrade to a well-tweaked 5D3 is way worth the cost.
Quote from: EXIV on April 24, 2014, 02:17:27 AM
Hi, I adapted the raw footage in order to get the same exact size, in order to make it easy to compare the quality. And then I offered this downloadable sample so everyone who is interested can see how is the original footage I worked with. Hope this helps. Take care.

Hum, I really don't know if downsizing the raw size actually is a good quality comparison. What I really like about ML raw (apart from the color depth and grade-ability) is the incredible increase in detail when compared to h.264. It gets rid of that "blurry" look that is, by the way, also there when you record externally in 4:2:2.
Extremely impressive, great work and good music!

Quote from: poromaa on April 23, 2014, 08:51:31 AM

I will try to get hold of a Sandisk Extreme Pro 160MB/s (their fastest with write-speed up to 150MB/s) today. This card has something they call VPG65 which means video performance guaranteed at min 65MB/s, so I believe this will max out my camera.

I will come back to this thread to report my findings.

As reported on some other threads on this forum, I am using these cards with my 5D3 and they are capable of writing speeds between 80-105 MB/sec. You won't be disappointed by the performance of these CF cards.
Is the card you're talking about a SD card or a CF card? In any case, the card will very likely not be suitable for sustained 1080p capture. CF cards, in general, perform better at the same writing speed indicated. If the hack doesn't work out for you, you can always remove the card and work with the standard firmware. Regards.
Thank you very much for posting this! Excuse me for asking, but why does your comparison not show the resolution difference between raw and h.264? When I compared the two different recording modes at 1080p, there was a noticeable difference in actual frame size. I feel puzzled  ::)

Quote from: DavidSh on April 22, 2014, 02:46:20 PM
Thanks MGerard,
So Is there other brand 128 Gb size that can handle 1080 24p?
I am using SanDisk Extreme Pro 160MB/sec. Those are extremely reliable up to 1080 25p but they aren't cheap either. At some point, you get what you pay for.
Quote from: DavidSh on April 22, 2014, 02:02:49 PM

Can you tell me the number of minutes i have with 1080p 24fps+audio on 64gb?

You should get something between 10-12 minutes with these settings.

I had a number of Komputerbay 1000x / 1066x 128 GB cards here to test but none of them was remotely capable of continuous 1080 24p recording.
Raw Video / Re: 2014: NEW Current Raw Capabilities
April 22, 2014, 01:34:06 AM
Just out of curiosity... am I the only one who gets much more stable results (0 skipped frames @ 1080-25p) with in-camera FAT formatted CFs? Just came home from a job, no problems at all. A while back I tried the same thing with the same CFs and ExFAT, and I had a lot of errors due to skipped frames...
Raw Video / Re: 2014: NEW Current Raw Capabilities
April 21, 2014, 02:08:58 AM
@filmkid7 ... did you try out formatting the card as FAT? Even though I do not know exactly why, it worked like a miracle on my SanDisk CFs...
CF, thank you very much for explaining and elaborating on the mathematical terms Andy from Cinelog is using. Still, did you know that Canon, for example, have implemented an exponential gamma curve inside the 5D3 that does not give us true Rec.709 (but makes the images look "nicer")? And you clearly know what happens if you plot a logarithmic curve on an exponential one ... that will, by no means, result in a "true logarithmic gamma curve". That is, nonetheless, how other products marketed as "log color space" work. What Cinelog does is something different, hence the word "true". At this point I need to underline that I am not affiliated with Cinelog in any way. I am just using the product daily for processing footage I obtained via my 5D3 rig and the unbelievable possibilities (in regards to picture quality) that ML raw gives us, and especially Cinelog for Resolve is a huge step up in usability and time it takes to achieve professional results fast. Instead of spending hours on end waiting for ACR to do its job or trying to fix the look we get via other (respected) possiblities via Resolve, Cinelog speeds the workflow up and gives results that can be intercut with more expensive (true Rec.709) image capturing devices.
That applies only when you are not using Cinelog for true Rec.709 or LogC conversion of ML RAW.
I tried out Filmconvert on LogC footage from Resolve/Cinelog, but it doesn't look so promising. Also doesn't look so good on original Alexa material (you can easily find different types of Alexa demo clips on the web) - please correct me if I'm wrong. The safest bet is to use it on top of the finished primary CC with the Default/sRGB profile.
Hi, I took some time yesterday to make a quick tutorial about my Cinelog / Resolve workflow.

Please enjoy.
While the latest nightly build seems to work fine (no error msgs or console anymore), the mlv files can't be decoded via MLVMystic (just decoded one dng with weird colors), decoding to dng sequence with mlv dump worked, dng seq numbering is wrong (starts at frame_000000 / 01 / 02 then continues with 1180).

Quote from: kardolan on April 17, 2014, 01:41:21 AM

Just bought the Cinelog package and started to test it.
Seems to be very good when used with ACR compared to BMC to Cinelog export in Resolve (weird colors an things)

For the moment my top workflow is ACR + neat export to DnxHD 444for grading. I keep testing

Great job guys ! :)

I second that! Have been using the Resolve LUTs since they came out and the results are magnificent. Apart from that, the workflow via Resolve is so much faster, it just takes you where you want to go in no-time compared to using ACR.

Quote from: Canon eos m on April 17, 2014, 03:35:42 AM
Good morning. Is this module I should use going forward?

It fixes the assert and is already included in the latest nightly build.