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 <c...@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 c...@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 > > > > > l...@chinaffmpeg.org > > > > > wrote: > > > > > > > > > > > > 在 2019年10月22日，18:37，Ole Andre Birkedal birke...@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@ffmpeg.org > > > > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > To unsubscribe, visit link above, or email > > > > > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > > > > > > > > > Thanks > > > > > > Steven > > > > > > 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". > > > > > > > > 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". > > > > > > 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". > > > > 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". > > 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". _______________________________________________ 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".
