[FFmpeg-devel] [PATCH] avformat/mxfenc: Never set codec_ul UID to NULL

[Tomas Härdin]

fre 2020-02-28 klockan 05:14 +0100 skrev Andreas Rheinhardt:
> mxf distinguishes codec profiles by different UIDs and therefore needs
> to check that the input is actually compatible with mxf (i.e. if there
> is a defined UID for it). If not, then sometimes the UID would be set to
> NULL and writing the (video) packet would fail. Yet the following audio
> packet would trigger writing the header (which has been postponed because
> the UID is not known at the start) and if the UID is NULL, this can lead
> to segfaults. This commit therefore stops setting the UID to NULL if the
> input is incompatible with mxf (it has initially been set to a generic
> value in mxf_write_header()).
> 
> Fixes #7993.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
> ---
> a) #7993 is actually a segfault even if its description suggests
> otherwise.
> b) My actually preferred way to fix this was to error out if an audio
> packet is encountered and the header has not been written yet, thereby
> ensuring that only a video packet can trigger writing the header and
> said code is only reached when the video is actually compatible with mxf
> (or with this muxer?). Yet I was surprised to find out that the
> FATE-test mxf-d10-user-comments would fail with this, because right now
> writing the header in this test is triggered by an audio packet (the
> video packets aren't written because they are not of the right size) and
> if these aren't written either, there will be zero bytes of output.
> c) It seems that mxf_write_header() doesn't actually write anything and
> could be converted into an init function.
> 
>  libavformat/mxfenc.c | 25 ++++++++++++++-----------
>  1 file changed, 14 insertions(+), 11 deletions(-)

Looks OK. Maybe we should have some av_asserts in the remaining places
where sc->codec_ul is used?

/Tomas