[FFmpeg-devel] [Cellar] [PATCH] FFV1: make RGB48 support as non-experimental

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 09:20:15PM +0100, Jerome Martinez wrote:
> On 07/01/2018 20:08, Michael Niedermayer wrote:
> >[...]
> >This is correct but i think misleading a bit
> >the 17bit case this is about uses a seperate codepath.
> 
> For your (FFmpeg) encoder and decoder. Not mine (same code path is used for
> 8/10/12/16/... bit RGB and YUV with my encoder and decoder).
> Again, we mix up bitstream specification and FFmpeg implementation.

The seperation of 16bit and >16bit results out of the data type size
fitting or not fitting in "int16".

A space/cache efficient implementation, possibly one using SIMD would
use seperate codepaths for 16 and > 16 on a normal architecture thats based on
8bit bytes.

Its part of spec design what "an efficient implementation" would/could do


[...]
> >
> >If we change the bitstream in a future version, which i belive we
> >should consider. Then we have an additional "old" version of the 17bit path
> >that needs to be supported in implementations.
> 
> question: How would you detect old version, from all encoders (not only
> FFmpeg)? there is nothing permitting that in the bitstream AFAIK (for v1: no
> micro_version; for v3: micro version >4 must be compatible with v4 as v4 is
> flagged stable).
> So it is "bitstream is in stone" now, for at least versions 0, 1, 3. Reason
> I speak about R&D with version 4 bitstream (I don't speak about FFmpeg),
> which is still flagged as experimental for all files.

very simple, the lowest version that we can make that change in without
causing any pain to people using ffv1 and without breaking the spec.


[...]
> >
> >But it wasnt intended as a "bitstream is in stone, encoder might mismatch
> >the spec" at the time.
> 
> I disagree: the idea behind CELLAR is that all encoders **must** match the

you disagree what i mean in a years old commit in ffmpeg i authored ?


> spec, or there is misunderstanding to clarify. Else everyone does his own
> version of FFV1, and we can not work together on an unique lossless
> compression format. The spec is expected to be the reference (for versions
> 0, 1, 3 for the moment) and encoders are expected to match the spec.

you make no sense
This code was intended to be used for developing the next version, that didnt
happen. If it did happen the code in the implementation would have changed
and once it was looking optimal a suggestion with test results would have
been posted to CELLAR to update the draft/spec. If that update did happen
then once its "stable" the check would have been removed from the encoder
implementation so people could use it.


[...]

> 
> >There is no question that with a unlimited bitdepth, real implementations
> >will never support some depths
> 
> Whatever is the support from the encoders you know, you can not know what
> was created by others based on the bitstream specification. so the bitstream
> is specified (for versions 0, 1, 3) for all bit depths and we can not change
> that now, as it is written for a long time in spec that the spec is flagged
> stable for these versions.

I can know what is possible with real implementations build by others because
they are constrained by the same physical laws and space and matter available
in the observable universe.


> 
> The question is not what is the support from decoder x, the question is that
> if there is a plan to break the compatibility between current version of
> FFV1 draft and future versions of this document.

I think its more like a circular reference
The draft/spec intended to describe the existing status quo
and while in the implementation something was marked experimental this 
detail was lost in the spec 


[...]

> I confirm that RGB48 files are already in the wild, as it is needed by some
> archives, and I confirm that they rely on MediaConch for testing the
> conformance compared to the specification.

Thanks, then its probably best if we support this format in en and decoder
implementations. As its out there already

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180108/cac7557d/attachment.sig>