Re: [Cellar] FFV1 Version 4

Kieran O Leary <kieran.o.leary@gmail.com> Wed, 06 January 2016 10:11 UTC

MIME-Version: 1.0
In-Reply-To: <568C0516.3040605@mediaarea.net>
References: <CAO7v-1TCNOcqhv=JR5dMWhibD=kLyQwLztk8RG3v-rtegn7s7Q@mail.gmail.com> <E89E5459-836A-4FD7-BA52-6F75AFD67083@dericed.com> <20160105163439.GA13213@nb4> <568BF59B.6050106@mediaarea.net> <20160105174445.GC13213@nb4> <568C0516.3040605@mediaarea.net>
Date: Wed, 06 Jan 2016 10:11:55 +0000
Message-ID: <CAO7v-1R44SDSZWZ_55SBT0vE+ka7e+s5V9suiW3emM-Z-ViS2A@mail.gmail.com>
From: Kieran O Leary <kieran.o.leary@gmail.com>
To: Jerome Martinez <jerome@mediaarea.net>
Content-Type: multipart/alternative; boundary="001a1135914c77fe550528a79549"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/g8mLLjiNQI_KcVH-KtK_042cSz8>
Cc: Christoph Gerstbauer <christophgerstbauer@gmail.com>, cellar@ietf.org
Subject: Re: [Cellar] FFV1 Version 4
Precedence: list

Hi guys,

I'd like to propose the inclusion of Logarithmic information within the
FFV1 codec when transcoding from LOG RGB DPX.

This could be very beneficial to moving image archives who want to
losslessly compress their LOG DPX scans to FFV1. Currently if the FFV1
transcode is converted back to DPX, it is with Linear values, making it
unsuitable for preservation purposes.

It appears that ffmpeg doesn't support LOG in general (or maybe this lack
of support is just in DPX), from what I've gleaned from the mailing list,
so perhaps the LOG 'flag' within the FFV1 bitstream is only half the
battle? This conversation between Carl Eugen Hoyos and Dave Rice is my
source for this info, so apologies if I'm taking them up the wrong way :
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025634.html

I would love to know if this is possible, or if anyone else would be
interested in this feature.
Here's some ffmpeg-user threads about the subject from the past year:
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025625.html &
https://lists.mplayerhq.hu/pipermail/ffmpeg-user/2015-December/029536.html

Best regards,

Kieran O'Leary

On Tue, Jan 5, 2016 at 6:01 PM, Jerome Martinez <jerome@mediaarea.net>
wrote:

> Le 05/01/2016 18:44, Michael Niedermayer a écrit :
>
>> the global header / extradata / ConfigurationRecord can and should be
>> duplicated at the container level. repeating it at the codec level would
>> make finding a duplicate element relativly hard as one probably would have
>> to scan the whole file. A container could contain something like an index
>> to point to redundant copies, while at codec level this would not work so
>> easily
>>
>
> As far as I know, I never seen duplicated ConfigurationRecord.
> I guess we should add such option (e.g. in Matroska specs, there is
> already a discussion about duplicated parts) for people wanting to secure
> this important part.5
>
> [...]
>>
>> different picture_structures in 1 frame dont make sense or do i
>> misunderstand ?
>>
>
> Some people may be crazy enough for wanting and trying e.g.:
> - slice 0,0 top field first
> - slice 0,0 (the same as the line above) bottom field first
> - slice 0,1 progressive
> - slice 1,0 bottom field first
> - slice 1,0 (the same as the line above) top field first
> - slice 1,1 progressive
> (we have MABFF feature in AVC/H264, so I don't invent too much)
>
> and for the moment, I see nothing in the FFV1 specification forbidding
> that (did I miss something?)
> So either we are clear it is authorized (and the reference decoder can
> deal with it), or we explicitly forbid it (picture_structure is same in all
> slices of a frame)
>
>
>
>> Additionally, picture_structure, sar_num, sar_dem (and other?) do
>>> not use to change (or they change as often as  chroma_planes,
>>> h_chroma_subsample, alpha_plane...), so we may consider to put them
>>> in the ConfigurationRecord() too (and we may need to take care of
>>> duplicating it in the container?)
>>>
>> they could optionally be put in the global ConfigurationRecord
>> but it should stay possible for them to change if thats what the
>> source video we encode is doing
>>
>
> I like the idea to have such optional possibility. this is not a lot, but
> always some bits of compression.
> A candidate for FFV1 version 4 feature!
>
> Jérôme
>

[Cellar] FFV1 Version 4 Kieran O Leary
Re: [Cellar] FFV1 Version 4 Dave Rice
Re: [Cellar] FFV1 Version 4 Michael Niedermayer
Re: [Cellar] FFV1 Version 4 Michael Niedermayer
Re: [Cellar] FFV1 Version 4 Michael Niedermayer
Re: [Cellar] FFV1 Version 4 Jerome Martinez
Re: [Cellar] FFV1 Version 4 Michael Niedermayer
Re: [Cellar] FFV1 Version 4 Jerome Martinez
Re: [Cellar] FFV1 Version 4 Kieran O Leary
Re: [Cellar] FFV1 Version 4 Peter B.
Re: [Cellar] FFV1 Version 4 Reto Kromer
Re: [Cellar] FFV1 Version 4 Jerome Martinez
[Cellar] Fwd: Re: FFV1 Version 4 Reto Kromer
Re: [Cellar] FFV1 Version 4 Peter B.
Re: [Cellar] FFV1 Version 4 Dave Rice
Re: [Cellar] FFV1 Version 4 Reto Kromer