On Sun, 28. Feb 04:01, Andreas Rheinhardt wrote:
> The WTV demuxer's oledata_to_iso8601 reads a value via avio_rl64
> and reinterprets it as a double via av_int2double. This does not
> work on big endian systems. So swap it to native endianness before
> av_int2double.
>
> law-and-order-partial.wtv from the FATE-suite exhibited the problem.
>
> Thanks-to: Andriy Gelman <andriy.gel...@gmail.com>
> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com>
> ---
> libavformat/wtvdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> index 7def9d2348..bb84e5dc9f 100644
> --- a/libavformat/wtvdec.c
> +++ b/libavformat/wtvdec.c
> @@ -418,7 +418,7 @@ static int crazytime_to_iso8601(char *buf, int buf_size,
> int64_t value)
> */
> static int oledate_to_iso8601(char *buf, int buf_size, int64_t value)
> {
> - time_t t = (av_int2double(value) - 25569.0) * 86400;
> + time_t t = (av_int2double(av_le2ne64(value)) - 25569.0) * 86400;
> struct tm tmbuf;
> struct tm *tm= gmtime_r(&t, &tmbuf);
> if (!tm)
I don't think that's correct because the output of avio_rl64() is already native
endian.
The result of:
double a = (av_int2double(value) - 25569.0) * 86400;
is consistent on my x86_64 and PPC64.
The failing fate test seems to be because sizeof(time_t) = 4 on the BE PPC64
docker instance, but is 8 on my x86_64.
--
Andriy
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
