Some time ago I remember hearing that the MLV format is getting extended with more features in Google summer of code for Apertus cine camera project. Did that ever happen?
A couple more questions:
1. Would developers consider adding new blocks to the official MLV format?
2. Where can I see most up to date version of mlv.h?
Ok never mind about the new blocks idea, raw_info has the matrix field I wanted. Though a "TEXT" block seems like a nice idea to me.
Anyway, I found mlv_structures.h on MLV post, and it is under LGPL (what I was hoping to find). However it does not contain raw_info structure, is that because raw_info is from CHDK and is full GPL? (I think I heard about this ages ago)
I am thinking there needs to be an mlv library (somthing like "libmlv"), that developers can use to add MLV support to their propreitary software. It would need to be licensed with LGPL or MIT, and written from scratch. But the GPL raw_info block is currently the main concern. Could it be done using byte offsets to access fields? - someone else calculates the offsets and communicates them to me.
I genuinely want to spread MLV as much as possible. No, I am not planning to sell any propreitary software with MLV support. I just want MLV to be a more widespread raw video format, I think it is perfect suited for that.
But first, I want to make a raw to MLV converter that converts other raw video formats or photo sequences to MLVs, so I can use MLV App with them. No licensing issues here as it will simply be GPL.
Anyone have any thought or advice about this?? About anything... The licensing issues, MLV for other cameras... bad or good ideas?
Ok let me condense the last verbal spaghetti post down to a couple of questions:
1. Is the MLV format suitable to use as a container for other raw video cameras' footage? (thinking of making a converter)
2. Would magic lantern community support the idea of a library (something like "libmlv") being created, with a license that does allow it to be used in proprietary software
Quote from: Ilia3101 on August 16, 2019, 03:42:11 PM
But first, I want to make a raw to MLV converter that converts other raw video formats or photo sequences to MLVs, so I can use MLV App with them.
How cool is that. I guess dng or tiff into mlv would be really convenient here. Or even jpg h264 maybe?
The library also seems like a good idea but I have little experience i this field. Maybe contact g3gg0 and a1ex directly too? Would be nice to see resolve and premiere implementing mlv support ;).
Quote from: Danne on August 18, 2019, 08:53:59 AM
How cool is that. I guess dng or tiff into mlv would be really convenient here. Or even jpg h264 maybe?
I saw in MLV headers that it can have h.264, but IDK if it has ever been tested or put to use (MLV App certainly doesn't handle h264 MLVs :D). DNG or cr2 would be easiest to convert to MLV though, especially if it is one of the already supported ML cameras, and masc found some nice libraries we could use.
Quote from: Danne on August 18, 2019, 08:53:59 AM
The library also seems like a good idea but I have little experience i this field. Maybe contact g3gg0 and a1ex directly too?
Yeah I guess I should reach out to them. I'm just not sure about the licensing, I remember loads of something about Martin Herring's Footage app (Footage was completely closed, this library WILL be open source, but I would want it to be usable in proprietary software). As MLV headers are LGPL it should techincally be allowed... as long as raw_info can be dealt with, maybe using byte offsets
Quote from: Danne on August 18, 2019, 08:53:59 AM
Would be nice to see resolve and premiere implementing mlv support ;).
It would be so satisfying if any of the industry giants were to implement MLV support. Maybe this is wishful thinking though :-\
Ok I found this https://github.com/apertus-open-source-cinema/opencine/blob/master/Source/OCcore/Image/mlv_structure_mod.h
It says it's LGPL, but contains the raw_info structure. Is that a mistake on their part?
Also I will forget the library idea for a bit, as I have heard from Apertus that their GSoC student will soon be finished with MLV format improvements... don't wanna make something already obsolete.
back from holiday,
anything i could help with?
Quote from: Ilia3101 on August 21, 2019, 05:45:03 PM
It says it's LGPL, but contains the raw_info structure. Is that a mistake on their part?
IIRC we aligned that that little part of the structure is fine to made LGPL to get the exchange format accepted.
only if even professional tools are allowed to use the structures, you can undercut commercial products with open source mindset ;)
Quote from: g3gg0 on August 25, 2019, 07:51:26 PM
back from holiday,
anything i could help with?
I'll probably have something soon :)
Quote from: g3gg0 on August 25, 2019, 07:51:26 PM
IIRC we aligned that that little part of the structure is fine to made LGPL to get the exchange format accepted.
Glad to hear
Quote from: g3gg0 on August 25, 2019, 07:51:26 PM
only if even professional tools are allowed to use the structures, you can undercut commercial products with open source mindset ;)
Yep, always fun to do that :D
Following this thread as it seems an important topic to keep up with. Fun facts. Thanks guys!
Following :)
The new(ish) RAWC block does not appear to be in the official mlv_structure.h LGPL file
(https://i.ibb.co/QnVLCYV/Screenshot-2019-10-11-at-21-11-30.jpg)
Wicked! What have you done? ;D
Quote from: masc on October 11, 2019, 10:15:36 PM
Wicked! What have you done? ;D
Almost ready to release, a tool for converting raw photo sequences to MLV. Should be useful for timelapses, or converting BlackMagic CDNG footage to MLV.
This will work much better once a colour matrix block finally gets added to the MLV format. It is currently relying on RAWI.raw_info.color_matrix1 and this commit (https://github.com/ilia3101/MLV-App/commit/9f1377b802a0c5a72e0849392b645e2337749c3c).
@a1ex @g3gg0 can I call a new MLV reading/writing library "libMLV"?
Quote from: Ilia3101 on October 11, 2019, 10:24:01 PM
Almost ready to release, a tool for converting raw photo sequences to MLV. Should be useful for timelapses, or converting BlackMagic CDNG footage to MLV.
This will work much better once a colour matrix block finally gets added to the MLV format. It is currently relying on RAWI.raw_info.color_matrix1 and this commit (https://github.com/ilia3101/MLV-App/commit/9f1377b802a0c5a72e0849392b645e2337749c3c).
@a1ex @g3gg0 can I call a new MLV reading/writing library "libMLV"?
Wow!
Indeed that's wicked @Ilia3101! 8)
Quote from: Ilia3101 on October 11, 2019, 10:24:01 PM
@a1ex @g3gg0 can I call a new MLV reading/writing library "libMLV"?
Green light from my side.
Quote from: Ilia3101 on October 11, 2019, 10:24:01 PM
@a1ex @g3gg0 can I call a new MLV reading/writing library "libMLV"?
absolutely.
thanks!
Quote from: Ilia3101 on October 11, 2019, 10:24:01 PM
Almost ready to release, a tool for converting raw photo sequences to MLV. Should be useful for timelapses, or converting BlackMagic CDNG footage to MLV.
Ilia3101,
What you are planning to do is revolutionary! Many people have already sensed the taste of the RAW-video magic and will not go back, no matter what. Many of them, tired of waiting for more capable and stable ML builds for their Canon cameras, bought the BMPCC4k to continue filming in RAW. Others are waiting for new RAW-video capable cameras to come out on the market. All these people look forward to using MLVApp for post processing their RAW videos. This is where your converter would be extremely useful! In my opinion, MLVApp is better, more intuitive and easier to work with than all other NLE available and is also free. Personally, when grading my most important videos, I prefer it to DaVinci Resolve despite MLVApp's low render speeds.
I keep my thumbs pressed for you to succeed!
@a1ex @g3gg0 Thanks! glad you guys don't mind me taking the name.
Can I ignore MLV_VIDEO_CLASS_H264/MLV_VIDEO_CLASS_JPEG/MLV_VIDEO_CLASS_YUV? I think they have never been implemented is that right?
Quote from: IDA_ML on October 12, 2019, 11:20:06 AM
What you are planning to do is revolutionary! Many people have already sensed the taste of the RAW-video magic and will not go back, no matter what. Many of them, tired of waiting for more capable and stable ML builds for their Canon cameras, bought the BMPCC4k to continue filming in RAW.
Yes I'd really like to create a solution for converting all camera raw formats to MLV, including red/arri/blackmagic if possible.
I have done some research on video raw formats:
- BRAW: Blackmagic claims BRAW is open in some way, but I don't see how that is true. I downloaded the SDK and it's completely propreitary, also I can't find any traces of a open specificaiton for it.
- Arriraw: is an "open format", but you have to buy a 175 euro PDF to see how it works. Or use their propreitary SDK. But it probably won't be too hard to figure out how it works, as it is uncompressed.
- Red raw: 100% propreitary, but there is an SDK for it (also propreitary, but maybe it's a way of getting it out of that format).
So MLV is really the best option, it is truly open, actually free, simple enough to be understood just by looking at mlv.h, and has many original implementations (ML itself, mlv_dump, mlvproducer, mlv app, fastrawviewer, martin hering's app ...)
Might have something later today to release. The writing functionality of libMLV is coming first. Reading a little bit later.
Quote from: Ilia3101 on October 12, 2019, 03:36:31 PM
Can I ignore MLV_VIDEO_CLASS_H264/MLV_VIDEO_CLASS_JPEG/MLV_VIDEO_CLASS_YUV? I think they have never been implemented is that right?
you should honor the flags, i.e. returning smth like LIBMLV_ERR_UNSUPPORTED_ENCODING or similar
@Ilia3101 will you release under permissive license? If you release under GPL is think MLV will not be adopted by some companies. If we want global support for MLV, the library should be permissive (I suggest ISC license (https://en.wikipedia.org/wiki/ISC_license#OpenBSD_license)).
Quote from: g3gg0 on October 12, 2019, 03:54:45 PM
you should honor the flags, i.e. returning smth like LIBMLV_ERR_UNSUPPORTED_ENCODING or similar
Okay will do!
Quote from: Luther on October 12, 2019, 03:55:23 PM
@Ilia3101 will you release under permissive license? If you release under GPL is think MLV will not be adopted by some companies. If we want global support for MLV, the library should be permissive (I suggest ISC license (https://en.wikipedia.org/wiki/ISC_license#OpenBSD_license)).
Yes, I think I will release all new libMLV library code with MIT. I am making it completely original.
Do you think MIT is good? If there is a better option that companies like more, I can use that, just let me know. Edit: just realised you suggested ISC. What is the advantage over MIT?
I thought about LGPL, as it's fully permissive in how it can be used, and mlv_structure.h file is LGPL anyway, but for some reason companies seem to be scared even of LGPL.
Quote from: Ilia3101 on October 12, 2019, 03:57:49 PM
Do you think MIT is good? If there is a better option that companies like more, I can use that, just let me know. Edit: just realised you suggested ISC. What is the advantage over MIT?
I second this too re: advantage w ISC over MIT. Great call!
Regardless just like those mentioned... this is beyond revolutionary and can't describe how much MLV_App has pried me away from major NLE's (for good reasons) in despite of the rendering times and yet that's the beauty of open source!
At the risk of making a fool of myself I thought I would flag an interest here, ie as a non video guy.
The use case for me is taking a series of .cr2 images to simulate a long exposure, convert them onto a MLV file and process that file in MLVapp, ie to simulate a LE exposure longer than the ND or base image I can take.
Looking forward to this Ilia3101. Mlv app integration maybe?
We could add a feature to MLV App for converting other raw formats to MLV, but that doesn't really fit in to the design seamlessly, it would be like a whole separate app within MLV App, so I would like to create a separate GUI app for that (but command line converter coming first).
And as a reading/writing library, it won't be integrated in to MLV App. Partly because it's difficult, but I think it also adds some competition.
I didn't want to release anything yesterday because bit packing was not working, but I sorted it this morning.
Will release some stuff very soon, github.com/ilia3101/LibMLV soon to be made unprivate.
Also would like advice/help on compiling methods. Want it to work on Windows too.
Quote from: garry23 on October 12, 2019, 07:43:05 PM
At the risk of making a fool of myself I thought I would flag an interest here, ie as a non video guy.
The use case for me is taking a series of .cr2 images to simulate a long exposure, convert them onto a MLV file and process that file in MLVapp, ie to simulate a LE exposure longer than the ND or base image I can take.
That should be possibe.
Quote from: Ilia3101 on October 13, 2019, 11:52:17 AM
And as a reading/writing library, it won't be integrated in to MLV App. Partly because it's difficult, but I think it also adds some competition.
I didn't want to release anything yesterday because bit packing was not working, but I sorted it this morning.
Will release some stuff very soon, github.com/ilia3101/LibMLV soon to be made unprivate.
Also would like advice/help on compiling methods. Want it to work on Windows too.
Awesome.
By the way. Is it linux or mac right now?
both working
Quote from: Ilia3101 on October 13, 2019, 11:52:17 AM
Also would like advice/help on compiling methods. Want it to work on Windows too.
If you like to have it working on all platforms with mostly one code base: Qt is again our best friend ;)
You wrote it again in C/C++?
Quote from: masc on October 13, 2019, 03:11:23 PM
If you like to have it working on all platforms with mostly one code base: Qt is again our best friend ;)
You wrote it again in C/C++?
Qt for the converter GUI yes, I agree. But I want the library itself to depend on almost nothing. CMAKE seems like a good compiling solution just for the library.
Yes, it's written in C, But it will also have a nice C++ wrapper.
This time I'm not making the mistake of having millions of variables like mlvObject_t in MLV App has. LibMLV reading object contains only MLV blocks themselves and array of where frames are in the file (and which file).
Quote from: Ilia3101 on October 13, 2019, 03:33:47 PM
Qt for the converter GUI yes, I agree.
Qt is not just GUI. You can also build command line tools in Qt.
Quote from: masc on October 13, 2019, 03:39:47 PM
Qt is not just GUI. You can also build command line tools in Qt.
You mean use qt project (.pro) and let Qt do compiling work?
Yapp, exactly. I am just not 100% sure if that works without Qt libs - this would be overkill. To be tested...
Edit: if you open QtCreator -> new project -> non-qt project -> Plain C/C++ Application..." This should do the job for Win/Linux/OSX.
(https://i.ibb.co/kxtYCKN/Bildschirmfoto-2019-10-13-um-20-53-37.png)
Ok here's a little bit of libMLV: https://github.com/ilia3101/LibMLV (raw2mlv included, compiles on mac and linux, writing functionality not released yet, generally unfinished)
Quite tired from all this, macOS compiling/linking decided to break today, so I'm also going to have a break.
Quote from: masc on October 13, 2019, 04:10:18 PM
Yapp, exactly. I am just not 100% sure if that works without Qt libs - this would be overkill. To be tested...
Edit: if you open QtCreator -> new project -> non-qt project -> Plain C/C++ Application..." This should do the job for Win/Linux/OSX.
Thanks. I will try using that for something. I have a command program thing that is simple C, won't use it for that, as it really would be overkill. But there will be more than one program with libMLV so it could come in useful. Definitely going to use Qt for the GUI app.
Awesome progress so far fellas! 8)
Quote from: Ilia3101 on October 13, 2019, 09:52:46 PM
Thanks. I will try using that for something. I have a command program thing that is simple C, won't use it for that, as it really would be overkill. But there will be more than one program with libMLV so it could come in useful. Definitely going to use Qt for the GUI app.
If you like to try with Qt, this would be your .pro file:
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += read_raw.c \
camera_matrices.c \
raw2mlv.c \
../LibMLV/MLVFrameUtils.c \
../LibMLV/MLVWriter.c
HEADERS += \
../LibMLV/LibMLV.h \
../LibMLV/mlv_structs.h \
../LibMLV/MLVFrameUtils.h \
../LibMLV/MLVWriter.hShouldn't be much overkill, because it just uses the compiler and nothing else for building. But it is nice to handle, because you can use QtCreator's editor and buttons to compile - so much comfort.
Wow thank you! I will try that out. I'll try and add as many build methods as possible to all aspects of the library later.
Quote from: masc on October 14, 2019, 08:13:49 PM
But it is nice to handle, because you can use QtCreator's editor and buttons to compile - so much comfort.
Also allows you to use "qmake" command, comfort for me too :D
Quote from: Ilia3101 on October 12, 2019, 03:57:49 PM
Edit: just realised you suggested ISC. What is the advantage over MIT?
Both say basically the same: use how you want, just mention authors name. Legally speaking it is also the same (AFAIK, I'm not a lawyer). The difference is: ISC is very short and has less ambiguity. It's also easier for bigger projects to use, because it doesn't increase the text size too much.
Quote from: Ilia3101 on October 13, 2019, 03:33:47 PM
But I want the library itself to depend on almost nothing. CMAKE seems like a good compiling solution just for the library.
Nice. I think Qt is unnecessary. Even CMAKE is. Why not simply use make (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html)?
Quote from: Luther on October 15, 2019, 02:09:44 AM
Both say basically the same: use how you want, just mention authors name. Legally speaking it is also the same (AFAIK, I'm not a lawyer). The difference is: ISC is very short and has less ambiguity. It's also easier for bigger projects to use, because it doesn't increase the text size too much.
Ah ok. I may switch to this, still undecided on most aspects of libMLV. I will see what similar libraries are licensed with.
Quote from: Luther on October 15, 2019, 02:09:44 AM
Nice. I think Qt is unnecessary. Even CMAKE is. Why not simply use make (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html)?
LibRaw has many build files, makefile, CMAKE, Visual Studio project, even Qt project. I think it's worth trying to have many options in libMLV, so it can integrate with as many software projects as possible, as easy as possible. I like makefiles, but I also don't understand them and they are quite hard to make compatible with all systems.
Edit: maybe I will just do makefiles, turns out even microsoft has an official implementation of make called NMAKE, that uses same makefile format.
Hi Ilia3101. Your tool is working as expected. Very nice. Is it possible to add the Unique Camera Model tag into the exported dng format? Well the tag is there, only the camera model is reported as Unknown Camera
Unique Camera Model : Unknown Camera
Quote from: Danne on November 08, 2019, 07:36:03 AM
Hi Ilia3101. Your tool is working as expected. Very nice. Is it possible to add the Unique Camera Model tag into the exported dng format? Well the tag is there, only the camera model is reported as Unknown Camera
Unique Camera Model : Unknown Camera
Do you mean the
mlv_idnt_hdr_t->cameraModel (https://github.com/ilia3101/MLV-App/blob/master/src/mlv/mlv.h#L206) field?
Is this a Canon/ML specific thing ? Or do all cameras have this and can I extract it with Libraw?
Camera model is correctly reported but not the unique tag. The name should be the same as for the camera model tag.
Some helping out utilizing raw2mlv workflows. Only mac atm:
https://www.magiclantern.fm/forum/index.php?topic=24631.msg222250#msg222250
Hmh ... found this. Any issue with MLV?
https://www.eoshd.com/comments/topic/39917-red-claim-victory-in-apple-raw-patent-battle/?tab=comments#comment-327129
Quote
Big bummer. The RED patent also poses a threat to MagicLantern as MLV is compressed RAW video.
Fuck. REally Annoying news.
I think that person on EOSHD is wrong (luckily), as from what I've heard RED's patent is for "visually lossless" compression, which just means high quality lossy (STILL A RIDICULOUS PATENT). However I have not read the whole patent so Im not an expert.
This video explains it well: https://www.youtube.com/watch?v=NZ20yQhMYx4 (https://www.youtube.com/watch?v=NZ20yQhMYx4) (all of this guy's videos about RED are great)
And here's the clip of Jim pretending that REDCODE didn't exist at a time when RED had already revealed everything about it: https://youtu.be/faEXjulgujk?t=55m53s (https://youtu.be/faEXjulgujk?t=55m53s)
Quote from: Danne on November 09, 2019, 01:09:26 PM
Camera model is correctly reported but not the unique tag. The name should be the same as for the camera model tag.
Do you know if I can get the value for this tag using LibRaw?
Is this a commonly used way of identifying cameras? Or something that's only used/known in the Magic Lantern world?
If I cannot get it with LibRaw, I will have to add slightly annoying code that matches camera name to this tag, and it will only be useful for ML Canons anyway.
Lack of time here but the tag is used with adobe camera raw. And yeah. Camera tag for dng files.
Sorry, not familiar with libraw and how it works :(
Sounds like something that libraw should know about. I will look in to it.
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?
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.
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:
Quote from: g3gg0 on July 15, 2013, 10:58:23 PMas 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
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?
Quote from: ilia3101 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?
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.
Quote from: Luther on February 20, 2020, 09:43:15 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.
Quote from: Luther on February 20, 2020, 09:43:15 PM
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?
Quote from: ilia3101 on February 20, 2020, 10:27:12 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 (https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document) 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.
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?
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?
I want to continue work on LibMLV, I plan to copy the Lua API style.
QuoteEXIF 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.
Quote
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?
Ilia, do you may want to chat with g3gg0 using discord. Did you create an account yet?
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?
It doesn't make a big difference. Just start.
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?
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).
Quote from: names_are_hard on September 30, 2021, 08:52:59 PM
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 😭)
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).
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).
QuoteMIT/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.
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.
@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:
Quote from: ilia3101 on September 30, 2021, 08:31:56 PM
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?
Quote from: g3gg0 on September 30, 2021, 10:01:10 PM
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.
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.
Thank you so much for the in-depth reply and explanation.
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)
yep, thus there was a LGPL version for the headers to make it even more clear ;)