The MLV format

[Danne]

Is there any way to get all functions revealed in raw2mlv? I could swear I saw some compressing options? I can´t find any description either on github nor reaching it from the compiled binary?

[ilia3101]

Haven't implemented compression yet. It will appear in help. I think if you run ./raw2mlv -h or --help you will see all the possible options.

[ilia3101]

Can I consider this a rule of the MLV format:

All metadata required for correctly decoding any given MLV, will come before its VIDF block.

Metadata such as: image parameters/resolution, compression, bitdepth, camera info, camera settings, and aspect ratio (if required, anamorphic modes for example).

The following suggests it may be:

as a consequence, we can start with the minimal subset (file header, raw info and then video frames)

If this is a rule, single frame previews can be fast and safe to do. All MLVs I look at seem to follow this rule, but I only looked at MLVs from 3 cameras with new builds.

Also putting this link here as I keep losing it: https://www.magiclantern.fm/forum/index.php?topic=7122.0

[ilia3101]

Let's say we write an official MLV format specification... describing every block structure with illustrations and text etc...

Then someone writes out C structs for MLV blocks based on reading only the specification. Are their C structures under the LGPL/GPL like mlv_structures.h/mlv.h is?

[Luther]

Let's say we write an official MLV format specification... describing every block structure with illustrations and text etc...

Then someone writes out C structs for MLV blocks based on reading only the specification. Are their C structures under the LGPL/GPL like mlv_structures.h/mlv.h is?

AFAIK, no. If you write a model or specification in, say, UML/TLA+ the specific code will be GPL, but not the "by-products" of it. Also, you wouldn't know how to prove someone used the specification in the first place (unless he wrote in a design by contract language, such as SPARK). Also, LGPL permits to close the code, only GPL that doesn't.
Why that worries you? Or the question was just out of curiosity? If someone wants to implement another MLV encoder/decoder, I don't see a problem in that, this is exactly what open source should want, people freely sharing information.

[ilia3101]

AFAIK, no. If you write a model or specification in, say, UML/TLA+ the specific code will be GPL, but not the "by-products" of it. Also, you wouldn't know how to prove someone used the specification in the first place (unless he wrote in a design by contract language, such as SPARK). Also, LGPL permits to close the code, only GPL that doesn't.

True, LGPL does permit that, but it says if you make changes to the code, you must share those specific changes. I guess mlv_structure.h is shared with LGPL so that if anyone makes their own changes to the format, they must give back... but I just see many ways around it. And if the "change" is adding a new block, it could just be put in a separate file, and the LGPL does not even apply, so adding a proprietary block would be easy and we don't have a way to control that if someone does it.

So it feels like having a license on the MLV structures does nothing.

Why that worries you? Or the question was just out of curiosity? If someone wants to implement another MLV encoder/decoder, I don't see a problem in that, this is exactly what open source should want, people freely sharing information.

Nothing worries me, I have had a lot of different thoughts about this issue. At one time I was thinking about making an mlv structures header file with a license to match the rest of LibmLV, but it's too weird to me so I'm not going to bother.


And what about these evolutions of my question:

1. Someone looks directly at the mlv_structure.h LGPL header, writes it down on paper, and later rewrites the structures in C based on their paper notes, is their code under LGPL?

2. Someone looks directly at the mlv_structure.h LGPL header, and rewrites structures in C while looking at the original structures, is their code under LGPL?

3. Can structures even be put under a code license like GPL/LGPL? They are not code, but descriptions of how some fields are arranged in memory/files right? Or are they considered code?

[Luther]

adding a proprietary block would be easy and we don't have a way to control that if someone does it.

But why is that a problem? I'm sorry, I can't see it. Other formats like DNG probably has some proprietary blocks implemented in some software, but the general structure is open... so why implementing something proprietary would hurt the project? It's not like these changes become mandatory to the open "standard" (such as what blobs do in operating systems), so I would think this is fine, no?

1. Someone looks directly at the mlv_structure.h LGPL header, writes it down on paper, and later rewrites the structures in C based on their paper notes, is their code under LGPL?

2. Someone looks directly at the mlv_structure.h LGPL header, and rewrites structures in C while looking at the original structures, is their code under LGPL?

I'm not really very acknowledged in that matter, but I think in both 1 and 2 it does apply the LGPL, since the structure would be exactly the same (and can be verified, which is more important in lawsuits).

3. Can structures even be put under a code license like GPL/LGPL? They are not code, but descriptions of how some fields are arranged in memory/files right? Or are they considered code?

I think so. Maybe GPL is not the best license in this case scenario. Markup languages such as XML, HTML and OWL have been under this W3C license for many years. Those languages don't have a specific code, but they do have a structure which other software can use.
But, again, I'm not an specialist on that. Might be better to ask on HackerNews or even stackexchange.

[ilia3101]

Does anyone like the idea of adding EXIF to MLV?

I was thinking it could be a special block, simply containing a dump of EXIF data in the exif/tiff tag format.

I know EXIF can have tags like bitdepth, black level, white level, compression and linearization tables - so there would need to be a rule that says any MLV file must be readable without looking at the EXIF.





Maybe MLV needs a PDF specification thing already?

[g3gg0]

EXIF could fit into the scheme.
but as you said you have to make sure that stuff doesnt cause redundancy.

what should it specify, what you do not have in the main blocks?

[ilia3101]

I want to continue work on LibMLV, I plan to copy the Lua API style.

EXIF could fit into the scheme.
...
what should it specify, what you do not have in the main blocks?

EXIF could do a lot: stuff like GPS, more than one colour matrix etc... Tonnes of stuff that's easier to outsource to EXIF than to implement in the MLV format ourselves.

but as you said you have to make sure that stuff doesnt cause redundancy.

It could cause some redundancy, if shutter speed and aperture gets in there, but it's not a concern as long as we keep this rule: An MLV decoder should be able to operate fully (extract frames) without using the EXIF block.



Again, about the licensing:

I would like to release LibMLV under MIT (permissive license), but how do we deal with the LGPL mlv.h? I think mlv.h is not code, it is structures.

The LGPL states that the user should be allowed to relink/replace LGPL components in a propreitary product. Problem: it would be much harder to relink header files containing structures. It would require dynamic loading of the header file.

As the American court ruled that APIs cannot be copyrighted (like the implementation can), and in my opinion, a header file with structures is much closer to API than implementation - it tells the compiler memory offsets and types, but does not become instructions, I think mlv.h may be used without LGPL restrictions. Does anyone agree?



How did propreitary apps like Martin Hering's colourcast, MLVProducer, fastcinemaDNG deal with this? Did they provide any way to relink with/replace mlv.h?

[Walter Schulz]

Ilia, do you may want to chat with g3gg0 using discord. Did you create an account yet?

[ilia3101]

Ah yes, I forget that I do actually have a discord account and I am in the magic lantern server.

Should I ask on there or message directly to g3gg0?

[Walter Schulz]

It doesn't make a big difference. Just start.

[names_are_hard]

The mlv.h I have is licensed GPLv2, not LGPL.  Which version of mlv.h are you working with?  GPL does not have the linking exception that LGPL has.

My personal, not-a-lawyer guesses about the API / structures part: structs are not APIs and are much more likely to be copyrightable.  The layout of a struct is not "obvious" in the sense that there is only one way to write it given a specification.  Structs definitely are code (as are APIs once they are written in a given language).  An instantiated struct, e.g. a global, does become bytes in object code.  Linking against such an object file would probably be okay if the code was LGPL licensed, but as far as I can see, mlv.h is not LGPL.

The easiest option would be use GPLv2.  Any particular reason why you want to use MIT?

[ilia3101]

There's a version of mlv.h released under LGPL somewhere a few years ago by the main devs (of course it's not up to date).

Licensing with a permissive license would give the best chances of getting wider MLV support possibly even in propreitary software. Although MLV having popularity is looking less likely as the years go on, for many reasons including creation of propreitary raw formats with strong compression (BRAW prores raw etc).

My personal, not-a-lawyer guesses about the API / structures part: structs are not APIs and are much more likely to be copyrightable.  The layout of a struct is not "obvious" in the sense that there is only one way to write it given a specification.  Structs definitely are code (as are APIs once they are written in a given language).  An instantiated struct, e.g. a global, does become bytes in object code.  Linking against such an object file would probably be okay if the code was LGPL licensed, but as far as I can see, mlv.h is not LGPL.

If MLV were standardised and the structs documented in a PDF document, then the structs could be re-written GPL free, right? Even though it's gonna produce the same code as the GPL-d structs.

Propreitary software using LGPL libraries (dynamically linked) will contain object code shaped by function definitions, and possibly even structures from the headers - this seems tolerated with LGPL, even though it limits how much change you can make in re-linking.

(so many ways to see this 😭)

[names_are_hard]

Forking from an earlier version doesn't sound ideal if ML is using the more recent code in its MLV files - won't that cause incompatibility?

MIT/BSD vs GPL is an interesting argument vs adoption.  Companies are more wary of taking GPLv2 code, but, if they take MIT/BSD code, they don't tend to cooperate with upstream - there's no need.  They're also allowed to modify your code (making incompatible MLV files) and not share those changes, which would suck.  Linux is GPL and Intel contributes driver code to them directly, for example, because GPLv2 means that's easier for them and it means Linux servers buy more Intel kit.

If MIT/BSD always lead to wide support, why is Linux so much more widespread and better supported than the BSDs?  GPLv2 was the right license to get Linux widely used and supported.

You could always license it as GPLv2 for now (because it's easier), but, since you retain copyright on the code you write, change the license on that code later on.  Sames goes for MLV if you get permission from the copyright holders there.  This is pretty common, having dual-license available on request (for a fee for the non-GPLv2 version, if you want).

[ilia3101]

The use of an earlier version wouldn't cause incompatibility, but some newer MLV blocks would not be supported. These new blocks are not critical for reading the image data correctly, but communicate things like stretch factor for anamorphic modes (don't remember all this stuff in much detail, perhaps there is now critical stuff).

MIT/BSD vs GPL is an interesting argument vs adoption.  Companies are more wary of taking GPLv2 code, but, if they take MIT/BSD code, they don't tend to cooperate with upstream - there's no need.  They're also allowed to modify your code (making incompatible MLV files) and not share those changes, which would suck.  Linux is GPL and Intel contributes driver code to them directly, for example, because GPLv2 means that's easier for them and it means Linux servers buy more Intel kit.

True, I guess we'd just have to hope no one makes custom propreitary MLV files.

I think the dual licensing is a great temporary solution.

[g3gg0]

well, using MLV structures, like the C structures (and also the function prototypes if you wish) was always meant to be LGPL.
only the real code is GPLed to make people work on the same code.

[ilia3101]

@g3gg0 Good to know. And how would you interpret the LGPL in this case? Would you say it requires a 'relinking'/replacement mechanism for MLV structures? Or simply the inclusion of a license text+source?

Also do you know about:

How did propreitary apps like Martin Hering's colourcast, MLVProducer, fastcinemaDNG deal with this? Did they provide any way to relink with/replace mlv.h?

well, using MLV structures, like the C structures (and also the function prototypes if you wish) was always meant to be LGPL.

Does this statement include the latest version of mlv.h (with GPLv2 on it as names_are_hard says), or only the LGPL file released a while ago?


If you prefer discord I can switch over, just need to restore my login.

[g3gg0]

nah its fine here. it just might happen that i dont notice when you ask smth
in that case a PM or discord msg as reminder would help.

> And how would you interpret the LGPL in this case? Would you say it requires a 'relinking'/replacement mechanism for MLV structures? Or simply the inclusion of a license text+source?

its meant on a file-level. the mlv.h is allowed to be used in your even commercial product.
while the license itself is meant for linking C code into a non-GPL project and requires you to provide that code, in this case its just about the header.
i should have chosen MIT back then. but well...

as we are talking about just structures/data types (the mlv_hdr structures etc) that i want people to just use like some kind of documentation, don't make a science out of it.
not gonna sue anyone who used C STRUCTURES from the latest mlv sources. i doubt that it even would make any sense to go after that.

again. just use the C-structures/datatypes from the latest headers.
do NOT USE C CODE - literally code, that is not just a structure/datatype, but code.


why this decision?

as we want to encourage people to contribute to open source projects, keeping the code itself GPL prohibits shameles copycats who do not contribute back.
making the C structures usable for all, that is like some kind of documentation of the binary format. syntactically. a bit, at least.
this simplifies interoperability, but does not make copycat's lifes easier.

> Also do you know about:
> How did propreitary apps like Martin Hering's colourcast, MLVProducer, fastcinemaDNG deal with this? Did they provide any way to relink with/replace mlv.h?

i hardly remember what i did yesterday. so errrh no.

well, i assume everyone played fair. if not then be so fair and at least contribute a bit back to at least finance server expenses.
OT: just checked - its 1.1k€ that are missing right now since the last donation in 2019, but thats nothing that would financially stress me.

[ilia3101]

Thank you so much for the in-depth reply and explanation.

[ilia3101]

Just made the connection...

Header files, at least interface definitions and structures, are not copyrightable, according to US copyright law (Google vs Oracle: as it stands, Google won), and the FSF itself (authors of GPL license).

Found this great answer too: https://softwareengineering.stackexchange.com/a/216480

So any system, even closed source, is safe to implement MLV!



Not that it matters anymore, with BRAW and ProRes raw being so popular. Apple/Blackmagic taking responsibility for patent issues makes those formats very appealing to manufacturers (on top of the great lossy compression)

[g3gg0]

yep, thus there was a LGPL version for the headers to make it even more clear