On Sat, 22 Dec 2018, James Almer wrote:
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?
According to spec, 0 means unknown, and yes, it is required. Regards, Marton _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
