On Sun, May 7, 2017 at 6: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.
Inside libavfilter, we need something like ff_inlink_frame_align because of ff_get_buffer problem. This is fortunate because we don't need to call av_frame_realign at all. > > 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) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
