Michael Niedermayer (HE12025-04-15): > or is the goal to avoid the error handling?
Both are desirable. I am sure we have in our API a few functions that take a dictionary but are very fast; is it really worth digging around to convince you that avoiding dynamic allocations is worth it? > also in the specific example > av_codec_open3(ctx, codec, NULL); > will no longer work as NULL is a pointer and AVMap here looks like > it would not be My bad, I forgot &, we obviously do not pass large structures by value. > AVMap should be public but the implementation should not be any more > public than needed. > That way users cannot by mistake mess with internals We are FFmpeg, not GNOME, we are not in the business of going out of our way and making our code less efficient for the sole benefit of preventing API users from shooting themselves in the foot. If you insist, there are ways of hiding most of the internals anyway. But I do not think it is worth it. > and we can > improve the internal implementation without ABI/API breakage The trick I introduced in BPrint allows us to improve on internal implementation without ABI/API breakage. I would not insist on it otherwise. Regards, -- Nicolas George _______________________________________________ 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".
