Adding support for generation of the EXT_X_PROGRAM_DATE_TIME tag for … #814

Ykidia · 2020-08-06T12:50:33Z

…HLS playlists, with fixed UTC timezone.
Command-line switch to go on with this tag: --hls_ext_x_program_date_time.
Probably closes issue [#365 ].

…HLS playlists, with fixed UTC timezone

googlebot · 2020-08-06T12:50:42Z

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

What to do if you already signed the CLA

Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

google-cla · 2020-08-06T12:50:42Z

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

What to do if you already signed the CLA

Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

Ykidia · 2020-08-06T13:05:35Z

@googlebot I signed it!

googlebot · 2020-08-06T13:05:38Z

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

google-cla · 2020-08-06T13:05:38Z

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

kqyang · 2020-08-07T03:43:24Z

CONTRIBUTORS

@@ -45,3 +45,4 @@ Sergio Ammirata <sergio@ammirata.net>
 Thomas Inskip <tinskip@google.com>
 Tim Lansen <tim.lansen@gmail.com>
 Weiguo Shao <weiguo.shao@dolby.com>
+Artem Bogdanov <ykidia@gmail.com>


Can you move it after line 27, i.e. in alphabetical order?

kqyang · 2020-08-07T04:13:08Z

packager/hls/base/media_playlist.cc

@@ -345,6 +368,8 @@ MediaPlaylist::MediaPlaylist(const HlsParams& hls_params,
      name_(name),
      group_id_(group_id),
      media_sequence_number_(hls_params_.media_sequence_number) {
+        start_timestamp = base::Time::Now().ToDoubleT();


It should be generated in the master playlist and passed to the media playlist otherwise there will be inconsistencies among the the media playlists.

Master playlist doesn't create any media playlists, only manipulates them in list(s) and, finally, writes all to file.
Wherein media playlist can be used without master playlist and, therefore, must generate the timestamp inside itself.
Thus, if we want to generate timestamps in master playlist, then we should provide some offset for every media playlist and for all their segments, when master playlist writing to a file. It looks like a dirty hack for me.
Simple hls notifier, on the contrary, creates media playlists and master playlist and thus, I think, can be used for the timestamp generation.
is it correct?

I don't think that is correct. Let me clarify what I mean.

Per HLS specification:

o If any Media Playlist in a Master Playlist contains an EXT-X-
PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
mappings of date and time to media timestamps.

The date and time must be consistent for all media playlists in the master playlist.

However, in your implementation, the |start_timestamp| is re-calculated for every media playlist. They will not be consistent, as different media playlists are created at different time. Although the difference may be small in most cases, likely negligible in some cases, but it will be significant sometimes.

To ensure a consistent date time mapping, there should only be one source of date time mapping. The best approach is to have a single mapping of media timestamp to absolute date/time, which is then propagate to all media playlists. One way to achieve that is to use master playlist to coordinate the mapping. Of course, there are other ways to do it.

Yes, specification says that "the date and time must be consistent for all media playlists in the master playlist". And the current solution does not contradict this. Specification does not say that "the date and time must be consistent ACROSS all media playlists in the master playlist". But even so: for example, one stream came (started) immediately, another after 678 ms, the third after 5 s, the fourth after 1.5 s, etc; how to make their timestamps consistent with each other if the streams doesn't reference each other in any way? Do you want to make their start timestamps are the same? Then content will be corrupted, and that's not correct. But if not (let's leave individual start timestamps) - every media playlist initializes its start timestamps upon creating, this happens immediately when the corresponding stream starts.
On the other hand, we're getting current system date and time to initialize start timestamps. This is a really single source of date and time mapping.
Please explain if I misunderstood.

It seems that the main problem is that you disagree that the date/time to media timestamp mapping has to be consistent across ALL media playlists.

If any Media Playlist in a Master Playlist contains an EXT-X-
PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
mappings of date and time to media timestamps.

It mentions clearly that "all media playlists must ... with consistent mappings of date and time to media timestamps".

Do you still have a different interpretation of the statement?

Yes.
You said "across ALL". But specification NOT.
I asked you "please explain if I misunderstood" - I meant "describe how you imagine the result", but not to simply repeat your previous post.
And did you really read my explanations? Where the mistake?
Anyway, how should what you want look like? Should all streams (media playlists) have the same start timestamps regardless of the arrival time? I'm really trying to understand.

kqyang · 2020-08-07T04:15:08Z

packager/hls/base/media_playlist.cc

+    AddSegmentInfoEntry(file_name, start_time, duration, start_byte_offset, size,
+                        start_timestamp);


Should we insert it for first segment and for the segments after ext-x-discontinuity only?

We CAN insert it everywhere only once or more but if we did it then we MUST insert it after all ext-x-discontinuity. So, we CAN simply insert it for all segments, as far as I understand RFC 8216.

Sure. I think it will be simpler if we just consider it for every ext-x-discontinuity. I am fine with your approach too but you'll need to take care of the i-frame playlist too. See the comment above.

kqyang · 2020-08-07T04:16:09Z

packager/hls/base/media_playlist.cc

@@ -423,13 +448,15 @@ void MediaPlaylist::AddSegment(const std::string& file_name,
                                         : std::next(iter)->timestamp;
      AddSegmentInfoEntry(file_name, iter->timestamp,
                          next_timestamp - iter->timestamp,
-                          iter->start_byte_offset, iter->size);
+                          iter->start_byte_offset, iter->size, start_timestamp);


start_timestamp should be incremented by "next_timestamp - iter->timestamp".

Also see the comment below

kqyang · 2020-08-07T04:17:19Z

packager/hls/base/media_playlist.h

@@ -268,6 +273,8 @@ class MediaPlaylist {
  bool target_duration_set_ = false;
  uint32_t target_duration_ = 0;

+  double start_timestamp = 0;


Ends with "_" to be consistent. Can you also add a comment explaining what it is?

kqyang · 2020-08-07T04:22:02Z

packager/hls/base/media_playlist.cc

+DEFINE_bool(hls_ext_x_program_date_time,
+            false,
+            "hls print EXT-X-PROGRAM-DATE-TIME tag");


Can you define it in https://github.com/google/shaka-packager/blob/master/packager/app/hls_flags.cc instead?

And then add a bool in HlsParams?

https://github.com/google/shaka-packager/blob/master/packager/hls/public/hls_params.h

kqyang · 2020-08-07T04:44:39Z

packager/hls/base/media_playlist_unittest.cc

@@ -299,6 +356,41 @@ TEST_F(MediaPlaylistMultiSegmentTest, SetTargetDuration) {
  ASSERT_FILE_STREQ(kMemoryFilePath, kExpectedOutput);
 }

+TEST_F(MediaPlaylistMultiSegmentTest, WriteToFileWithTagExtXProgramDateTime) {


I think you can remove these new tests except the first one as they don't add more test coverage.

I suggest also not to remove the last test because it adds case when the time stamp changes across key frames before adding segment.

…rams. Some other minor changes.

kqyang · 2020-08-15T22:26:05Z

packager/hls/base/media_playlist.cc

-DEFINE_bool(hls_ext_x_program_date_time,
-            false,
-            "hls print EXT-X-PROGRAM-DATE-TIME tag");
+#include "packager/app/hls_flags.h"


Move it before line 21, i.e. put it in alphabetical order

kqyang · 2020-08-15T22:35:42Z

packager/hls/base/media_playlist.cc

-                   uint64_t previous_segment_end_offset);
+                   uint64_t previous_segment_end_offset,
+                   bool use_program_date_time,
+                   double start_timestamp);


Can you rename |start_timestamp| to |program_date_time| to avoid confusion as we already have a start_time in this class?

kqyang · 2020-08-15T22:46:36Z

packager/hls/base/media_playlist.cc

@@ -345,6 +368,8 @@ MediaPlaylist::MediaPlaylist(const HlsParams& hls_params,
      name_(name),
      group_id_(group_id),
      media_sequence_number_(hls_params_.media_sequence_number) {
+        start_timestamp = base::Time::Now().ToDoubleT();


It seems that the main problem is that you disagree that the date/time to media timestamp mapping has to be consistent across ALL media playlists.

If any Media Playlist in a Master Playlist contains an EXT-X-
PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
mappings of date and time to media timestamps.

It mentions clearly that "all media playlists must ... with consistent mappings of date and time to media timestamps".

Do you still have a different interpretation of the statement?

Ykidia · 2020-08-26T07:00:45Z

@kqyang, please, let's continue with this PR. Tell me what is stopping it? Are there some political reasons? If the problem is only in our different interpretation of the specification, then I can offer two options:

You describe to me your idea of how we can implement what you want (i.e., according to your interpretation of the specification).
You merge this PR, and then we are waiting for the appearance of any related issue(s) and descriptions of how this can be solved, incl. it will be possible to discuss with others their vision of the specification and implementation; the absence of opened issue(s) for some time will indirectly indicate that the specification may have been interpreted correctly. At the same time, presence of opened issue(s) will help us - and me, in particular - to understand how to do everything correctly.
What do you think about it?

kqyang · 2020-08-27T04:36:02Z

@Ykidia I want to make sure that we are doing the right thing. Per my understanding, what you did in this PR violates HLS specification. I could be wrong, but I don't see your argument and reply on #814 (comment).

If you have a different interpretation of this clause, I want to understand how you interpret it.

If any Media Playlist in a Master Playlist contains an EXT-X-
PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
mappings of date and time to media timestamps.

Let us have a consensus on the spec before moving forward. We can worry about how that can be implemented later.

Ykidia · 2020-08-31T18:46:20Z

Take a look at a real example of related master and media playlists:

master.m3u8

#EXTM3U

#EXT-X-MEDIA:TYPE=AUDIO,URI="stream_7.m3u8",GROUP-ID="default-audio-group",LANGUAGE="ru",NAME="stream_7",DEFAULT=YES,AUTOSELECT=YES,CHANNELS="2"

#EXT-X-STREAM-INF:BANDWIDTH=5600000,AVERAGE-BANDWIDTH=5713160,CODECS="avc1.640029,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_0.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=350000,AVERAGE-BANDWIDTH=460204,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_1.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=650000,AVERAGE-BANDWIDTH=759214,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_2.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=950000,AVERAGE-BANDWIDTH=1058236,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_3.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1250000,AVERAGE-BANDWIDTH=1318306,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_4.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2400000,AVERAGE-BANDWIDTH=2488413,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_5.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3800000,AVERAGE-BANDWIDTH=3928568,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=1280x720,FRAME-RATE=25.000,AUDIO="default-audio-group"
stream_6.m3u8

stream_0.m3u8

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:209991
#EXT-X-DISCONTINUITY-SEQUENCE:1
#EXT-X-MAP:URI="1080_init.m4v"
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:11.077+000
1080_98998116224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:16.077+000
1080_98998566224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:21.077+000
1080_98999016224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:26.077+000
1080_98999466224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:31.077+000
1080_98999916224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:36.077+000
1080_99000366224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:41.077+000
1080_99000816224.m4v

stream_1.m3u8

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:209992
#EXT-X-DISCONTINUITY-SEQUENCE:1
#EXT-X-MAP:URI="360_350k_init.m4v"
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:16.087+000
360_350k_98998566224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:21.087+000
360_350k_98999016224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:26.087+000
360_350k_98999466224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:31.087+000
360_350k_98999916224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:36.087+000
360_350k_99000366224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:41.087+000
360_350k_99000816224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:46.087+000
360_350k_99001266224.m4v

stream_2.m3u8

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:209992
#EXT-X-DISCONTINUITY-SEQUENCE:1
#EXT-X-MAP:URI="360_650k_init.m4v"
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:16.096+000
360_650k_98998566224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:21.096+000
360_650k_98999016224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:26.096+000
360_650k_98999466224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:31.096+000
360_650k_98999916224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:36.096+000
360_650k_99000366224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:41.096+000
360_650k_99000816224.m4v
#EXTINF:5.000,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:46.096+000
360_650k_99001266224.m4v

stream_3.m3u8

<...>

<...>

stream_7.m3u8

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:209998
#EXT-X-DISCONTINUITY-SEQUENCE:1
#EXT-X-MAP:URI="a1_init.m4a"
#EXTINF:4.992,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:36.264+000
a1_99000901664.m4a
#EXTINF:4.992,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:41.256+000
a1_99001350944.m4a
#EXTINF:5.013,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:46.248+000
a1_99001800224.m4a
#EXTINF:4.992,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:51.262+000
a1_99002251424.m4a
#EXTINF:5.013,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:42:56.254+000
a1_99002700704.m4a
#EXTINF:4.992,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:43:01.267+000
a1_99003151904.m4a
#EXTINF:4.992,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:43:06.259+000
a1_99003601184.m4a
#EXTINF:5.013,
#EXT-X-PROGRAM-DATE-TIME:2020-08-31T17:43:11.251+000
a1_99004050464.m4a

Notice how all media playlists have different timestamps, albeit slightly.
Let's say that the starting timestamps for all media playlists could be the same (although this cannot be a prerequisite, because, as we discussed earlier, data streams can arrive with different delays, which must be reflected, otherwise the final stream received by the user will be corrupted).
In addition, the duration of video frames for all media playlists is the same and is equal to 5 seconds (this is also not a prerequisite, the duration of frames may well be different, both between different media playlists and within the same media playlist).
But look at the duration of the audio frames (stream_7). It is different for every frame, and it is extremely difficult to "fix" due to the very nature of audio frames.
And how do you propose to bring the timestamps of media playlists with video and audio to one common denominator?
The correct answer is no way, because this is not required.
Because, looking at the stream_0 media playlist, we see that the timestamps in it go one after another, continuously, moreover, digging in the headers/contents of the corresponding files, we will see that the playlist timestamps are completely consistent with these files. We will see a similar full match in stream_1, stream_2 and in all other playlists (and in stream_7, of course!).
To paraphrase, we will see a complete match of timestamps in all media playlists specified in the master playlist. This is exactly what the specification says.
By the way, the current implementation of EXT-X-PROGRAM-DATE-TIME has been working normally on more than one server for several months now, and no one has ever complained.

kqyang · 2020-08-31T19:24:13Z

@Ykidia Thanks for the data. I understand that it works well in most cases. Unfortunately, it will break if we put it in large scale use as it already shows inconsistencies. For example, if one of the stream is delayed by 0.5 seconds, which is possible in live case, players will see a difference of 0.5 seconds between two renditions although the two are supposed to be presented at the same time.

To paraphrase, we will see a complete match of timestamps in all media playlists specified in the master playlist. This is exactly what the specification says.

I am confused with your statement. Apparently the timestamp does not match between different representations, which clearly violates HLS spec.

Again, please explain your interpretation if you have a different understanding of how consistency works.

If you are concerned with how we can achieve consistent mapping, we can discuss that later once we agree on what it means. It is do-able and will just be slightly more complicated that what you have now.

Ykidia · 2020-09-01T05:06:24Z

@kqyang,

For example, if one of the stream is delayed by 0.5 seconds, which is possible in live case, players will see a difference of 0.5 seconds between two renditions although the two are supposed to be presented at the same time.

"Supposed to be"? This is just a guess based on the special-case data, where all segments are the same length; but they do not have to be the same, neither between media playlists, nor even within the single media playlist. And what will be supposed to be then? If all segments are different length, how to detect reference time stamp unambiguously?

The fact of the matter is that HLS spec. does NOT say, that timestamps must

match between different representations

, NOR contain any similar words to "between" or "across".

    If any Media Playlist in a Master Playlist contains an EXT-X-
    PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
    Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
    mappings of date and time to media timestamps.

This clearly means only that if we want to insert EXT-X-PROGRAM-DATE-TIME tags to one of the media playlist in master playlist, then we MUST to insert the tag to all the others media playlists in that master playlist. Moreover, simple tag insertion is not enough - timestamps in every media playlist must be consistent.
And they are consistent, within every media playlist!
But no qualifying words such as "between" or "across" or similar. The point is that, if necessary, there would be a corresponding clarification.

It is do-able and will just be slightly more complicated that what you have now.

Hmm, however, you intrigued me. Perhaps I do not fully understand your point of view? Please tell me in more detail how it should look. As I said earlier, I am trying to understand as much as possible.
And you did not answer my question:

how do you propose to bring the timestamps of media playlists with video and audio to one common denominator?

r0ro · 2020-09-12T00:56:11Z

Hi @Ykidia,

I tend to have the same interpretation of the HLS RFC as @kqyang and understand that the EXT-X-PROGRAM-DATE-TIME value should be consistent across different media playlists.

I've reworked your proposal in the following patch: https://github.com/Ykidia/shaka-packager/commit/27cf91ccf05ebca7c753208c1e02941f39de319e

Basically, instead of computing a "reference" time in each playlists independently I moved this logic to the upper layer in simple_hls_notifier.cc

I also changed the option to be able to specify an offset between current time and stream generation time, this way someone knowing that he's receiving the stream with a fixed delay can compensate for this delay.

And finally I only kept one EXT-X-PROGRAM-DATE-TIME for first segment and first segment following a discontinuity.

I've also submitted a pull request with stashed commits: #840

kqyang · 2020-10-04T07:13:02Z

Thank you @Ykidia for initiating the work on EXT_X_PROGRAM_DATE_TIME tag. And thank you @r0ro for improving it!

Close this PR as it is deprecated and replaced by #840.

Ykidia · 2020-10-05T19:54:37Z

@kqyang, I spoke to a real expert on this subject. His experience is greater, and his qualifications are higher than those with whom I worked and whose opinion I fiercely defended here. He explained to me that the solution to the issue is more difficult than I thought. I apologize for my harsh tone in this conversation. I was wrong and you are right. Thank you for your patience!

Adding support for generation of the EXT_X_PROGRAM_DATE_TIME tag for …

c42dcc2

…HLS playlists, with fixed UTC timezone

kqyang reviewed Aug 7, 2020

View reviewed changes

Ykidia added 5 commits August 7, 2020 12:34

Resolving some contributor's requests

d542d5d

Some more corrections

8066fd0

Some more edit

f4a0a78

.

2f38244

Removed unnecessary test. Moved ext_x_program_date_time flag to HlsPa…

104b8b3

…rams. Some other minor changes.

kqyang reviewed Aug 15, 2020

View reviewed changes

Few cosmetic changes.

4c57165

r0ro mentioned this pull request Sep 12, 2020

Adding support for hls EXT_X_PROGRAM_DATE_TIME #840

Closed

kqyang closed this Oct 4, 2020

Ykidia deleted the new_branch branch October 5, 2020 19:31

github-actions bot added the status: archived Archived and locked; will not be updated label Jul 24, 2023

github-actions bot locked as resolved and limited conversation to collaborators Jul 24, 2023

		AddSegmentInfoEntry(file_name, start_time, duration, start_byte_offset, size,
		start_timestamp);

Adding support for generation of the EXT_X_PROGRAM_DATE_TIME tag for … #814

Adding support for generation of the EXT_X_PROGRAM_DATE_TIME tag for … #814

Conversation

Ykidia commented Aug 6, 2020

googlebot commented Aug 6, 2020

What to do if you already signed the CLA

Individual signers

Corporate signers

google-cla bot commented Aug 6, 2020

What to do if you already signed the CLA

Individual signers

Corporate signers

Ykidia commented Aug 6, 2020

googlebot commented Aug 6, 2020

google-cla bot commented Aug 6, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ykidia Aug 10, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ykidia Aug 10, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ykidia commented Aug 26, 2020

kqyang commented Aug 27, 2020

Ykidia commented Aug 31, 2020

kqyang commented Aug 31, 2020

Ykidia commented Sep 1, 2020 • edited

r0ro commented Sep 12, 2020

kqyang commented Oct 4, 2020

Ykidia commented Oct 5, 2020

Ykidia Aug 10, 2020 •

edited

Ykidia Aug 10, 2020 •

edited

Ykidia commented Sep 1, 2020 •

edited