On Sun, May 7, 2017 at 1:34 PM, Marton Balint <c...@passwd.hu> wrote: > > On Sat, 6 May 2017, Nicolas George wrote: > >> Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : >>> >>> As far as I know. No new features can go to release branch. >>> Or maybe I'm wrong. >> >> >> As I said, if this is the only issue, then it is not: just copy-paste >> av_frame_realign() at the two places where it will be needed and make it >> static. >> >> But really, I do not care much what happens in releases. I will fight to >> the end to prevent short-term workarounds to be introduced in the master >> branch when a correct fix is so easy, but for the releases branches, do >> what you want. Only do not expect my help for the ugly way. > > > I suggest the following: > > As the av_frame_realign API is useful on its own without any framework, I > suggest we implement that. > > Once the implementation is complete we can backport it to 3.3 with the > avpriv prefix and without bumping version numbers. > > In the 3.3 branch the regression can be fixed (old behaviour can be > restored) by calling avpriv_frame_align in the frame queue. > > In the master branch, if no consensus is reached, or discussion/work on the > alignment framework stalls, a vote can be made to either > 1) enforce the aligment in the frame queue or > 2) enforce the aligment in parts of the code we know regressed (libmp3, > af_volume) >
Introducing avpriv API is still a bad thing for a release branch - avpriv is ultimately public ABI and having 3.3 and master diverge in ABI right away would be bad. IMHO just add a fix local to avfilter and make it re-align the frame queue to resolve the regression at hand in the release. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel