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

[Baptiste Coudurier]

Hi James, I hope you are doing well


> On Apr 3, 2019, at 6:59 AM, James Almer <jamrial at gmail.com> wrote:
> 
> 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.

All right, I changed the code to avoid using ff_h2645_packet_split() and I found “nal_unit_extract_rbsp” in libavformat :)
I don’t think duplicating ff_h264_decode_seq_parameter would be good though so I still changed the prefix to avpriv.

Let me know if that works.

Thanks!

—
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: Message signed with OpenPGP
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190409/7a578415/attachment.sig>