[FFmpeg-devel] [PATCH] This fixes ISO date formatissue when manifest created by this muxer is not playable in most players. This ensures compatibility with dash standard. Tested on many players (dashj.js, shaka, VLC, etc.)
Aaron Levinson
alevinsn at aracnet.com
Sun Apr 30 21:47:53 EEST 2017
On 4/26/2017 4:27 AM, mfojtak wrote:
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 6232c70..fe1d6c2 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -433,7 +433,7 @@ static void format_date_now(char *buf, int size)
> struct tm *ptm, tmbuf;
> ptm = gmtime_r(&t, &tmbuf);
> if (ptm) {
> - if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%S", ptm))
> + if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%SZ", ptm))
> buf[0] = '\0';
> }
> }
>
This change appears to be correct. I wasn't previously knowledgeable
about the 'Z' suffix, but I looked into it and it is documented in ISO
8601 (https://en.wikipedia.org/wiki/ISO_8601 and also
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15 ).
On a separate note, the actual format is: YYYY-MM-DDTHH:mm:ss.sssZ .
The ".sss" part is missing from this implementation, which represents
milliseconds. According to the specification, ".sss" may be absent, but
maybe it would work with even more players if it were included.
Technically, the specification states that an absent time-zone offset
should be treated as 'Z', which indicates that the code was already
compliant without the 'Z', even if it didn't work with most players.
strftime() doesn't handle milliseconds, but perhaps it ought to populate
milliseconds anyway as follows:
if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%S.000Z", ptm))
Aaron Levinson
More information about the ffmpeg-devel
mailing list