Is MLV all that it's cracked up to be?

[Midphase]

First of all, I want to make it abundantly clear that this isn't a criticism or a slam on ML and .mlv.

I'm just trying to get a sense of what exactly .mlv gives me that .raw doesn't. Looking at the EXIF data written to DNG files from .mlv files using MLVMystic and comparing them to the EXIF from CDNG derived from .raw files using RAWMagic, I'm not seeing a whole lot of additional information coming from the .mlv files. There is ISO, and some focal length info, but everything else is pretty much the same in both files.

Besides that, when recording in .mlv on my 5D3, I seem to get slightly worse CF card performance than when recording in .raw. I also noticed that DNG files derived from .mlv seemed to display more pronounced dead pixels than similar takes extracted from .raw as CDNG.

Last but not least, there is the severe lack of a good conversion app on the Mac, and pretty much nothing to get CDNG as opposed to DNG files. RAWMagic has worked flawlessly for me with Resolve, and to a lesser degree with Premiere Pro. .mlv on the other hand has presented challenges until very recently thanks to MLVMystic. The problem with MLVMystic is that it's still in fairly rough beta, it converts considerably slower than RAWMagic, and it doesn't spit out CDNG files which means, for better or for worse Premiere Pro wants nothing to do with them and import into Resolve is a wee bit more of a PITA.

Having said that, I am still wanting to give .mlv every chance in the book, but I have to ask -- what is the specific advantage of .mlv vs. .raw in real world usage?

Thanks for all your replies, I am really curious to know more about the advantages of .mlv over .raw.

PS.

Tomorrow I'm doing a camera shootout with the following cameras:

1. Arri Alexa
2. Red Dragon
3. Red Epic
4. Canon C500
5. Canon 1DC
6. Canon 5D Mark III (ML raw)
7. Sony F55
8. Panasonic GH4
9. Blackmagic Cinema 4k

Should I shoot in .mlv or .raw?

[Audionut]

This looks like a pretty good summary to me.

some technical facts:
- structured format
- extensible layout
- as a consequence, we can start with the minimal subset (file header, raw info and then video frames)
- multi-file support (4 GiB splitting is enforced)
- spanning suport (write to CF and SD in parallel to gain 20MiB/s)
- out-of-order data support (frames are written some random order, depending on which memory slot is free)
- audio support
- exact clock/frametime support (every frame has the hardware counter value)
- RTC information (time of day etc)
- align fields in every frame (can differ from frame to frame)

the benefit for post processing will be:
- files can be easily grouped by processing SW due to UIDs and file header information (autodetect file count and which files belong to each other)
- file contains a lot of shooting information like camera model, S/N and lens info
- lens/focus movement can be tracked (if lens reports)
- exact* frame timing can be determined from hw counter values (*=its accuracy is the limiting thing)
- also frame drops are easy to detect
- hopefully exact audio/video sync, even with frame drops
- unsupported frames can be easily skipped (no need to handle e.g. RTC or LENS frames if the tool doesnt need them)
- specified XREF index format to make seeking easier, even with out of order data and spanning writes

why a custom format and not reuse e.g. .mov?
- other formats are good, but none fits to our needs
- hard to make frames align to sector or EDMAC sizes
- they dont support 14 bit raw bayer patterns out of the box
- even when using a flexible container, nearly all sub blocks would need custom additions
- this means a lot of effort to make the standard libs for those formats compatible
- its hard to implement our stuff in a clean way without breaking the whole format

thats the reason why i decided to throw out another format.
it is minimalistic when desired (especially the first implementation will only use a subset of the frames)
and can be extended step by step - while even the most minimalistic parser/post processing tool
can process the latest video files where all stuff is implemented.

if you are a developer (ML or even 3rd party tools) - look over it and make yourself comfortable with that format.
in case there is a bug or something doesnt make sense, please report it.
i would love to get feedback.

here is the link of the spreadsheet that is some kind of reference when designing the format:
https://docs.google.com/spreadsheet/ccc?key=0AgQ2MOkAZTFHdHJraTVTOEpmNEIwTVlKd0dHVi1ULUE#gid=0

implementer's notes
green = fully implemented
blue= implemented, but not 100%
red = not implemented yet, just defined

