[FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

James Almer jamrial at gmail.com
Wed Apr 3 16:59:17 EEST 2019


On 4/3/2019 9:25 AM, Baptiste Coudurier wrote:
> Hey Hendrik
> 
>> On Apr 3, 2019, at 11:37 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>>
>> On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
>> <baptiste.coudurier at gmail.com> wrote:
>>>
>>> ---
>>> libavcodec/cbs_h2645.c             | 28 ++++++++++++++--------------
>>> libavcodec/extract_extradata_bsf.c |  4 ++--
>>> libavcodec/h2645_parse.c           |  6 +++---
>>> libavcodec/h2645_parse.h           |  6 +++---
>>> libavcodec/h264_parse.c            |  4 ++--
>>> libavcodec/h264_parser.c           |  4 ++--
>>> libavcodec/h264_ps.c               |  4 ++--
>>> libavcodec/h264_ps.h               |  4 ++--
>>> libavcodec/h264_slice.c            |  2 +-
>>> libavcodec/h264data.c              |  2 +-
>>> libavcodec/h264data.h              |  3 ++-
>>> libavcodec/h264dec.c               | 10 +++++-----
>>> libavcodec/hevc_parse.c            |  2 +-
>>> libavcodec/hevc_parser.c           |  4 ++--
>>> libavcodec/hevcdec.c               |  4 ++--
>>> libavcodec/svq3.c                  |  2 +-
>>> 16 files changed, 45 insertions(+), 44 deletions(-)
>>>
>>
>> We prefer not to expose huge modules like this as avpriv, as it makes
>> it part of the ABI and as such impossible to change without
>> deprecation cycles.
>> Preferably, avpriv should be avoided entirely where possible, as it
>> has many of the same limitations as actual public API, and just adds
>> confusion.
> 
> Understood. What’s the alternative ?

One usual solution is adding an avpriv_ wrapper for the internal
function, like avpriv_ac3_parse_header() is done for
ff_ac3_parse_header(), which prevents internal structs from being part
of the ABI. But ff_h2645_packet_split() and
ff_h264_decode_seq_parameter_set() don't allow for that, seeing
H264ParamSets, H2645Packet, H2645RBSP and H2645NAL are complex and tend
to get changes every now and then. The last time was only a few months ago.

Other than what you're doing in your patch, the only solution i can
think of is duplicating the functionality. It wouldn't be the first, as
you can see in avc.c, hevc.c, av1.c, where bitstream parsing was
implemented in a reduced form exclusively for muxing purposes.

> 
> Thanks!
> 
>> Baptiste
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> 



More information about the ffmpeg-devel mailing list