Andreas Rheinhardt (12020-08-20): > The MERGE_REF() macro is asymmetric by design: The refs of the second > argument are added to the refs of the first argument and the second > argument is freed. The list of the first argument meanwhile is/ought to > be preserved. When swapping, one therefore has to swap the > non-ref-fields, too. But the MERGE_REF at the end of > ff_merge_channel_layouts() is special. The list will be freed and > replaced by a different list after the macro anyway, so one doesn't need > to preserve the list at all. preserve_fmts exists so that the compiler > can optimize this part of MERGE_REF() away for that invocation of the macro.
Thanks for the explanation. I had not realized that these are precisely the functions that make the lists the same. > It is certainly interesting (e.g. if I am not mistaken, it would mean > that ff_merge_formats/samplerates() can't fail at all any more). I see This is one of the benefits I expect, yes. > two obvious downsides: Traversing the list for freeing is slower (but it > should only be a constant factor) and it increases the size of the > AVFilterLink even after merging. But I don't consider these obstacles to > have much weight. If we become worried about the size of the fields AVFilterLink used only at initialization, we can move them all together in a separate structure that gets freed once the filter is configured. > Speaking of AVFilterLink: All ff_merge_*() as well as ff_can_merge_*() > always use the in- and out-fields of one and the same AVFilterLink. I > wonder whether these function should not just take the AVFilterLink * as > parameter. It would also mean that ff_merge_formats() would have the > same signature as the other functions, which simplifies macros. Now that you mention it, it is probably something that can be done, indeed. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
