Magic Lantern Forum

Developing Magic Lantern => General Development => Topic started by: ilia3101 on August 08, 2019, 12:09:00 AM

Title: The MLV format
Post by: ilia3101 on August 08, 2019, 12:09:00 AM
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?
Title: Re: The MLV format
Post by: ilia3101 on August 16, 2019, 03:42:11 PM
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?
Title: Re: The MLV format
Post by: ilia3101 on August 18, 2019, 01:27:07 AM
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
Title: Re: The MLV format
Post by: Danne on August 18, 2019, 08:53:59 AM
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 ;).
Title: Re: The MLV format
Post by: ilia3101 on August 18, 2019, 05:17:44 PM
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.

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

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 :-\
Title: Re: The MLV format
Post by: ilia3101 on August 21, 2019, 05:45:03 PM
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.
Title: Re: The MLV format
Post by: g3gg0 on August 25, 2019, 07:51:26 PM
back from holiday,

anything i could help with?

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 ;)
Title: Re: The MLV format
Post by: ilia3101 on August 26, 2019, 02:49:27 PM
back from holiday,

anything i could help with?

I'll probably have something soon :)

IIRC we aligned that that little part of the structure is fine to made LGPL to get the exchange format accepted.

Glad to hear

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
Title: The MLV format
Post by: DeafEyeJedi on September 07, 2019, 08:59:09 AM
Following this thread as it seems an important topic to keep up with. Fun facts. Thanks guys!
Title: Re: The MLV format
Post by: extremelypoorfilmaker on September 08, 2019, 06:44:24 PM
Following :)
Title: Re: The MLV format
Post by: ilia3101 on October 01, 2019, 08:13:42 PM
The new(ish) RAWC block does not appear to be in the official mlv_structure.h LGPL file
Title: Re: The MLV format
Post by: ilia3101 on October 11, 2019, 10:12:59 PM
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FQnVLCYV%2FScreenshot-2019-10-11-at-21-11-30.jpg&hash=8a466cd13a64f1b9d98dd27cf4527807)
Title: Re: The MLV format
Post by: masc on October 11, 2019, 10:15:36 PM
Wicked! What have you done?  ;D
Title: Re: The MLV format
Post by: ilia3101 on October 11, 2019, 10:24:01 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"?
Title: Re: The MLV format
Post by: Danne on October 12, 2019, 05:17:43 AM
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!
Title: The MLV format
Post by: DeafEyeJedi on October 12, 2019, 06:31:40 AM
Indeed that’s wicked @Ilia3101! 8)
Title: Re: The MLV format
Post by: a1ex on October 12, 2019, 08:11:35 AM
@a1ex @g3gg0 can I call a new MLV reading/writing library "libMLV"?

Green light from my side.
Title: Re: The MLV format
Post by: g3gg0 on October 12, 2019, 09:49:43 AM
@a1ex @g3gg0 can I call a new MLV reading/writing library "libMLV"?

absolutely.
thanks!
Title: Re: The MLV format
Post by: IDA_ML on October 12, 2019, 11:20:06 AM
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!
Title: Re: The MLV format
Post by: ilia3101 on October 12, 2019, 03:36:31 PM
@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?



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:

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.
Title: Re: The MLV format
Post by: g3gg0 on October 12, 2019, 03:54:45 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
Title: Re: The MLV format
Post by: 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)).
Title: Re: The MLV format
Post by: ilia3101 on October 12, 2019, 03:57:49 PM
you should honor the flags, i.e. returning smth like LIBMLV_ERR_UNSUPPORTED_ENCODING or similar

Okay will do!

@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.
Title: Re: The MLV format
Post by: DeafEyeJedi on October 12, 2019, 07:41:26 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!
Title: Re: The MLV format
Post by: 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.

Title: Re: The MLV format
Post by: Danne on October 12, 2019, 07:50:53 PM
Looking forward to this Ilia3101. Mlv app integration maybe?
Title: Re: The MLV format
Post by: ilia3101 on October 13, 2019, 11:52:17 AM
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.
Title: Re: The MLV format
Post by: ilia3101 on October 13, 2019, 11:53:15 AM
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.
Title: Re: The MLV format
Post by: Danne on October 13, 2019, 11:56:29 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?
Title: Re: The MLV format
Post by: ilia3101 on October 13, 2019, 12:50:11 PM
both working
Title: Re: The MLV format
Post by: masc on October 13, 2019, 03:11:23 PM
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++?
Title: Re: The MLV format
Post by: ilia3101 on October 13, 2019, 03:33:47 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).
Title: Re: The MLV format
Post by: masc on October 13, 2019, 03:39:47 PM
Qt for the converter GUI yes, I agree.
Qt is not just GUI. You can also build command line tools in Qt.
Title: Re: The MLV format
Post by: ilia3101 on October 13, 2019, 03:47:41 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?
Title: Re: The MLV format
Post by: 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.
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FkxtYCKN%2FBildschirmfoto-2019-10-13-um-20-53-37.png&hash=6a741ad587df223388ae5b8cb0735bb5)
Title: Re: The MLV format
Post by: ilia3101 on October 13, 2019, 09:52:46 PM
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.


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.
Title: Re: The MLV format
Post by: DeafEyeJedi on October 13, 2019, 11:24:56 PM
Awesome progress so far fellas!  8)
Title: Re: The MLV format
Post by: masc on October 14, 2019, 08:13:49 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:
Code: [Select]
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.h
Shouldn'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.
Title: Re: The MLV format
Post by: ilia3101 on October 14, 2019, 08:28:31 PM
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.

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
Title: Re: The MLV format
Post by: Luther on October 15, 2019, 02:09:44 AM
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.

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)?
Title: Re: The MLV format
Post by: ilia3101 on October 16, 2019, 06:17:24 PM
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.

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.
Title: Re: The MLV format
Post by: 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
Code: [Select]
Unique Camera Model             : Unknown Camera
Title: Re: The MLV format
Post by: ilia3101 on November 09, 2019, 12:46:55 PM
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
Code: [Select]
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?
Title: Re: The MLV format
Post by: 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.
Title: Re: The MLV format
Post by: Danne on November 10, 2019, 03:50:12 PM
Some helping out utilizing raw2mlv workflows. Only mac atm:
https://www.magiclantern.fm/forum/index.php?topic=24631.msg222250#msg222250
Title: Re: The MLV format
Post by: Walter Schulz on November 10, 2019, 05:32:42 PM
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.
Title: Re: The MLV format
Post by: ilia3101 on November 10, 2019, 07:21:47 PM
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)
Title: Re: The MLV format
Post by: ilia3101 on November 10, 2019, 08:11:19 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.
Title: Re: The MLV format
Post by: Danne on November 10, 2019, 08:21:55 PM
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 :(
Title: Re: The MLV format
Post by: ilia3101 on November 10, 2019, 08:37:39 PM
Sounds like something that libraw should know about. I will look in to it.
Title: Re: The MLV format
Post by: Danne 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?
Title: Re: The MLV format
Post by: ilia3101 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.
Title: Re: The MLV format
Post by: ilia3101 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

Title: Re: The MLV format
Post by: 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?
Title: Re: The MLV format
Post by: Luther 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.
Title: Re: The MLV format
Post by: ilia3101 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?
Title: Re: The MLV format
Post by: Luther 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 (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.
Title: Re: The MLV format
Post by: ilia3101 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?
Title: Re: The MLV format
Post by: g3gg0 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?
Title: Re: The MLV format
Post by: ilia3101 on September 30, 2021, 08:31:56 PM
I want to continue work on LibMLV, I plan to copy the Lua API style.

Quote
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.

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?
Title: Re: The MLV format
Post by: Walter Schulz on September 30, 2021, 08:41:58 PM
Ilia, do you may want to chat with g3gg0 using discord. Did you create an account yet?
Title: Re: The MLV format
Post by: ilia3101 on September 30, 2021, 08:44:41 PM
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?
Title: Re: The MLV format
Post by: Walter Schulz on September 30, 2021, 08:48:09 PM
It doesn't make a big difference. Just start.
Title: Re: The MLV format
Post by: names_are_hard on September 30, 2021, 08:52:59 PM
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?
Title: Re: The MLV format
Post by: ilia3101 on September 30, 2021, 09:45:14 PM
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 😭)
Title: Re: The MLV format
Post by: names_are_hard on September 30, 2021, 09:54:22 PM
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).
Title: Re: The MLV format
Post by: ilia3101 on September 30, 2021, 09:59:59 PM
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).

Quote
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.
Title: Re: The MLV format
Post by: 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.
only the real code is GPLed to make people work on the same code.
Title: Re: The MLV format
Post by: ilia3101 on September 30, 2021, 10:04:21 PM
@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.
Title: Re: The MLV format
Post by: g3gg0 on September 30, 2021, 10:45:47 PM
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.
Title: Re: The MLV format
Post by: ilia3101 on September 30, 2021, 11:39:33 PM
Thank you so much for the in-depth reply and explanation.