[MLVI] (once)
- MLVI block is the first block in every .mlv file
- the MLVI block has no timestamp, it is assumed to have timestamp value 0 if necessary
- the MLVI block contains a GUID field which is a random value generated per video shoot
- using the GUID a tool can detect which partial or spanning files belong together, no matter how they are named
- it is the only block that has a fixed position, all other blocks may follow in random order
- fileCount field in the header may get set to the number of total chunks in this recording (the current implementation on camera isn't doing this right)

[RAWI] (once, event triggered)
- this block is known from the old raw_rec versions
- whenever the video format is set to RAW, this block has to appear
- this block exactly specifies how to parse the raw data
- bit depth may be any value from 1 to 16
- settings apply to all VIDF blocks that come after RAWI's timestamp (this implies that RAWI must come before VIDF - at least the timestamp must be lower)
- settings may change during recording, even resolution may change (this is not planned yet, but be aware of this fact)

[VIDF] (periodic)
- the VIDF block contains encoded video data in any format (H.264, raw, YUV422, ...)
- the format of the data in VIDF blocks have to be determined using MLVI.videoClass
- if the video format requires more information, additional format specific "content information" blocks have to be defined (e.g. RAWI)
- VIDF blocks have a variable sized frameSpace which is meant for optimizing in-memory copy operations for address alignment. it may be set to zero or any other value
- the data right after the header is of the size specified in frameSpace and considered random, unusable data. just ignore it.
- the data right after frameSpace is the video data which fills up the rest until blockSize is reached
- the blockSize of a VIDF is therefore sizeof(mlv_vidf_hdr_t) + frameSpace + video_data which means that a VIDF block is a composition of those three data fields
- if frames were skipped, either a VIDF block with zero sized payload may get written or it may be completele omitted
- the format of the data in VIDF frames may change during recording (e.g. resolution, bit depth etc)
- whenever in time line a new content information block (e.g. RAWI) appears, the format has to get parsed and applies to all following blocks

[WAVI] (once, event triggered)
- when the audio format is set to WAV, this block specifies the exact wave audio format

[AUDF] (periodic)
- see [VIDF] block. same applies to audio

[RTCI] (periodic, event triggered)
- contains the current time of day information that can be gathered from the camera
- may appear with any period, maybe every second or more often
- should get written before any VIDF block appears, else post processing tools cannot reliable extract frame time

[LENS] / [EXPO] / ... (periodic, event triggered)
- whenever a change in exposure settings or lens status (ISO, aperture, focal length, focus dist, ...) is detected a new block is inserted
- all video/audio blocks after these blocks should use those parameters

[IDNT] (once)
- contains camera identification data, like serial number and model identifier
- the camera serial number is written as HEX STRING, so you have to convert it to a 64 bit INTEGER before displaying it

[INFO] (once, event triggered)
- right after this header the info string with the length blockLen - sizeof(mlv_info_hdr_t) follows
- the info string may contain any string entered by the user in format "tag1: value1; tag2: value2"
- tag can for example be strings like take, shot, customer, day etc and value also any string

[NULL] (random)
- ignore this block - its just to fill some writing buffers and thus may contain valid or invalid data

[ELVL] (periodic)
- roll and pitch values read from acceleration sensor is provided with this block

[WBAL] (periodic, event triggered)
- all known information about the current white balance status is provided with this block

[XREF] (once)
- this is the only block written after recording by processing software, but not the camera
- it contains a list to all blocks that appear, sorted by time
- the XREF block is saved to an additional chunk
- files that only contain a XREF block should get named .idx to clarify their use
- .idx files must contain the same MLVI header like all chunks, but only have the XREF block in it

[MARK]
- on keypresses, like halfshutter or any other button, this block gets written for e.g. supplying video cutting positions
- the data embedded into this block is the keypress ID you can get from module.h


possible future blocks:

[OFFS]
- in-camera black and noise reference pictures can be attached here (dark frame, bias frame)
- to be checked if this is useful and doable

[VERS]
- a string follows that may get used to identify ML and raw_rec versions
- should follow the same format as INFO strings, "tag1: value1; tag2: value2"
- tag can be either "ml_core", "raw_rec" or any other string that is used to identify some module/component version
- possible content: "ml-core 20130912; raw_rec v2.1; mlv_fmt v2.0; smpte v0.0"



[MLV Format]
- the Magic Lantern Video format is a block-based file format
- every information, no matter if audio or video data or metadata is written as data block with the same basic structure
- this basic structure includes block type information, block size and timestamp (exception to this is the file header, which has no timestamp, but a version string instead)
- the timestamp field in every block is a) to determine the logical order of data blocks in the file and b) to calculate the wall time distance between any of the blocks in the files
- the file format allows multiple files (=chunks) which basically are in the same format with file header and blocks
- chunks are either sequentially written (due to e.g. 4 GiB file size limitation) or parallel (spanning over mutiple media)
- the first chunk has the extension .mlv, subsequent chunks are numbered .m00, m01, m02, ...
- there is no restriction what may be in which chunk and what not

