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/) 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 ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
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".
