[FFmpeg-devel] [PATCH] avformat/mxfdec: Do not process zero modified_date timestamp.

[James Almer]

On 12/22/2018 3:44 PM, Michael Niedermayer wrote:
> This causes windows to fail as the timestamp is outside its supported range
> Fixes regression & fate
> 
> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> ---
>  libavformat/mxfdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index f5e3a736e5..6e96107498 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2590,7 +2590,7 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)
>  
>  #define SET_TS_METADATA(pb, name, var, str) do { \
>      var = avio_rb64(pb); \
> -    if ((ret = avpriv_dict_set_timestamp(&s->metadata, name, mxf_timestamp_to_int64(var))) < 0) \
> +    if (var && (ret = avpriv_dict_set_timestamp(&s->metadata, name, mxf_timestamp_to_int64(var))) < 0) \
>          return ret; \
>  } while (0)

This fixes the crash in the demuxer, but what about the muxing behavior?
The mxf files with zero as modified_date timestamp were created by our
muxer, also because gmtime_r() returns NULL in it. Is 0 within the valid
range for it? Can the modified_date tag be skipped if gmtime_r() fails,
or is an obligatory metadata tag in the spec?