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 <mich...@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?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
