> On Feb 5, 2018, at 4:20 PM, Jerome Martinez <jer...@mediaarea.net> wrote: > > On 03/02/2018 14:48, Michael Niedermayer wrote: >> >> I hope this will not reduce interrest in working on a improved >> 9-16bit mode in v4. > > I don't like to put politics in technical stuff, but here this is politics, > and I think that blocking an easy improvement of FFV1 v3 encoding/decoding in > FFmpeg (actually just using the current FFV1 v3, and also v1 actually, > specification without having artificial limitations about bit depths for a > specific color space, i.e. 16-bit support was already there for YUV before I > work on FFV1) just for forcing people to do a completely different work (e.g. > working on FFV1 v4) is not fair and IMO is not in the idea behind open source. > IMO if interest for 9-16bit (side note: I don't see why 8-bit should not be > in the range, some ideas I have for v4 are useful also for 8-bit) mode in v4 > is reduced, that would only mean that v3 is already so great and/or just that > people have no better idea right now, it is not bad, and both works (using v3 > at the maximum of its possibilities and working on v4) are separate works. > FYI criticism I saw about FFV1 is not compression ratio but speed (playing a > 4K stream is just impossible on a "normal" machine, you need a very expensive > CPU for that) so my plan is to focus on speed improvement in priority. It > could be v4 stuff (incompatible changes), or v3 (encoder/decoder > optimization), depending of what I find.
IMHO, improved higher bit depths in version 4 is very interesting. We already have a few noted exceptions where version 4 is intended to fix and optimize a few things of version 3 (signed 16 bit handling, RGB plane order for 9-15 bits), so a change in optimization of high bit depth handling seems already appropriate for consideration. >> [...] >> >>> Last but not least, since almost two years now it's impossible >>> to work on the development of FFV1 v4. It's always the wrong >>> time and/or the wrong place every time I am doing something for >>> this cause. Why? This is extremely frustrating. >> I want to understand this too. IMO v4 development should be more >> important than or at least equally to the v3 draft polishing and neither >> should block the other. > > Also politics, but I don't understand who is blocking v4 from your point of > view. "impossible to work on v4"? Where? As far as I see 1 person (me) said > his priority is having FFV1 v3 becoming a standard (so IETF related work) and > widely used (so any bit depth for any supported color space in v3 because it > is an easy demonstration that FFV1 is versatile without having to wait for v4 > R&D, especially because v3 bitstream design is already pretty good and > versatile) because this is what I need, and my personal case is not blocking > anyone else for sending patches for either FFV1 specifications or FFmpeg code > about v4. Eager to see patch proposals for v4 (and v3 if it does not break > support of files in the wild), whoever feeling blocked with his patches > should send patch proposals to either FFmpeg (code) or CELLAR mailing list > (bitstream format). > > That said, I plan to add more pix_fmt support for FFV1 v3 (which is already a > good format!) support in FFmpeg and some optimization ideas beside my work > for IETF spec, with the hope we could speak about technical issues (e.g. more > optimization hints or info about wrong code or warning about that it breaks > the bitstream specs as currently written), leaving aside politics. In the cellar charter and timeline, the effort to produce a informational specification for FFV1 video codec versions 0, 1 and 3 precedes the effort to produce a specification for FFV1 video codec version 4. Initially I anticipated that the version 4 specification would be a fork from the completed version 0,1,3 draft; however, I think the current approach (one doc that ‘makes’ both outputs) works well to allow version 4 work to proceed without blocking any remaining version 0,1,3 work. Still I suggest that we resolve https://github.com/FFmpeg/FFV1/pull/87 and https://github.com/FFmpeg/FFV1/pull/71 soon as IMHO the version 0,1,3 informational specification is very close to a last call and submission to the IESG (chairs are welcome to offer other opinions ;) ). So while I encourage resolution to these pull requests, it seems we have a good system to manage concurrent work on both FFV1 goals of the charter. Kind Regards, Dave Rice _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
