[FFmpeg-devel] [PATCH] Support for zulu timezone format for PDT in HLS playlists

[Ole Andre Birkedal]

Completely agree, just worried that it might cause incompatibility issues from some users down the line.

On the other hand, Unified Streaming is always using UTC timestamps on their PDT: https://docs.unified-streaming.com/documentation/live/recommended-settings.html#timecode

This would make the whole thing a lot easier and could remove most of the code bloat in ff_hls_write_file_entry that's dealing with timestamps.

Also thinking of just sending all HLSContext::flags into the ff_hls_write_file_entry function and masking out the needed bits inside. This function takes too many arguments in my opinion, but that's for another day :)

I'm preparing a couple of patches that I'll share in this thread and we can take it from there.

Ole Andre Birkedal

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 24, 2019 5:41 PM, Marton Balint <cus at passwd.hu> wrote:

>
>
> On Thu, 24 Oct 2019, Ole Andre Birkedal wrote:
>
> > This is something that Akamai requires for their MSL4 product when
> > ingesting HLS and using it to generate clips on their CDN. It's also
> > something required by one of our customers, but we don't know the exact
> > reason of why they require this. I'll update the patch with a better
> > commit message explaining these things.
> > Having a setting for choosing to use UTC and then by default presenting
> > it in the Z format is a good idea! Always using UTC should not be on by
> > default though, even if I think that's the best way to present
> > timestamps, there could be users who depend on it being non-UTC.
> > So to recap
> >
> > 1.  By default USE Zulu time on +0000 UTC timestamps in PDT, but can be configured OFF.
> > 2.  Add an option for using UTC timezone in PDT, by default OFF.
>
> If the incompatibility you experience can be fixed by using option 2, then
> I'd rather not add a flag for option 1... I don't have a strong preference
> though.
>
> Regards,
> Marton
>
> > Just realising that this also bleeds into the CMAF muxer in DASH, will investigate what can be done to support similar settings there.
> > Thanks for the feedback,
> > Ole Andre Birkedal
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Wednesday, October 23, 2019 2:50 PM, Marton Balint cus at passwd.hu wrote:
> >
> > > On Wed, 23 Oct 2019, Marton Balint wrote:
> > >
> > > > On Wed, 23 Oct 2019, Ole Andre Birkedal wrote:
> > > >
> > > > > Thanks for the feedback, attached new complete patch with code changes +
> > > > > added documentation for it
> > > >
> > > > Please also explain why this might be required in the docs. In the commit
> > > > message please name the specific vendor/device which is not parsing zero
> > > > offset correctly.
> > > > I wonder if it would make sense to set this flag by default (doing that
> > > > can be a separate patch) if it improves compatiblity.
> > >
> > > One more idea is that maybe we should introduce a flag which always puts
> > > the timestamp in UTC instead? Otherwise your approach only works if the
> > > local time is UTC, no?
> > > Thanks,
> > > Marton
> > >
> > > > Thanks,
> > > > Marton
> > > >
> > > > > Ole
> > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > On Wednesday, October 23, 2019 4:32 AM, Steven Liu lq at chinaffmpeg.org
> > > > > wrote:
> > > > >
> > > > > > > 在 2019年10月22日，18:37，Ole Andre Birkedal birkedal at extab.net 写道：
> > > > > > > Some HLS players prefer UTC+0 timestamps in PROGRAM-DATE-TIME to end in a
> > > > > > > Z instead of +0000, this patch adds a hlsflag to enable that feature.
> > > > >
> > > > > > > Example command:
> > > > > > > ffmpeg -i input.mp4 -c copy -hls_flags +program_date_time+zulu_timezone
> > > > > > > output.m3u8
> > > > >
> > > > > > > Example PDT output:
> > > > > > > #EXT-X-PROGRAM-DATE-TIME:2019-10-22T10:27:54.000Z
> > > > > > > Ole Andre
> > > > > > > Birkedal<zulu_timezone.patch>_______________________________________________
> > > > >
> > > > > > Document doc/muxer.texi please.
> > > > > >
> > > > > > > ffmpeg-devel mailing list
> > > > > > > ffmpeg-devel at ffmpeg.org
> > > > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > > > > To unsubscribe, visit link above, or email
> > > > > > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > > > > >
> > > > > > Thanks
> > > > > > Steven
> > > > > > ffmpeg-devel mailing list
> > > > > > ffmpeg-devel at ffmpeg.org
> > > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > > > To unsubscribe, visit link above, or email
> > > > > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > > >
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel at ffmpeg.org
> > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > To unsubscribe, visit link above, or email
> > > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > >
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel at ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> >
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".