Hi Michael, I hope you are doing well, > On Apr 16, 2019, at 4:03 PM, Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > Signed PGP part > On Wed, Apr 10, 2019 at 06:54:53PM -0300, James Almer wrote: >> On 4/10/2019 6:26 PM, Baptiste Coudurier wrote: >>>> On Apr 9, 2019, at 6:27 PM, James Almer <jamr...@gmail.com> wrote: >>>> >>>> On 4/9/2019 9:40 PM, Baptiste Coudurier wrote: >>>>> >>>>>> On Apr 9, 2019, at 5:24 PM, James Almer <jamr...@gmail.com> wrote: >>>>>> >>>>>> On 4/9/2019 8:59 PM, Baptiste Coudurier wrote: >>>>>>> >>>>>>>> On Apr 9, 2019, at 4:51 PM, James Almer <jamr...@gmail.com> wrote: >>>>>>>> >>>>>>>> On 4/9/2019 8:22 PM, Baptiste Coudurier wrote: >>>>>>>>> Hi James, >>>>>>>>> >>>>>>>>>> On Apr 9, 2019, at 4:09 PM, James Almer <jamr...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> […] >>>>>>>>>> >>>>>>>>>> Ok so, the only fields you need from the sps are >>>>>>>>>> constraint_set_flags, >>>>>>>>>> frame_mbs_only_flag, bit_depth_luma, profile_idc, level_idc and sar, >>>>>>>>>> meaning you don't even need to parse the sps until the very end (sar >>>>>>>>>> is >>>>>>>>>> the furthest value, and right at the beginning of vui_parameters). >>>>>>>>>> I'd very much prefer if we can avoid making >>>>>>>>>> ff_h264_decode_seq_parameter_set() avpriv and with it H264ParamSets >>>>>>>>>> part >>>>>>>>>> of the ABI, so i think it's worth copying the required bitstream >>>>>>>>>> parsing >>>>>>>>>> code at least until the beginning of vui_parameters. It was done for >>>>>>>>>> hevc and av1, so it can be done for h264 as well. >>>>>>>>> >>>>>>>>> Since vui parsing is needed, that would be the entire >>>>>>>>> "ff_h264_decode_seq_parameter_set()” function. >>>>>>>> >>>>>>>> If you only need up to sar, then yo don't need to parse the entire VUI. >>>>>>> >>>>>>> It still requires copying the entire >>>>>>> ff_h264_decode_seq_parameter_set(), even though the sub functions are >>>>>>> not needed. >>>>>>> >>>>>>>>> >>>>>>>>> I disagree with the copying. I also disagree with the copying for >>>>>>>>> AVC1 and HEVC btw. >>>>>>>> >>>>>>>> Using avpriv opens a whole can of worms that will be unpredictable in >>>>>>>> the future. Just look at recent commits like >>>>>>>> f4ea930a119298c6110ee4e3d24219a66e27e230 that started storing >>>>>>>> previously >>>>>>>> skipped values. If hevc_pc was made avpriv for isombff/matroska muxing >>>>>>>> purposes and its structs part of the ABI, this wouldn't have been >>>>>>>> possible until a major bump. >>>>>>> >>>>>>> When did the sharing policy between avformat and avcodec (in the sense >>>>>>> avformat using avcodec) change ? >>>>>>> It seems perfectly natural to me to have libavformat require the >>>>>>> libavcodec version that it was compiled with, >>>>>>> and check it at runtime. >>>>>> >>>>>> More than one ffmpeg release will ship with libavcodec/libavformat >>>>>> sharing the same soname. Backwards compatibility is expected, hence the >>>>>> split between major, minor and micro, as you're meant to be able to drop >>>>>> a newer libavcodec library, say for example ffmpeg 4.1's >>>>>> libavcodec.58.so, and it should work with an existing libavformat.so.58 >>>>>> that was linked against ffmpeg 4.0's libavcodec.58.so. >>>>> >>>>> Sorry to repeat the question but when did that change ? >>>> >>>> I don't know if it ever changed to being with. It's been like this for >>>> as long as i remember, and i don't recall inter-library version checks >>>> that would take minor and micro into consideration (which would be >>>> needed to truly tie a given libavformat library with the exact >>>> libavcodec it was linked to) whereas ABI backwards compatibility >>>> considerations for inter-library stuff can be seen all across the >>>> codebase and git history. >>> >>> It definitely changed, probably around the introduction of “avpriv” prefix. >> >> I think that predates my arrival to the project. Someone else will have >> to chime in... > > it possibly changed from "we dont care / we didnt think about it" in the > distant past, iam not sure its very long ago. > But strange interdependancies on minor/micro versions that are outside > the established rules (https://semver.org/ <https://semver.org/>) > can cause surprises and problems to for example packagers for distros. > So i suggest to stay close to what most users of the libs / packagers do > expect and whould causes the least problems and surprise …
Actually I just saw this: WARNING: library configuration mismatch From fftools/cmdutils.c line 1117 from 2010 it seems So we did care about warning about it since we added this code. I still believe we should enforce libavcodec version inside libavformat, but that will be another topic. — Baptiste
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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".
