> 在 2019年11月3日，20:14，Marton Balint 写道：
>
>
>
> On Fri, 25 Oct 2019, Ole Andre Birkedal wrote:
>
>> I think this is the best solution, with just one new flag +utc_pdt that will
>> force timestamps of PDT to be in UTC with the format -MM-DDThh:mm:ssZ.
>> Too many flags will be confusing,
> 在 2019年11月3日，20:14，Marton Balint 写道：
>
>
>
> On Fri, 25 Oct 2019, Ole Andre Birkedal wrote:
>
>> I think this is the best solution, with just one new flag +utc_pdt that will
>> force timestamps of PDT to be in UTC with the format -MM-DDThh:mm:ssZ.
>> Too many flags will be confusing,
On Fri, 25 Oct 2019, Ole Andre Birkedal wrote:
I think this is the best solution, with just one new flag +utc_pdt that
will force timestamps of PDT to be in UTC with the format
-MM-DDThh:mm:ssZ. Too many flags will be confusing, and the "zulu"
name can be a bit confusing so I removed any
I think this is the best solution, with just one new flag +utc_pdt that will
force timestamps of PDT to be in UTC with the format -MM-DDThh:mm:ssZ. Too
many flags will be confusing, and the "zulu" name can be a bit confusing so I
removed any mention of that.
Ole Andre Birkedal
‐‐‐ Orig
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 th
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
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 expl
On Wed, Oct 23, 2019 at 14:44:38 +0200, Marton Balint wrote:
> 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 (do
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
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 z
Thanks for the feedback, attached new complete patch with code changes + added
documentation for it
Ole
‐‐‐ Original Message ‐‐‐
On Wednesday, October 23, 2019 4:32 AM, Steven Liu wrote:
>
>
> > 在 2019年10月22日，18:37，Ole Andre Birkedal birke...@extab.net 写道：
> > Some HLS players prefer
> 在 2019年10月22日，18:37，Ole Andre Birkedal 写道：
>
> Some HLS players prefer UTC+0 timestamps in PROGRAM-DATE-TIME to end in a Z
> instead of +, this patch adds a hlsflag to enable that feature.
>
> Example command:
> ffmpeg -i input.mp4 -c copy -hls_flags +program_date_time+zulu_timezone
>
Some HLS players prefer UTC+0 timestamps in PROGRAM-DATE-TIME to end in a Z
instead of +, 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-
13 matches
Mail list logo