[processing]
- to accurately process MLV files, first all blocks and their timestamps and offset in source files should get sorted in memory
- when sorting, the sorted data can be written into a XREF block and saved to an additional chunk
- do not rely on any order at all, no matter in which order they were written into a file
- the only reliable indicator is the timestamp in all headers

First of all, I want to make it abundantly clear that this isn't a criticism or a slam on ML and .mlv.

Then you should probably consider using a more appropriate thread title.

[Midphase]

No need to re-quote all that. I've read it and re-read it, and believe me, I didn't just fall off the turnip truck. I'm just merely raising the question on a "real world" level and not a programming level.

Even from a data stability point, I've been dismayed at getting more corrupted frames when using .mlv than I ever have in .raw.

I understand what the programmers are saying, but what I am asking is...does this all translate in useable real-world data that makes up for the poor (current) post-production support for .mlv?

I've always maintained that ML raw is a two step deal, one is what happens in the camera, but the second and equally important is what happens once the data leaves the camera. One without the other doesn't work, both have to be rock solid to be considered for professional work.

While there seems to have been a great deal of development time devoted to perfecting the in-camera software and adding more functionality to ML in general, the back end development has been severely lacking. Command-line solutions aren't solutions.

So once again...are the advantages of .mlv in real-world usage worth the extra PITA that comes with it on the back end vs. .raw; which, for better or worse, does have a useable OS X back end in RAWMagic.

[Audionut]

Command-line solutions aren't solutions.

That is your own personal opinion, based solely on your own abilities, and/or, expectations.

Lets consider this.

Adobe has some pretty nice front end software.  If you don't like Adobe, well then there is Resolve, or a bunch of other software that may contain a GUI that ticks all your boxes.

What do you think Adobe et all have, that ML doesn't?  Well, off the top of my head, massive amounts of resources for a start.  The sort of resources that are well outside the resources available to a bunch of guys coding stuff as a hobby.

While there seems to have been a great deal of development time devoted to perfecting the in-camera software and adding more functionality to ML in general

There is a pretty good reason for this, because, that's what the guys do.  The fact that they have developed the features they have, doesn't imply that they must then follow through with fancy GUI's that make the secondary process easier, for yourself.  These Linux guys live off command lines 

In fact, being an open source software, implies collaboration.  So it shouldn't be an expectation of the ML development team to further develop applications, specific to the needs of a few, taking resources away from the main goal of the development process.

What is it?

Magic Lantern is a free software add-on that runs from the SD/CF card and adds a host of new features to Canon EOS cameras that weren't included from the factory by Canon.

I don't specifically see mention about designing front end software for video editing 



Yes I am being argumentative, but your thread title implies an argumentative response.  You know that just as well as I do, or else the first line of your OP wouldn't have been a clarification!

[Midphase]

You post IMHO exemplifies a key misunderstanding and gap between the guys who are coding ML and the guys who are trying to use it.

I have been a huge evangelist for ML raw, even wanting to organize a special presentation for the upcoming NAB and try to sort through much of the mis-information that's floating out there.

But make no mistake, sheer power without end-user friendliness is doomed from the start. So many programmers believe that just implementing amazing code in all that is needed. This is the critical difference that made Steve Jobs so successful, he understood that the end-user experience is as inherent to a product's success as the product itself.

Don't get me wrong, I don't believe in the need to appease the absolute lowest common denominator, but in the case of ML the situation is very much at the opposite end of that spectrum.

Perhaps I don't understand the end-goal here. Maybe ML is some sort of performance-art piece designed to prove that Canon are a bunch of dick-heads who have been keeping all of this power away from the masses for their own perverse reasons. If that's the case, good for ML because it has fully succeeded in achieving that.

