[FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
h.leppkes at gmail.com
Sun May 7 18:19:49 EEST 2017
On Sun, May 7, 2017 at 1:47 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> On Sun, May 7, 2017 at 7:34 AM, Marton Balint <cus at 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
>>> 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,
> 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)?
Just for the record, we can't do this with get_buffer, the entire
point of this callback is to get a fully user-controlled buffer into a
Anyone implementing this function needs to be absolutely aware of
alignment and stride requirements, and for this function it is even
documented already (although docs can always be expanded to make
This entire concept currently applies to raw input data only, ie.
input to avfilter, encoders, and maybe even swscale and swresample
(although those may already have checks somewhere)
More information about the ffmpeg-devel