Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo)

[Jakobmen]

any new pre-builts i can play with=) ?

[1%]

I think with the latest commits I can only use the bigger modules on DigicV.

[g3gg0]

i updated the MLV player again - see main post.
now it supports resizing and different debayering algorithms.

parts of it are faster now, others are slower.
in the end its about the same speed as the version before

[oddname]

i dont know what is wrong on 5D2. there were just reports of "hanging" module.
can you explain the problem in detail?

I can try again, can you point me to the latest build of the module that should work?
(I tried one before, and I was the one saying it froze, gave me speeds of 6-7MB/s instead of 60-70 when it works)

[Thomas Worth]

now it supports resizing and different debayering algorithms.

Where did you get the debayer code? Did you write it yourself or are you using code from say, dcraw?

[g3gg0]

Wrote it on my own.  It isn't much code.  Just simple math

[1%]

I'm having really nice success with the latest updates found. Just have an issue with indicators roling over at 45GB and freezing on card full.

[oddname]

When will the format be available in the nightly builds? If it will.

[baldand]

I've also made a simple player for both MLV and RAW file sets. It uses OpenGL shaders for the demosaicing to keep CPU usage lower. It's written in python, so it works at least on Linux and Mac (command line only though). I haven't tried on Windows but it might be possible to make it work there also with little or no changes.

Link and info about the tool can be found in my blog post here: http://thndl.com/?20

[ted ramasola]

I've also made a simple player for both MLV and RAW file sets. It uses OpenGL shaders for the demosaicing to keep CPU usage lower. It's written in python, so it works at least on Linux and Mac (command line only though). I haven't tried on Windows but it might be possible to make it work there also with little or no changes.

Link and info about the tool can be found in my blog post here: http://thndl.com/?20

that's great news! I do look forward to it being available for windows.

[baldand]

that's great news! I do look forward to it being available for windows.

It turns out it also works fine on Windows (at least Win7) as-is using a python distro like WinPython 2.7 (See https://code.google.com/p/winpython/ )

If you install that and use it to compile the included bitunpack module it will decode a bit faster.
E.g. from the source directory something like:
c:/WinPython/python/python setup.py build_ext -c mingw32 --inplace
(though I had to remove -mno_cygwin calls from python/lib/distutils/cygwinccompiler.py first)
Then copy bitunpack.pyd from the build subsubdirectory

[swinxx]

hi,

mlv really sounds interesting and i think we all hope that audio will make it to the final verison,
can someone post a link to a actual build with mlv for 5d mark3... have no skills to build my own one. thx.



thx.

[Malex]

Hi, I am following from far what's happening with the MLV format and I think it's pretty exiting, so I was wondering, do you think or hope that in the future, softwares like Davinci Resolve, After effects, Premiere, and others will read that format ? Will they debayer proxy directly!?
If that happens, it would be crazy for Canon, they'd have to hire you guys! (to make you stop that nonsense!) or sue you.
What are you thoughts on that?

[oddname]

hi,

mlv really sounds interesting and i think we all hope that audio will make it to the final verison,
can someone post a link to a actual build with mlv for 5d mark3... have no skills to build my own one. thx.



thx.

Likewise but for 5D2, cant find a newer one that should work besides the old 50D one =)

[g3gg0]

If that happens, it would be crazy for Canon, they'd have to hire you guys! (to make you stop that nonsense!) or sue you.
What are you thoughts on that?

we dont think about any of these options

[Midphase]

I was wondering, do you think or hope that in the future, softwares like Davinci Resolve, After effects, Premiere, and others will read that format ? Will they debayer proxy directly!?

I think there's a pretty good chance that Premiere Pro and Aftereffects will once the .mlv format is fully finalized. Adobe has hinted at it and I don't think they'd have anything to lose by adding that format in much the same way they deal with RED's proprietary format.

Regarding Canon, I don't think they care. They continue to sell cameras, and I'm sure they've seen a spike in sales of the 5D3 since the ML raw came out. Given the recent offerings from Blackmagic, I don't think anyone who is serious about video would consider buying a DSLR anymore if it wasn't for ML raw, so for that I think Canon must be pretty thankful to these guys (whether they'd admit it or not).

[enliten]

hey guys, what's the CPU overhead whilst recording raws?

I was just wondering if it was possible to compress a frame every now and then to "improve" bandwidth. With the meta data included in MLV does it matter if the frames are written out of order?

-Ben

[g3gg0]

compression -> no

there is nearly no cpu involved, thats the reason why its possible.

[enliten]

no compression because it won't work or because it's too hard or because it isn't a priority?

(I know that this would have to be a wholly software implementation, thus why i was suggesting only a frame here or there)

EDIT: i missed a letter

[g3gg0]

the cpu is too slow to compress 100MiB/s in realtime

[maxotics]

@Enliten  Compression takes time.  A lot more time than de-compression.  No matter what your source of data.   So why would you want to add the time to compress onto the time needed to read the data stream in the first place? 

I think what you're asking is why can't you throw out a bunch of data you don't need while showing it, to improve speed.  That sounds logical.  But if you think about for a bit you'll realize that's just another type of compression (which in a sense is already done when the software translates the bytes into data that can be used by the display). 

What the devs are probably thinking about is taking the time to compress the stream for easy playback (either at once, or buffering).  Realize however, that it would take their time and then you'd have people complaining about load times.  (Again, no free lunch). 

Some people on the forum get upset if they feel you haven't done your research first, or if you ask a question you could have answered yourself if you thought about it for a bit.  Some are here on the forum to get things done and others to learn.  So you'll get mixed responses.  I recommend going very slowly.  Try not to ask any question like "it's not a priority?" that may suggest you think they're blowing certain issues off.  Everyone is working on this for free, wishes they had more time, and is already upset that they can't do all they want to do.  Everyone sets priorities for themselves.  There is no central command.

Also, g3gg0 has put his MLV viewer up on Bitbucket.  You're welcome to clone and push any ideas you have!

Hope this helps! 

[g3gg0]

Everyone is working on this for free, wishes they had more time, and is already upset that they can't do all they want to do.

thanks, wise words
(at work atm and painting powerpoint slides. fu*k, yeah, hardcore lowelevel developer)

[Greg]

the cpu is too slow to compress 100MiB/s in realtime

This result for the DIGIC 5+?

[enliten]

@maxotics hey, yes i did very little research going into that question.

please be aware that it is never my intent to offend, i just like problems and see a challenge behind a "no". which is why I wanted elaboration.

I did know that realtime compression isn't viable which is why I asked what the CPU overhead is and made the comment about frame numbers.

Let me throw you a hypothetical.

Let's say the devs are able to take a frame that is about to be dumped onto the card, and instead threw it onto camera memory for processing. The camera then compresses this frame and then dumps it onto the card when it is able to next (after having compressed it).

Lets say the 5th frame is the one that gets grabbed for compression. The frames would be written to card 1,2,3,4,6,7,8,9... and once compression has finished then 5,10,11. So it would be a pseudo-realtime compression. Taking a frame here or there and compressing, rather than every frame. The thing that would allow this to be completed is the new MLV format with has frame metadata, allowing the frame to be uncompressed by whatever tool supports MLV.

Of course this is only theoretical, which is why I asked the question in the first place.

Apologies for not elaborating better in the first place.

-Ben

[maxotics]

( painting powerpoint slides. fu*k, yeah, hardcore lowelevel developer)

PPT work?  You're going to seriously depress everyone!

BTW, I have tons of VBA code in Office (mostly Excel, Access and Word). If you ever need some VBA to do something stupid (so you can spend more time with C), PM me.