L'octidi 18 floréal, an CCXXV, Marton Balint a écrit : > 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.
You mean do that even before the discussion about the complete fix in master is finished? I can live with that. A small nit: since the avpriv_frame_realign() would be called from only one file, at most two, it would be simpler and cleaner to put it there as a static function than adding yet another function in the avpriv namespace. Also, depending on the time it takes for the discussion to finish (IIRC, only Hendrik had an objection to the principle), it may be more convenient to keep the branch as close as possible to master. > 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) Ronald explained, I will do so again with different words to make the point: My plan is to call av_frame_realign() in libavcodec/encode.c just before the calls to encoder->encode2() and encoder->send_frame() because these are the functions that need alignment. In other words, call it in the last place of the code path that is common to all encoders. For filters, I think the correct place is before the end of ff_inlink_consume_frame() and ff_inlink_consume_samples(). Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
