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

Baptiste Coudurier baptiste.coudurier at gmail.com
Wed Apr 24 21:41:11 EEST 2019

Hi Michael, I hope you are doing well,

> On Apr 16, 2019, at 4:03 PM, Michael Niedermayer <michael at 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 <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/ <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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190424/2be5f5d7/attachment.sig>

More information about the ffmpeg-devel mailing list