> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Saturday, May 21, 2016 3:25 AM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to > openh264 1.6 > > On Mon, Mar 7, 2016 at 6:05 PM, Stefano Sabatini <stefa...@gmail.com> > wrote: > > In particular, the slice mode API was changed in commit: > > > > commit 33c378f7b791310e4cb64b53e2bb8f3f3bded105 > > Author: sijchen <sijc...@cisco.com> > > Date: Tue Nov 10 09:50:06 2015 -0800 > > > > change API for slicing part for easier usage (the UseLoadBalancing flag > > is > still under working) > > > > This fixes compilation with latest version of openh264. > > --- > > From the author of this wrapper: > > [20:23:22] <wbs> just fwiw, the openh264 patch that somebody just > sent, for fixing compilation with 1.6 (which is not released) is just > awful. it changes defaults for lots of options, it changes names for > options, etc, all in one single patch (which breaks compilation with > any earlier version) > [20:23:47] <wbs> if one wants to add support for 1.6, it shouldn't > break support for earlier versions. and 1.6 isn't released, so the > actual api for that version may still change > [20:24:06] <wbs> so I would just tell people to stick it and not try > to "support" an unreleased version which is still open for changes > > I agree with this assessment, dropping support for any and all > released versions of the library in favor of a unreleased > in-development version seems bad. > Can't we support both, and address his comments about changing the > options etc? > > - Hendrik
FWIW, we at Kodak Alaris are actively using openh264 1.6 (OK so it's not officially released) with FFmpeg. I have manually applied the 1.6 related patches, AND I have an FFmpeg change (soon to be submitted) to support other new capabilities in 1.6. What I would like to see is openh264 1.6 become an official release (soon!), with interface changes conditionally compiled so as not to break builds using older versions. Also, perhaps the pre-1.6 options could be transparently mapped into the new 1.6 options so that there would be a smooth transition. If it would help move this along, I will tentatively volunteer to the do some or all of the work. Greg W., Kodak Alaris _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel