New: Option to not to use EXT-X-DISCONTINUITY in SCTE35 marks about scte-35_hls_x9k3 HOT 12 CLOSED

You good on this?

from scte-35_hls_x9k3.

Let me look into this.

from scte-35_hls_x9k3.

I believe I may have just fixed that with the last commit. I'll do a new build here shortly, v0.1.91 .

from scte-35_hls_x9k3.

Not really

The code is inserting EXT-X-DISCONTINUITY on each SCTE35 tag (whatever the type is). That is not the correct way. The EXT-X-DISCONTINUITY it is only used if the fragments codification change: for instance, if you have a new video in the live flow, or if you replace an original fragment with an advertisement.

As the code is just generating segments for the same content, EXT-X-DISCONTINUITY is not expected, making the player to freeze. BTW there are a lot of examples on Internet where you can see the EXT-X-DISCONTINUITY in the playlist, BUT because this is AFTER the manifest manipulation that permit to insert an Ad as a replacement of the original content.

The solution is to strip out the EXT-X-DISCONTINUITY from the SCTE35 tags. I can provide a PR if you want, but I would prefer to know your opinion first.

from scte-35_hls_x9k3.

Another thing that could be implemented is to continue the sequence of .ts files without deleting the index.m3u8, just by appending when restarting x9k3.

from scte-35_hls_x9k3.

Another thing that could be implemented is to continue the sequence of .ts files without deleting the index.m3u8, just by appending when restarting x9k3.
He submitted a pull request, we need a command line option, I need a letter and a name for it.
I am thinking

-c --continue

which would mean to continue the index.m3u8 either in the current dir or in output dir if specified.

thoughts?

from scte-35_hls_x9k3.

First off, let's be clear about the role of discontinuity tags.
This comes straight for the spec.

The client MUST be prepared to reset its parser(s) and decoder(s)before playing a Media Segment that has an EXT-X-DISCONTINUITY tag applied to it; otherwise, playback errors can occur.

The EXT-X-DISCONTINUITY tag MUST be present if there is a change in
any of the following characteristics:

• file format
• number, type, and identifiers of tracks
• timestamp sequence

The EXT-X-DISCONTINUITY tag SHOULD be present if there is a change in
any of the following characteristics:

• encoding parameters
• encoding sequence

Here's what I know, you have something else going on.

• I have been testing, I peppered the m3u8 full of discontinuity tags, I have no issue at all . You can have them on every segment, I know this because I tried it.

That being said, I have no problem adding an option to disable them, just give me a letter and word.
We can use a -D --disable-discontinuity or -n --no-discontinuity

I made some comments on your pull request.

Just give me a minute, I'll get this in there for you.

from scte-35_hls_x9k3.

Hi @futzu. Thanks for your thoughts. Let me explain the use case I was doing and the tests that I've made. I don´t doubt that you made your tests for sure. But I have, at least one case where it was not working. Hopefully it is better undestood.

I have an input file sample.ts that is a FFMPEG MPEG-TS generated file. This file last 50 seconds more or less. When you execute x9k5 on it, without any cue, it does the segmentation so I get with the multiple ts files according to the --time option. Perfect. Only VoD, no live mode.

Now, I insert the cue with the sidecar file, and the segmenter does the work of generating the segments according to the cue points. Perfect.

Well. In my test, with this file, having the EXT-X-DISCONITNUITY before each of the CUE segments break the playout. The player freezes and lost time in the play, tested with hls.js and native IOS player. If I take the exact same playlist generated and strip out alll the EXT-X-DISCONTINUITY tags, the playout, with the exact same segments works perfect. I can provide the sample.ts I've used if you want to use it.

That is the test. But let's get into the RFC.

Having a sample.ts segmented in multiple ts, the file format, number, type, PIDs, encoding parameters, sequence, are all the same in all the segments. When the tool detects a CUE point according to the sidecar, will generate new segments at those CUE points, but again those new segments share all the properties, and it does not break the sequence of the playout. So, in that case, I don´t see any of the conditions for what the RFC indicates a EXT-X-DISCONTINUITY is required. And it makes completely sense. Maybe I'm missing something, so in that case please let me know.

In the replay mode, the EXT-X-DISCONTINUITY is required when the stream is restarted and added into the playlist. The TS file has PTS, and when the tool reinsert the file again in the playout, the PTS is reset. That's why the players need to know that there is a change. Without the EXT-X-DISCONTINUITY when restarting the stream, it does not work for hls.js neither native ISO player. In the case of hls.js, you get an Buffer underrun error if the discontinuity is not included.

from scte-35_hls_x9k3.

Another thing that could be implemented is to continue the sequence of .ts files without deleting the index.m3u8, just by appending when restarting x9k3.
He submitted a pull request, we need a command line option, I need a letter and a name for it.
I am thinking

-c --continue

which would mean to continue the index.m3u8 either in the current dir or in output dir if specified.

thoughts?

Can this be put in a different issue? I don´t think we can maintain 2 discussions in the same place :)

from scte-35_hls_x9k3.

@futzu BTW, I don´t see any comments in the PR. It appears without review.

from scte-35_hls_x9k3.

version v0.1.93

from scte-35_hls_x9k3.

This works, for VoD, and live mode for SCTE35 marks. But this could affect replay mode, as EXT-X-DISCONTINUITY must be added in any case.

AS I will open a more detailed issue about replay mode, I close this as a solution for SCTE35 marks. Thanks

from scte-35_hls_x9k3.