| Message ID | 20170413200033.49386-1-atomnuker@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> > --- > src/index | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/src/index b/src/index > index c203676..1b8a037 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,59 @@ > News > </h1> > > + <h3 id="pr3.3">April 13th, 2017, FFmpeg 3.3 "Hilbert"</h3> > + <p> > + <a href="download.html#release_3.3">FFmpeg 3.3 "Hilbert"</a>, a new > + major release, is now available! Some of the highlights: > + </p> > + <ul> > + <p> > + <li>Apple Pixlet decoder</li> > + <li>NewTek SpeedHQ decoder</li> > + <li>QDMC audio decoder</li> > + <li>PSD (Photoshop Document) decoder</li> > + <li>FM Screen Capture decoder</li> > + <li>ScreenPressor decoder</li> > + <li>XPM decoder</li> > + <li>DNxHR decoder fixes for HQX and high resolution videos</li> > + <li>ClearVideo decoder (partial)</li> > + <li>16.8 and 24.0 floating point PCM decoder</li> > + <li>Intel QSV-accelerated VP8 video decoding</li> > + </p> > + <p> > + <li>native Opus encoder</li> > + <li>DNxHR 444 and HQX encoding</li> > + <li>Quality improvements for the (M)JPEG encoder</li> > + <li>VAAPI-accelerated MPEG-2 and VP8 encoding</li> > + </p> > + <p> > + <li>premultiply video filter</li> > + <li>abitscope multimedia filter</li> > + <li>readeia608 filter</li> > + <li>threshold filter</li> > + <li>midequalizer filter</li> > + <li>MPEG-7 Video Signature filter</li> > + <li>add internal ebur128 library, remove external libebur128 dependency</li> > + <li>Intel QSV video scaling and deinterlacing filters</li> > + </p> > + <p> > + <li>Sample Dump eXchange demuxer</li> > + <li>MIDI Sample Dump Standard demuxer</li> > + <li>Scenarist Closed Captions demuxer and muxer</li> > + <li>Support MOV with multiple sample description tables</li> > + <li>Pro-MPEG CoP #3-R2 FEC protocol</li> > + <li>Support for spherical videos</li> > + </p> > + <p> > + <li>CrystalHD decoder moved to new decode API</li> > + <li>configure now fails if autodetect-libraries are requested but not found</li> > + </p> > + </ul> > + <p> > + We strongly recommend users, distributors, and system integrators to > + upgrade unless they use current git master. as some developers had concerns about the release in relation to merges prior to it, iam not sure we should recommand that or not. We could also wait with adding such recommandition and for example add it for 3.3.1 when no major issues are reported on release/3.3 either way patch LGTM thx [...]
Hi, On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer <michael@niedermayer.cc > wrote: > On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > > + We strongly recommend users, distributors, and system integrators to > > + upgrade unless they use current git master. > > as some developers had concerns about the release in relation to > merges prior to it, iam not sure we should recommand that or not. > > We could also wait with adding such recommandition and for example > add it for 3.3.1 when no major issues are reported on release/3.3 It's unusual to make a release if we're not sure users should upgrade to it? Ronald
On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer <michael@niedermayer.cc > > wrote: > > > On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > > > + We strongly recommend users, distributors, and system integrators to > > > + upgrade unless they use current git master. > > > > as some developers had concerns about the release in relation to > > merges prior to it, iam not sure we should recommand that or not. > > > > We could also wait with adding such recommandition and for example > > add it for 3.3.1 when no major issues are reported on release/3.3 > > > It's unusual to make a release if we're not sure users should upgrade to it? iam not sure i understand what you are trying to say? but ill try to awnser anyway I dont think its unusual that after a large number of changes or a long time since the last release theres higher uncertanity in the code state. Nor is it unusual that one doesnt suggest everyone to upgrade to a "dot zero" release but waits for .1, for example ubuntu does that AFAIK Iam not sure what the team prefers, how can i be sure without asking? and thats what i did above, i asked [...]
On 4/14/2017 8:32 PM, Michael Niedermayer wrote: > On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer <michael@niedermayer.cc >>> wrote: >> >>> On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: >>>> + We strongly recommend users, distributors, and system integrators to >>>> + upgrade unless they use current git master. >>> >>> as some developers had concerns about the release in relation to >>> merges prior to it, iam not sure we should recommand that or not. >>> >>> We could also wait with adding such recommandition and for example >>> add it for 3.3.1 when no major issues are reported on release/3.3 >> >> >> It's unusual to make a release if we're not sure users should upgrade to it? > > iam not sure i understand what you are trying to say? > but ill try to awnser anyway > > I dont think its unusual that after a large number of changes or a long > time since the last release theres higher uncertanity in the code state. > > Nor is it unusual that one doesnt suggest everyone to upgrade to a > "dot zero" release but waits for .1, for example ubuntu does that AFAIK > > Iam not sure what the team prefers, how can i be sure without asking? > and thats what i did above, i asked IMO, since the "we strongly recommend" line has been a constant in all releases, removing it now will (for those that notice it) rise quite a few red flags and make people come to the conclusion they should probably skip it altogether. If we expect people to use it and hopefully report any issues with it, we shouldn't do something that will scare them away. And really, the tree wasn't any more "unstable" when we branched it for 3.3 than how it had been when we branched previous releases. All new release branches featured merges up to some arbitrary point. It's even been two weeks since the branch was cut, and no outstanding issues were found even in master, so lets try to not start spreading uncertainty.
On Fri, Apr 14, 2017 at 08:48:55PM -0300, James Almer wrote: > On 4/14/2017 8:32 PM, Michael Niedermayer wrote: > > On Fri, Apr 14, 2017 at 04:07:41PM -0400, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Fri, Apr 14, 2017 at 4:24 AM, Michael Niedermayer <michael@niedermayer.cc > >>> wrote: > >> > >>> On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > >>>> + We strongly recommend users, distributors, and system integrators to > >>>> + upgrade unless they use current git master. > >>> > >>> as some developers had concerns about the release in relation to > >>> merges prior to it, iam not sure we should recommand that or not. > >>> > >>> We could also wait with adding such recommandition and for example > >>> add it for 3.3.1 when no major issues are reported on release/3.3 > >> > >> > >> It's unusual to make a release if we're not sure users should upgrade to it? > > > > iam not sure i understand what you are trying to say? > > but ill try to awnser anyway > > > > I dont think its unusual that after a large number of changes or a long > > time since the last release theres higher uncertanity in the code state. > > > > Nor is it unusual that one doesnt suggest everyone to upgrade to a > > "dot zero" release but waits for .1, for example ubuntu does that AFAIK > > > > Iam not sure what the team prefers, how can i be sure without asking? > > and thats what i did above, i asked > > IMO, since the "we strongly recommend" line has been a constant in all > releases, removing it now will (for those that notice it) rise quite a > few red flags and make people come to the conclusion they should > probably skip it altogether. > If we expect people to use it and hopefully report any issues with it, > we shouldn't do something that will scare them away. > > And really, the tree wasn't any more "unstable" when we branched it > for 3.3 than how it had been when we branched previous releases. All > new release branches featured merges up to some arbitrary point. > It's even been two weeks since the branch was cut, and no outstanding > issues were found even in master, so lets try to not start spreading > uncertainty. sure, lets do what people prefer [...]
On Thu, Apr 13, 2017 at 09:00:33PM +0100, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> > --- > src/index | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/src/index b/src/index > index c203676..1b8a037 100644 > --- a/src/index > +++ b/src/index > @@ -37,6 +37,59 @@ > News > </h1> > > + <h3 id="pr3.3">April 13th, 2017, FFmpeg 3.3 "Hilbert"</h3> > + <p> > + <a href="download.html#release_3.3">FFmpeg 3.3 "Hilbert"</a>, a new > + major release, is now available! Some of the highlights: > + </p> > + <ul> > + <p> is this valid html ? it looked funky and so i checked and found: http://stackoverflow.com/questions/2161337/can-we-use-any-other-tag-inside-ul-along-with-li which says no [...]
James Almer wrote: >IMO, since the "we strongly recommend" line has been a constant >in all releases, removing it now will (for those that notice >it) rise quite a few red flags and make people come to the >conclusion they should probably skip it altogether. +1 And as for bug report/fixing there has been invented the k++ possibility in the i.j.k versioning schema... In the real world of audio-visual archives, witch I know best, it is indeed important to be able to tell to the users to keep updated with the last release. (BTW: They are often unable to deal with the HEAD.) The final goal should to be to have FFmpeg used widely, I guess. Best regards, Reto
2017-04-15 1:48 GMT+02:00 James Almer <jamrial@gmail.com>: > And really, the tree wasn't any more "unstable" when we branched it > for 3.3 than how it had been when we branched previous releases. That's not how I remember it. We had a relatively high number of open regressions when 3.2 was released but I don't think we ever had such a high number of open regressions as now (neither at times of releases nor otherwise). > All new release branches featured merges up to some arbitrary > point. It's even been two weeks since the branch was cut, > and no outstanding issues were found even in master Sorry, but I really wonder what this sentence is supposed to mean... Carl Eugen
diff --git a/src/index b/src/index index c203676..1b8a037 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,59 @@ News </h1> + <h3 id="pr3.3">April 13th, 2017, FFmpeg 3.3 "Hilbert"</h3> + <p> + <a href="download.html#release_3.3">FFmpeg 3.3 "Hilbert"</a>, a new + major release, is now available! Some of the highlights: + </p> + <ul> + <p> + <li>Apple Pixlet decoder</li> + <li>NewTek SpeedHQ decoder</li> + <li>QDMC audio decoder</li> + <li>PSD (Photoshop Document) decoder</li> + <li>FM Screen Capture decoder</li> + <li>ScreenPressor decoder</li> + <li>XPM decoder</li> + <li>DNxHR decoder fixes for HQX and high resolution videos</li> + <li>ClearVideo decoder (partial)</li> + <li>16.8 and 24.0 floating point PCM decoder</li> + <li>Intel QSV-accelerated VP8 video decoding</li> + </p> + <p> + <li>native Opus encoder</li> + <li>DNxHR 444 and HQX encoding</li> + <li>Quality improvements for the (M)JPEG encoder</li> + <li>VAAPI-accelerated MPEG-2 and VP8 encoding</li> + </p> + <p> + <li>premultiply video filter</li> + <li>abitscope multimedia filter</li> + <li>readeia608 filter</li> + <li>threshold filter</li> + <li>midequalizer filter</li> + <li>MPEG-7 Video Signature filter</li> + <li>add internal ebur128 library, remove external libebur128 dependency</li> + <li>Intel QSV video scaling and deinterlacing filters</li> + </p> + <p> + <li>Sample Dump eXchange demuxer</li> + <li>MIDI Sample Dump Standard demuxer</li> + <li>Scenarist Closed Captions demuxer and muxer</li> + <li>Support MOV with multiple sample description tables</li> + <li>Pro-MPEG CoP #3-R2 FEC protocol</li> + <li>Support for spherical videos</li> + </p> + <p> + <li>CrystalHD decoder moved to new decode API</li> + <li>configure now fails if autodetect-libraries are requested but not found</li> + </p> + </ul> + <p> + We strongly recommend users, distributors, and system integrators to + upgrade unless they use current git master. + </p> + <h3 id="gsoc2016finalreport">October 30th, 2016, Results: Summer Of Code 2016.</h3> <p> This has been a long time coming but we wanted to give a proper closure to our participation in this run of the program and it takes time. Sometimes it's just to get the final report for each project trimmed down, others, is finalizing whatever was still in progress when the program finished: final patches need to be merged, TODO lists stabilized, future plans agreed; you name it.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com> --- src/index | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)