-
Notifications
You must be signed in to change notification settings - Fork 507
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TS] Segment template $Time$ is truncated to 32 bits #701
Comments
@Canta Thanks for the issue report. This looks like a bug to me as the timestamp should be 64 bits instead of 32 bits, i.e. it shouldn't wrap around at 0xffffffff. Are you able to re-produce the problem? Can you increase verbose level to 4 (--v=4)? It can produce more debug which may give us a clue on where and why the timestamp is truncated? |
Errr... I think that would be messy. If I did my math right (most likely I did not), it would take 1.7 days or so to reach that point from zero. All that time generating verbose logs will make it hard to handle, and I gotta guess when does the wrap actually happen. No worries, I'll do it if it's needed to understand this. But would really like to avoid it. Isn't it any way to force the startup I'll take a look at this, make some experiments. If no luck, I'll go your way and generate a huge log somewhere. It most likely will take me a day or two to set this up. Please let me know if you happen to know a better way to trigger this. Thanks! |
@Canta I have not tried myself but I think you instruct ffmpeg to generate a stream with large time offsets. Shaka Packager does not change timestamps. The input timestamp will be carried as is to the output (unless it is truncated somewhere). There are two possible causes of the problem: Let us know if you manage to create a source stream using ffmpeg with large timestamps. It will help us with the investigation.
It should be 0.55 days if starting from 0: (1 << 32) / 90000.0 / 3600 / 24. You may also use any of your existing live stream and let it run for 0.55 days. |
Update: I still didn't had the time to test it right, but I've seen something strange that I'd like to report here. I get an input stream, transcode it, and feed it to two different shaka packager instances: one for HLS, and another one for MPEG-DASH. This is because I need two different encryption setups for DRM. But both packager instances receives the same (splitted) input: no changes in timestamps at all between them. The weird thing I see is that MPEG-DASH doesn't show this problem. DASH chunks are generated fine with times like Thing is, I'm using my fork of shaka packager discussed in #691, which indeed deals with HLS mechanics. Could it be related? In fact, I have this concrete question: is the Shouldn't be the case, as otherwise it would give me negative numbers given the same situation. But It's the only thing I can't think of here. Perhaps I triggered another hidden bug somehow by my modifications? |
Ahh, that is good information. No, it is not because of your change, but your data does help us pinpoint where the problem is: diff --git i/packager/media/formats/mp2t/ts_segmenter.cc w/packager/media/formats/mp2t/ts_segmenter.cc
index 3474ec1a..aaea5ced 100644
--- i/packager/media/formats/mp2t/ts_segmenter.cc
+++ w/packager/media/formats/mp2t/ts_segmenter.cc
@@ -125,7 +125,7 @@ void TsSegmenter::SetTsWriterFileOpenedForTesting(bool value) {
ts_writer_file_opened_ = value;
}
-Status TsSegmenter::OpenNewSegmentIfClosed(uint32_t next_pts) {
+Status TsSegmenter::OpenNewSegmentIfClosed(int64_t next_pts) {
if (ts_writer_file_opened_)
return Status::OK;
const std::string segment_name =
diff --git i/packager/media/formats/mp2t/ts_segmenter.h w/packager/media/formats/mp2t/ts_segmenter.h
index 78a88d22..b140040e 100644
--- i/packager/media/formats/mp2t/ts_segmenter.h
+++ w/packager/media/formats/mp2t/ts_segmenter.h
@@ -71,7 +71,7 @@ class TsSegmenter {
void SetTsWriterFileOpenedForTesting(bool value);
private:
- Status OpenNewSegmentIfClosed(uint32_t next_pts);
+ Status OpenNewSegmentIfClosed(int64_t next_pts);
// Writes PES packets (carried in TsPackets) to a file. If a file is not open,
// it will open one. This will not close the file. Can you try if the above change fixes your problem? If yes, you are welcome to send us a pull request? Thanks. |
The TS format! That's something I started using about a week ago because of some devices. When I used fmp4 I never saw this happening, and I'm using it only for HLS. Makes sense. I've patched this by hand in one of our servers, and will let it run the whole weekend on a single stream. Most likely will have feedback by next monday. BTW, two questions:
Thanks a lot. |
Great.
Yes, it is a user set offset. We don't expect it to be more than (1 << 32) / 90000 seconds.
Yes, please use int64_t for consistency. And yes, it is signed so it can handle negative numbers in some situations. |
It worked. Now I see ts segments with Let me first finish the #691 PR, and then will send you another one for this. It's an easy fix. |
@Canta Great. Thanks for the confirmation! |
Also, added Daniel Cantarín to AUTHORS and CONTRIBUTORS files, as per @kqyang comment: shaka-project#702 (comment)
The fix was cherry-picked to v2.4.2. |
System info
Operating System: CentOS Linux release 7.7.1908 (Core)
Shaka Packager Version: c731217
Issue and steps to reproduce the problem
Quick description:
When packager runs for a long enough time,
$$Time$$
value resets and goes back from zero.Packager Command:
What is the expected result?:
To increase linearly the value of
$$Time$$
What happens instead?:
$$Time$$
resets its value.Additional information:
Please take a look at this HLS medialist extract:
There, you can see a sudden time jump, from
4294929887
to250591
.I believe what's happening is that this
$$Time$$
value increased over theuint32
limit of4294967295
(0xffffffff
).There's no error, nor any signal restart. Playback is fine. However, I do some other stuff with the chunks later, outside of shaka packager's scope. I need to have a linear incremental time-related filename for the chunks. The
[rendition]_$$Time$$.[extension]
pattern is great for me, but this overflow thing is giving me trouble.I believe the most obvious fix would be to change that variable data type to something bigger. However, I'm also not sure what are my options. I'm feeding streams to shaka packager through UDP or pipes. They're MPEGTS streams. I could play with ffmpeg or any other tool in a way to handle that
$$Time$$
: let's say, for example, taking away a few orders of magnitude. As long as the result is linearly incremental, and has a time-based logic, I'm fine with it. But I'm not sure what parameter would let me exactly do something like that. I saw in the docs that it mentionsprintf
formatting options, but the only example I see is how to put a minimum order of magnitude with padding, and such thing will not save me from this problem.So, in this ticket I ask for one of two things:
$$Time$$
data type to something bigger thanuint32
?Thanks.
The text was updated successfully, but these errors were encountered: