Author Topic: The MLV format  (Read 7773 times)

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 6959
Re: The MLV format
« Reply #50 on: November 11, 2019, 04:21:12 PM »
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

  • Moderators
  • Hero Member
  • *****
  • Posts: 924
Re: The MLV format
« Reply #51 on: November 11, 2019, 05:50:38 PM »
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

  • Moderators
  • Hero Member
  • *****
  • Posts: 924
Re: The MLV format
« Reply #52 on: December 12, 2019, 01:40:06 PM »
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

  • Moderators
  • Hero Member
  • *****
  • Posts: 924
Re: The MLV format
« Reply #53 on: February 20, 2020, 09:03:09 PM »
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

  • Senior
  • ****
  • Posts: 317
Re: The MLV format
« Reply #54 on: February 20, 2020, 09:43:15 PM »
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

  • Moderators
  • Hero Member
  • *****
  • Posts: 924
Re: The MLV format
« Reply #55 on: February 20, 2020, 10:27:12 PM »
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

  • Senior
  • ****
  • Posts: 317
Re: The MLV format
« Reply #56 on: February 20, 2020, 11:19:02 PM »
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?
Quote
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).
Quote
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

  • Moderators
  • Hero Member
  • *****
  • Posts: 924
Re: The MLV format
« Reply #57 on: July 13, 2020, 01:36:10 AM »
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

  • Developer
  • Hero Member
  • *****
  • Posts: 3157
Re: The MLV format
« Reply #58 on: September 20, 2020, 08:59:13 AM »
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?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!