But the reality of the situation is that ML exists on borrowed time and in about two years' time nobody will want to shoot video on DSLR's because there will be absolutely no reason to do so (and that's me being optimistic). There are other massive disruptive forces that are causing a rapid shift in how people shoot video. I live and breathe this industry on a daily basis in a town that fancies itself the World capital of film production. I am constantly interacting with cinematographers and editors, and believe me, when I show them a command-line solution they laugh in my face at the absurdity of it. So yes this is only my opinion, but an opinion shared by just about every single professional that I've interacted with for the better part of last year.

On OS X, RAWMagic has been the only solid application that seems to really get it. Unfortunately Thomas is not particularly motivated or available to bring it up to speed with .mlv, which kinda gets us back to the original question:

Is .mlv, in real-world scenarios, worth the extra hassle vs. .raw? Because all of the metadata in the world means nothing if the conversion apps or the ingesting apps don't use it or know what to do with it. And despite a more robust data-writing method, .raw has been rock solid since I first began using it back in June of last year. If anything, this speaks highly of how well the original developers nailed .raw, and why I am not seeing the benefits of .mlv right off the bat.

Lately, Andy has brought up the idea of ACES support in ML raw video. Now that makes much more sense to me, yet none of the developers really chimed into that conversation which leads me to believe that it probably fell on deaf ears.

But I digress....what I would appreciate above all else is if you would be so kind as to explain to me, in plain words, why .mlv makes more sense than .raw with the current state of tools available and its current implementation by third parties?

I appreciate your time and passion, I really do; and I sincerely hope that my posts aren't coming across as too snarky or negative...because in truth if we could hang and discuss this over a couple of drinks I'm sure we'd come to like one another! 

[Marsu42]

You post IMHO exemplifies a key misunderstanding and gap between the guys who are coding ML and the guys who are trying to use it.

I'd like to add that you are using nightly or alpha versions to even be able to try these features, there is absolutely nothing done concerning an "end-user" friendliness (yet). Probably due to the lack of people willing to do extremely boring things like writing docs it will remain this way, and there seems to be no schedule for any "stable" 3.0 release since it's more interesting to develop than to bug-hunt.

My point: These are all well-known facts, and while some people might come across a bit nerdy or gear-headed it's not nuclear science to see that yo good ol' Adobe-Apple creative user isn't in the mood to wrestle with command line parameters. It's just that unless more resources pop up out of nowhere, any discussion or lamenting is a bit pointless. Are you volunteering to step up for a gui & usability project?

[Audionut]

To further the response from Marsu42, you seem to be expecting ML raw to be some professional solution, with all of the end user support and resources, that are expected from expensive professional software.

Are you volunteering to step up for a gui & usability project?

This!

The developers have enabled the features, it's up to others to take these features in the directions required.

Yes, it is that simple.  ML is a software addon to enable extra functionality in Canon EOS cameras.  No more, no less.
We should all be extremely grateful to g3gg0 for taking the time to make the raw format extensible (MLV), and easy for third party developers to take this to the next level.  Either professionally, with fancy, easy to use GUI's, and end user support, or simple GUI applications designed to provide some aspect of simpleness.

It should not be an expectation, that the developers move from 1 person coding in the garage, to providing GUI's rivalling that of software giants.

You're best bet, would not be discussing the situation here.  Start writing letters to the big players.  They already have the core functionality, and GUI's sorted.  Adding MLV support would be relatively easy in comparison.

But the reality of the situation is that ML exists on borrowed time and in about two years' time nobody will want to shoot video on DSLR's because there will be absolutely no reason to do so (and that's me being optimistic).

Really?  Borrowed time!  Photographers have been given a bunch of extremely useful features in the last 12 months.  And it only continues to get better.

[ItsMeLenny]

As a friend of mine used to say "A computer is as only as smart as its user."

[Marsu42]

To further the response from Marsu42, you seem to be expecting ML raw to be some professional solution, with all of the end user support and resources, that are expected from expensive professional software.

The underlying problem is that with the damn expensive 5d3 ML has evolved into a market segment where people have $10000 worth of gear and expect everything to be pro-grade. ML has not and cannot adapt to that, good idea it doesn't support the 1d :->

Back when I started using ML it was a legacy 5d2 project and people were amazed that it even worked on their Rebels, unlocking unbelievable features like more than 3 shots bracketing only found in cameras well out of their financial reach. I was very thankful that after donating for a 60d I got some pre-alpha buggy version working that didn't brick my camera. I know this sounds like grandfather talk, but that's the origin of ML ~3 years ago, everything now is just a nice extra.

[ilguercio]

Someone blames ML for giving us the most they can and not Canon for NOT giving users what they expect. Weird.

[tjaja]

Canon is foolproofing their software and the camera has to work with features that not outclass their higher class camera's. Because busniss.
MLV is structured, so it should be easier for Adobe or some company to pick it up. And I think it is just a matter of time.

[N/A]

Not to mention, .MLV has working audio.

I can see where OP is coming from, it can be frustrating to have all of these great new camera features handed to us only to constantly struggle with a convoluted post workflow. But considering raw video was just a dirty, hiv-ridden crack pipe dream just 11 months ago, we've come a tremendous way.

To be completely generic and cliche, Rome wasn't built in a day.

I moderate the "Share your Video/Photos" section, so I have a pretty good idea of the general type of shoots .RAW and .MLV are being used for. I see a lot of hobbyists and freelance videographers who shoot timelapses, commercials, music videos, etc. You know, the do-it-yourself type of users. We like to have complete control over our projects, and this is what ML gives us. We want the most bang for our buck, which is why most of us don't mind command line tools and different options on how to reach whatever goal we may have in mind for our labors of love.

[1%]

Its real simple for me... raw if you don't want sound. MLV if you want sound.

Then you have MLrawViewer and you can make it into pro-res without many command line things. Otherwise you could break it out into dngs, I think MLV browser (or mlv-to-cdng) can do it but I only tested that on windows.

[dubzeebass]

Or the recursive script I and some others wrote, for Mac.

[tonybeccar]

Hehe.. hot conversation.. it shouldnt be like that. Marsu42, you are right.. and of course you too audionut. But there is a valid point.. we need a proper gui.. because command lines ARE laughable.. well they are very time consuming.. yes!
I know the main os is mac for this business.. but maybe you missed my thread Marsu.. i am developing a converter for windows.. which i am aiming to have everything and be thr ultimate solution.. its looking good.. and also chmee is working on cdngs.. which is thr way to go.. so my guess is in 2 months ML would be close to (or co.pletely) perfect. I am on holiday returning in a few days and will resume development on my app.. which i have good ideas for.
But as audionut said and its very true.. its up to collaboration to make the back end happen.. well it IS happening and soon it will be ready..
But yeah ML will be always for small budget productions who want to get close to really professional cameras.. so i dont mind myself a little dirt on the road
Anyway id love to compile my converter for mac.. i just dont know how to and currently have no mac to test it on.. will do soon when i resume work.though..
Anyway hope i brought some peace to both sides hehe..
Cheers!!

[reddeercity]

@Midphase, I have same thoughts exactly! You have very good points that No one will
Address , without being defensive !
All you ever hear is the same BS over & over
How ML is open soure and if you don't like it do it your self etc....
And then the same people will jump all over you when make a suggestion
Or a comment toward the Delveopment of Raw/MLV. To me it seems
There is no direction and if there is , it's known to a FEW Select
People .
And there agian I know everyone will take may comment
Negatively , but it must be said.
I'm absolutely a very big supporter or the ML , if I wasn't
I wouldn't be posting my concerns and be active on the form.
I will have more to say on this topic later on.

[Marsu42]

All you ever hear is the same BS over & over
How ML is open soure and if you don't like it do it your self etc....

If you really call this bs and not just for trolling purposes, I think you missed out big on the whole idea. That's why I came to code ML patches, because I wanted to change something w/o begging the devs for every single implementation. Now that the core is cleaner and modules are here, it's even much easier than before - and if you're stuck, you're getting near-instant help around here.

And then the same people will jump all over you when make a suggestion
Or a comment toward the Delveopment of Raw/MLV.

I guess it depends on the tone. As written above I'd agree there are some less-than-practical photogs around who might not have optimal experience with actual real-life implementation of the ML features for production purposes. But it's up to your social skills to deliver the intended message so it's well received ... reading your post above, you could do with some practice :-p

[reddeercity]

Sorry you  see it that way, I couldn't help but Tell the truth.

[Marsu42]

Sorry you  see it that way, I couldn't help but Tell the truth.

Ok, if your opinion from your perspective is the same as the truth imho that's plain trolling - thank you for notifying so no further energy is wasted.

[Midphase]

"Its real simple for me... raw if you don't want sound. MLV if you want sound."

Thank you 1% for being pretty much the only one to answer my question. With that basic bit of info, I think I'll stick with .raw.

To the rest of the people who feigned outrage...I think you're missing the point I was trying to make and which I have neither the time, nor the inclination to re-explain (given the defensive posture that just about everyone immediately took).

Thank you developers for the hard work.

[mixmastermike]

@Midphase, I have same thoughts exactly! You have very good points that No one will
Address , without being defensive !
All you ever hear is the same BS over & over
How ML is open soure and if you don't like it do it your self etc....
And then the same people will jump all over you when make a suggestion
Or a comment toward the Delveopment of Raw/MLV. To me it seems
There is no direction and if there is , it's known to a FEW Select
People .
And there agian I know everyone will take may comment
Negatively , but it must be said.
I'm absolutely a very big supporter or the ML , if I wasn't
I wouldn't be posting my concerns and be active on the form.
I will have more to say on this topic later on.

Well said, I don't think it is unreasonable to want MLV to function with sound or at 30p.

But at the same time I understand it's not me doing the coding either, so catch 22 on that one.

If this is open source does that mean there is no structural development plan? Or is it even unreasonable to ask that question?

The aggressive nature of posters taking this or that stance reminds me of one of my favorite Einstein quotes

"Great spirits have always encountered violent opposition from mediocre minds"

And here's one free from me;

"If you find yourself arguing with an idiot, you have to ask who the idiot is"

[Marsu42]

If this is open source does that mean there is no structural development plan? Or is it even unreasonable to ask that question?

Of course not, what gave you the idea? Personally, I keep mentioning that the current situation cannot be satisfactory to end users as they are forced to used the pre-alpha nightly bleeding edge releases as a kind of "new stable", there are no milestones or point releases except for specific camera models then and again. Imho needs some predictable release management to de-confuse the situation.

At the same time, people don't seem to realize that the bulk and tricky part of ML is essentially coded by one person, maybe with specific additions from another coder. How much of a structural development plan does a single person need? I'm not a dev and thus don't have any insight in what's going on betwen them, but it boils down to everyone is doing what he likes or wants, and this about what you can expect to get for free.

[1%]

AFAIK a1ex + g3gg0 are mainly into photography vs video production. If you need some sort of milestones to mesh ml RAW with your workflow there needs to be some sort of discussion as to what is exactly lacking.. and not unreasonable stuff like 4K filming and in camera pro-res. So far my list includes inconsistent HDMI and inability to preview full crop mode while recording without major speed hits or footage destruction. Also the FPN noise + hot pixels at high ISO.

The post worflow is getting worked out since there are a few competing solutions, the ML raw viewer is really a godsend in terms of realtime preview and one click conversion.

[Midphase]

I agree with you 1%, MLRawViewer is a step in the right direction with someone who is willing to listen to feedback and not get all up in arms when someone asks for needed improvements.

MLVMystic is also promising, but it's still ways away from where it needs to be. It's currently very slow, lacks any sort of progress bar (which in turn makes it feel slower than it probably really is), lacks the ability to select directories, lacks drag and drop functionality, doesn't export to CDNG which is (in no small part due to Blackmagic) gaining more and more acceptance and support from apps like Premiere Pro, would be nice it could export to other formats like ProRes (yeah, I know MLRawViewer does that already), and some sort of preview would be cool too. In essence what I am asking is for an app that's a combination of MLRawViewer and MLVMystic (with a dash of RAWMagic thrown in).

My point about ML raw (and DSLR video) having a limited shelf life still stands. Today's test with about every camera in existence (including the GH4 and the Blackmagic 4K) supported the fact that the landscape is changing quite rapidly. As a fan of ML raw, I want it to still be a relevant and useful format for as long as possible. But in reality there really isn't too much time to screw around before the limited momentum that ML raw has achieved grinds to a halt due to a difficult post production data pipeline.

I realize that this is all free stuff, done as an open source project. I totally get it. But I think that the ML community should be open to having a serious conversation about what is really needed to solidify this software.

As much as hacking cameras is a fun puzzle box that I am sure piques the fancy of the developers, I wish they'd stop focusing so much on adding new features, and put more time into fixing the elements that need fixing (all the things that 1% just mentioned for instance) as well as strengthening the back end tools.

[Markus]

Its real simple for me... raw if you don't want sound. MLV if you want sound.

Then you have MLrawViewer and you can make it into pro-res without many command line things. Otherwise you could break it out into dngs, I think MLV browser (or mlv-to-cdng) can do it but I only tested that on windows.

Is a working sound module for standard raw rec impossible or just not something anyone is interested in putting time in developing?