search

FFmpeg / FFV1

The FFV1 lossless video codec specification.
Other
154 stars 35 forks source link

[v4] implementation of additional image data #47

Open retokromer opened 7 years ago

retokromer commented 7 years ago

Today the data used for restoration (e.g. from infrared scanning) are often stored into the alpha channel, which is not a proper solution, as discussed in https://github.com/FFmpeg/FFV1/pull/31. At least proper metadata are needed.

retokromer commented 7 years ago

On the scanner side e.g. Scanity from DTF (aka Prasad) and ARRISCAN from ARRI use this mechanism. On the software side e.g. Diamant from HS-Art Digital Service or DRS Nova from MTI Film.

JeromeMartinez commented 7 years ago

Is there a flag in the created file from such tool indicating that the 4th channel is not really alpha, or do we have to assume it from the e.g. software name?

retokromer commented 7 years ago

I have to check this as the lab. As long as I can remember (but after a stroke my memory is not good anymore, so please take this cum grano salis), the files we had to deal with didn’t have a flag, no one flagged I can remember.

retokromer commented 7 years ago

This week I did some checking on the softwares I can easily access. Sadly, the software name is not a sufficient flag, as one software can usually export different flavours of the same format, in a more or less transparent way. Additionally the metadata are not always consistent between different versions of the same software!

I would suggest again the double strategy I mentioned in Berlin:

The only improvement of my suggestion since Berlin is that – following some excellent arguments made on the Cellar list and/or here on GitHub – I changed my mind: I suggest now to store this metadata both in the codec and in the container, and to consider codec over container in case of divergence.

retokromer commented 7 years ago

Closing as open for longtime.

dericed commented 7 years ago

-1

retokromer commented 7 years ago

@dericed It’s useless and may even be confusing, in my opinion, to keep open issues too long. I have understood that in the current version of FFV1 this will not be considered. When the work on the new version will start, I might publish an updated list with my wishes which would include this one.

JeromeMartinez commented 7 years ago

We could decide to have a label "enhancement" for such ticket, in order to have them categorized. For the moment, it is true that we focus on v0-3 when we have time for improvements, but I think it is good to keep ideas for v4+ in this tracker so we don't forget them.

michaelni commented 7 years ago

@dericed It’s useless and may even be confusing, in my opinion, to keep open issues too long. I have understood that in the current version of FFV1 this will not be considered. When the work on the new version will start, I might publish an updated list with my wishes which would include this one.

I think we can just work on the next version and update and edit the specificiation and implementation as needed. The specification/draft built for IETF needs to omit these possibly but that should not keep us from working on them. We just might need a way for "make" to drop sections that dont belong in the current IETF draft

ablwr commented 7 years ago

Agreed, better to tag with something like 'enhancement' or even 'v4' than to close the issue entirely.

retokromer commented 6 years ago

Seems not to be of interest. I give up.

michaelni commented 6 years ago

I think this should be kept open

retokromer commented 6 years ago

OK, I reopen and unfollow FFV1 as well.

Context: Censored.

JeromeMartinez commented 6 years ago

@retokromer it takes time, right, but taking time does not mean that it is not welcome. Some words are off topic.

retokromer commented 6 years ago

FYI: Tests with the new ProRes RAW were successful. However, this covers just a little part of my wish about Bayer.

retokromer commented 5 years ago

FYI: Bayer-based content can easily be encoded as greyscale content. It needs just two additional bits to encode a classic RGB filters disposition (e.g. bggr).

richardpl commented 5 years ago

I think best approach is to send patches to ffmpeg-devel with actual implementation?

retokromer commented 5 years ago

My approach is not supported by two out of three authors of the specification, therefore I would just loose my time… That said, I‘m personally in favour of having first an in-depth discussion on the current bit-stream and on the changes which possibly might be necessary in version 4. (And I’ll refrain here from complaining about the toxic climate inside the FFmpeg project.)