Hi, On Sun, May 7, 2017 at 7:34 AM, 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) My understanding from what Nicolas said is that the goal is to have higher-level code (utils.c-level, e.g. the callers of filter() or encode_frame() or get_buffer() inside decode_frame()) call this for every input frame going back to a caller with higher alignment requirements than the input frame (possibly with a one-time warning)? Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
