On Sat, Dec 22, 2018 at 04:23:54PM -0300, James Almer wrote:
> On 12/22/2018 4:00 PM, Marton Balint wrote:
> >
> >
> > 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
>
> Ok, thanks. Patch LGTM as well then.will apply thanks to everyone [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
