Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Sun, Apr 02, 2017 at 09:15:00PM +0200, Michael Niedermayer wrote: > On Sat, Apr 01, 2017 at 09:17:00PM +0200, Marton Balint wrote: > > > > On Fri, 31 Mar 2017, James Almer wrote: > > > > >Now, regarding merges, we're like 10 commits away from the massive > > >bitstream reader batch, which is more or less the only thing committed > > >to libav for a whole week. So how about we re-cut from master (should be > > >a matter of merging master into release/3.3, which will be > > >straight-forward as nothing has been cherry-picked) once we have reached > > >that exact point?. > > >Give Google and Kierank a couple days to make sure h264 fuzzing didn't > > >find anything outstanding, and go ahead with tagging the release. > > > > I prefer this as well. > > ok, it seems noone on IRC or ML objected to this so i updated > release/3.3 to master with ver bumps > > i intend to make 3.3 from this branch within a few days > testing, release notes, bugfixes very welcome > > ive done some quick testing and it seems to be working > > thanks everyone release made ill make 3.3.1 in a week or 2, backported bugfixes welcome ! also anyone wants to write a news entry ? thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
2017-04-02 21:15 GMT+02:00 Michael Niedermayer : > i intend to make 3.3 from this branch within a few days Please wait for a resolution for the decklink license issue: Either the library is free (as explained here) or non-free as was claimed on the Debian bugtracker. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Sat, Apr 01, 2017 at 09:17:00PM +0200, Marton Balint wrote: > > On Fri, 31 Mar 2017, James Almer wrote: > > >Now, regarding merges, we're like 10 commits away from the massive > >bitstream reader batch, which is more or less the only thing committed > >to libav for a whole week. So how about we re-cut from master (should be > >a matter of merging master into release/3.3, which will be > >straight-forward as nothing has been cherry-picked) once we have reached > >that exact point?. > >Give Google and Kierank a couple days to make sure h264 fuzzing didn't > >find anything outstanding, and go ahead with tagging the release. > > I prefer this as well. ok, it seems noone on IRC or ML objected to this so i updated release/3.3 to master with ver bumps i intend to make 3.3 from this branch within a few days testing, release notes, bugfixes very welcome ive done some quick testing and it seems to be working thanks everyone [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Fri, 31 Mar 2017, James Almer wrote: Now, regarding merges, we're like 10 commits away from the massive bitstream reader batch, which is more or less the only thing committed to libav for a whole week. So how about we re-cut from master (should be a matter of merging master into release/3.3, which will be straight-forward as nothing has been cherry-picked) once we have reached that exact point?. Give Google and Kierank a couple days to make sure h264 fuzzing didn't find anything outstanding, and go ahead with tagging the release. I prefer this as well. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Fri, Mar 31, 2017 at 08:04:46PM -0300, James Almer wrote: > On 3/31/2017 6:42 PM, James Almer wrote: > > On 3/31/2017 3:19 PM, Michael Niedermayer wrote: > >> On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: > >>> On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: > On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > > Hi all > > > > are there any issues/tickets that block making 3.3 ? > > > > What about the spherical API size_t / uint32_t issue ? > > we can change it before the release but not after it > > Ive finally branched release/3.3 off > feel free to backport anything > we also need release notes and all that stuff > > once we all agree ill make 3.3 from it > >>> > >>> wm4 and ubitux stated on irc that now is a bad time to release due to > >>> the many recent merges > >>> > >>> so what shall we do ? > >>> should we release now (as in a few days) anyway ? > >>> > >>> should we wait till the merge rate slows down ? (no idea when that will > >>> be or in what condition the tree will then be) > >>> > >> > >>> should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 > >>> that is 3 weeks ago with backports ? > >> > >> heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported > >> till master of today ommiting merges, anything changing version (cant be > >> backported due to conflicting version numbers) > > Right, forgot the thing about version bumps. > > I guess it's always possible to revert the commits that bumped library > version in release/3.3 after recutting it at the point i mentioned below. > Afaik the only one so far (outside of the post release bump) is one that > added two functions to spherical.h, so it should be harmless. we can add a new release bump pair if we do the release in a week If people want to cut the release in a week instead of now or 3 weeks ago [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On 3/31/2017 6:42 PM, James Almer wrote: > On 3/31/2017 3:19 PM, Michael Niedermayer wrote: >> On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: >>> On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > Hi all > > are there any issues/tickets that block making 3.3 ? > > What about the spherical API size_t / uint32_t issue ? > we can change it before the release but not after it Ive finally branched release/3.3 off feel free to backport anything we also need release notes and all that stuff once we all agree ill make 3.3 from it >>> >>> wm4 and ubitux stated on irc that now is a bad time to release due to >>> the many recent merges >>> >>> so what shall we do ? >>> should we release now (as in a few days) anyway ? >>> >>> should we wait till the merge rate slows down ? (no idea when that will >>> be or in what condition the tree will then be) >>> >> >>> should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 >>> that is 3 weeks ago with backports ? >> >> heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported >> till master of today ommiting merges, anything changing version (cant be >> backported due to conflicting version numbers) Right, forgot the thing about version bumps. I guess it's always possible to revert the commits that bumped library version in release/3.3 after recutting it at the point i mentioned below. Afaik the only one so far (outside of the post release bump) is one that added two functions to spherical.h, so it should be harmless. >> , most hwaccel stuff >> (as likely related to merges), most cherry picks from libav and >> anything that didnt apply / depended on ommited commits >> https://github.com/michaelni/FFmpeg/tree/alternative-3.3 >> >> fate of course passes >> >> do people prefer this over what is in release/3.3 ? > > IMO, this is not ideal. It will make the release/3.3 branch wildly > different than master (and libav master) at the alleged point where it > branched out from it. > > Now, regarding merges, we're like 10 commits away from the massive > bitstream reader batch, which is more or less the only thing committed > to libav for a whole week. So how about we re-cut from master (should be > a matter of merging master into release/3.3, which will be > straight-forward as nothing has been cherry-picked) once we have reached > that exact point?. > Give Google and Kierank a couple days to make sure h264 fuzzing didn't > find anything outstanding, and go ahead with tagging the release. > > However, if the merges really put the tree in an unstable state, as it's > apparently been argued, then i guess what you suggested above is better > than waiting another month to release 3.3. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On 3/31/2017 3:19 PM, Michael Niedermayer wrote: > On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: >> On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: >>> On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: Hi all are there any issues/tickets that block making 3.3 ? What about the spherical API size_t / uint32_t issue ? we can change it before the release but not after it >>> >>> Ive finally branched release/3.3 off >>> feel free to backport anything >>> we also need release notes and all that stuff >>> >>> once we all agree ill make 3.3 from it >> >> wm4 and ubitux stated on irc that now is a bad time to release due to >> the many recent merges >> >> so what shall we do ? >> should we release now (as in a few days) anyway ? >> >> should we wait till the merge rate slows down ? (no idea when that will >> be or in what condition the tree will then be) >> > >> should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 >> that is 3 weeks ago with backports ? > > heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported > till master of today ommiting merges, anything changing version (cant be > backported due to conflicting version numbers), most hwaccel stuff > (as likely related to merges), most cherry picks from libav and > anything that didnt apply / depended on ommited commits > https://github.com/michaelni/FFmpeg/tree/alternative-3.3 > > fate of course passes > > do people prefer this over what is in release/3.3 ? IMO, this is not ideal. It will make the release/3.3 branch wildly different than master (and libav master) at the alleged point where it branched out from it. Now, regarding merges, we're like 10 commits away from the massive bitstream reader batch, which is more or less the only thing committed to libav for a whole week. So how about we re-cut from master (should be a matter of merging master into release/3.3, which will be straight-forward as nothing has been cherry-picked) once we have reached that exact point?. Give Google and Kierank a couple days to make sure h264 fuzzing didn't find anything outstanding, and go ahead with tagging the release. However, if the merges really put the tree in an unstable state, as it's apparently been argued, then i guess what you suggested above is better than waiting another month to release 3.3. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: > On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: > > On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > > > Hi all > > > > > > are there any issues/tickets that block making 3.3 ? > > > > > > What about the spherical API size_t / uint32_t issue ? > > > we can change it before the release but not after it > > > > Ive finally branched release/3.3 off > > feel free to backport anything > > we also need release notes and all that stuff > > > > once we all agree ill make 3.3 from it > > wm4 and ubitux stated on irc that now is a bad time to release due to > the many recent merges > > so what shall we do ? > should we release now (as in a few days) anyway ? > > should we wait till the merge rate slows down ? (no idea when that will > be or in what condition the tree will then be) > > should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 > that is 3 weeks ago with backports ? heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported till master of today ommiting merges, anything changing version (cant be backported due to conflicting version numbers), most hwaccel stuff (as likely related to merges), most cherry picks from libav and anything that didnt apply / depended on ommited commits https://github.com/michaelni/FFmpeg/tree/alternative-3.3 fate of course passes do people prefer this over what is in release/3.3 ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
> > also what exactly is broken with teh current tree that will be better > in a month and was better 3 weeks ago ? > Is that known ? or is it just "there were lots of chnages, things may > be broken" ? > > all just some randdom comments so myself and also others better > understand what the issues are > Whilst I appreciate the work that has gone into fixing h264 crashes, I am always uncomfortable about the state of h264 decoding after a libav merge. It has caused me numerous problems in the past. I am currently fuzzing sliced threads decoding which afaik nobody does. But I am not on the scale of google. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
Steven Liu wrote: >> should we make a 3.3 release from >>0bab78f7e729a76ea7a8cbec7f1de033c52494e8 >> that is 3 weeks ago with backports ? >> >I think this point maybe better, and stable than another >two. +1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Fri, Mar 31, 2017 at 03:19:01PM +0200, Clément Bœsch wrote: > On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: > > On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: > > > On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > > > > Hi all > > > > > > > > are there any issues/tickets that block making 3.3 ? > > > > > > > > What about the spherical API size_t / uint32_t issue ? > > > > we can change it before the release but not after it > > > > > > Ive finally branched release/3.3 off > > > feel free to backport anything > > > we also need release notes and all that stuff > > > > > > once we all agree ill make 3.3 from it > > > > wm4 and ubitux stated on irc that now is a bad time to release due to > > the many recent merges > > > > Clarification on the situation: for a few days now, a few developers > including myself are working on catching up with the Libav merges. We were > at more than 1000+ commits a few weeks (days?) ago and we're at about 650 > now (basically Libav in early November 2016). > > It's hard to predict how long it will take to reach the 1:1 state again. > In the best case I'd say 3 weeks to 1 month, assuming no blocker and still > a large number of noops. > > I also have much less time since I'm not in holidays anymore (yeah, I took > a few days of holidays to help with that). > > That said, reaching a 1:1 state again will mean a more stable state (as in > "less changing") of the repository because the merges will be less > abundant, and thus more likely a time to make a release. Iam not sure if we will be in a better state for a release after merging 650 commits from libav which diverged for many years. If that happens within a month, how long will it take to stabilize after that? I mean if we decide that 1 week of stabilization of release/3.3 after 300 merges is not good enough (as in we cant release this now in a few days), 650 more quickly added on top doesnt seem to improve the situation. Also waiting now for 650 more merges then weeks for stabilization puts things more into FFmpeg 3.4 time, as in we are not waiting with 3.3 but more accuratly we skip a release. And if we do, will there be no reason to skip 3.4 in 2-3 months ? IMO release early, release often also what exactly is broken with teh current tree that will be better in a month and was better 3 weeks ago ? Is that known ? or is it just "there were lots of chnages, things may be broken" ? all just some randdom comments so myself and also others better understand what the issues are [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote: > On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: > > On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > > > Hi all > > > > > > are there any issues/tickets that block making 3.3 ? > > > > > > What about the spherical API size_t / uint32_t issue ? > > > we can change it before the release but not after it > > > > Ive finally branched release/3.3 off > > feel free to backport anything > > we also need release notes and all that stuff > > > > once we all agree ill make 3.3 from it > > wm4 and ubitux stated on irc that now is a bad time to release due to > the many recent merges > Clarification on the situation: for a few days now, a few developers including myself are working on catching up with the Libav merges. We were at more than 1000+ commits a few weeks (days?) ago and we're at about 650 now (basically Libav in early November 2016). It's hard to predict how long it will take to reach the 1:1 state again. In the best case I'd say 3 weeks to 1 month, assuming no blocker and still a large number of noops. I also have much less time since I'm not in holidays anymore (yeah, I took a few days of holidays to help with that). That said, reaching a 1:1 state again will mean a more stable state (as in "less changing") of the repository because the merges will be less abundant, and thus more likely a time to make a release. > so what shall we do ? To quote myself on IRC so my position is know here: 14:55 <@ubitux> michaelni: i don't know what to do. no release is fine with me. doing a release of the current state is not a good idea. doing a release of a previous state should be ok but i don't see the point. [...] That said, if you wish to help with doing a clean release, help is welcome on the merges. That includes doing cherry-picks in advance so they can be noop'ed when reached in the timeline, or help trimming the bottom of doc/libav-merge.txt. Thanks, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
2017-03-31 21:07 GMT+08:00 Michael Niedermayer : > On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: > > On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > > > Hi all > > > > > > are there any issues/tickets that block making 3.3 ? > > > > > > What about the spherical API size_t / uint32_t issue ? > > > we can change it before the release but not after it > > > > Ive finally branched release/3.3 off > > feel free to backport anything > > we also need release notes and all that stuff > > > > once we all agree ill make 3.3 from it > > wm4 and ubitux stated on irc that now is a bad time to release due to > the many recent merges > > so what shall we do ? > should we release now (as in a few days) anyway ? > > should we wait till the merge rate slows down ? (no idea when that will > be or in what condition the tree will then be) > > should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 > that is 3 weeks ago with backports ? > I think this point maybe better, and stable than another two. > > I think these where the 3 suggestions from IRC more or less > > Theres also a major bump ahead and IMO we should release before that > making all the new stuff available with the current ABI > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > You can kill me, but you cannot change the truth. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] FFmpeg 3.3
On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote: > On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote: > > Hi all > > > > are there any issues/tickets that block making 3.3 ? > > > > What about the spherical API size_t / uint32_t issue ? > > we can change it before the release but not after it > > Ive finally branched release/3.3 off > feel free to backport anything > we also need release notes and all that stuff > > once we all agree ill make 3.3 from it wm4 and ubitux stated on irc that now is a bad time to release due to the many recent merges so what shall we do ? should we release now (as in a few days) anyway ? should we wait till the merge rate slows down ? (no idea when that will be or in what condition the tree will then be) should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 that is 3 weeks ago with backports ? I think these where the 3 suggestions from IRC more or less Theres also a major bump ahead and IMO we should release before that making all the new stuff available with the current ABI [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
