[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Michael Niedermayer]

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 <jamrial at gmail.com> wrote:
> >>
> >> On 4/9/2019 9:40 PM, Baptiste Coudurier wrote:
> >>>
> >>>> On Apr 9, 2019, at 5:24 PM, James Almer <jamrial at gmail.com> wrote:
> >>>>
> >>>> On 4/9/2019 8:59 PM, Baptiste Coudurier wrote:
> >>>>>
> >>>>>> On Apr 9, 2019, at 4:51 PM, James Almer <jamrial at 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 <jamrial at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190417/97f26f66/attachment.sig>