While HLS Draft in section 3.4.5 require that time should comply with RFC3339, during my work i noticed that many Encoders use ISO8601 where Timezone representation is less strict than RFC3339. ISO8601 allow to expose TZ in several ways:

DateTime/Zone
<time>Z
<time>±hh:mm (by RFC3339)
<time>±hhmm
<time>±hh

Example of manifest where we getting Parser error:

#EXTM3U
#EXT-X-TARGETDURATION:8
#EXT-X-PROGRAM-DATE-TIME:2017-01-30T17:26:04+0100
#EXT-X-MEDIA-SEQUENCE:855733
#EXTINF:8,
1478947334-fast-1920-1080-2750000-855733.ts
#EXTINF:8,
1478947334-fast-1920-1080-2750000-855734.ts
#EXTINF:8,
1478947334-fast-1920-1080-2750000-855735.ts

Error itself: parsing time "2017-01-30T17:26:04+0100" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "+0100" as "Z07:00"

But while RFC3339 newer then ISO8601, lot of software still use it, so my proposal is to create Format validation for incoming tag #EXT-X-PROGRAM-DATE-TIME in reader.go and using switch{case} test incoming string against precompiled regexp rules, and route string to time.Parse() with proper layout(format).

I implemented only RFC3339 with Nano seconds, this should be enough and in case we need add other formats this will be easy to add to switch{case} chain.

Increase efficiency for large playlist.

before

BenchmarkDecodeMediaPlaylist-8        50          23445112 ns/op        12282139 B/op     160240 allocs/op
BenchmarkEncodeMediaPlaylist-8       100          14378131 ns/op         1749294 B/op      81643 allocs/op

after

BenchmarkDecodeMediaPlaylist-8       100          16781361 ns/op        11001559 B/op     120172 allocs/op
BenchmarkEncodeMediaPlaylist-8       100          13064495 ns/op         1744527 B/op      81247 allocs/op

When decoding a playlist with a window size bigger than 8 then an encode will result in a truncated playlist. This due to this line here.

media, err = NewMediaPlaylist(8, 1024) // TODO make it autoextendable

Would it be possible to update the winsize afterwards through Count() internally?

Hello, thanks for an awesome m3u8 project. We came across the need to read and write custom tags to m3u8 so I've implemented it through an interface in my fork, but would love to get this upstream so we don't have to use a fork. I've implemented this in a way that should allow for the parsing of any format as the user will have to implement the interface. This way we do not have to pollute the source code with parsing/writing for non-standard tags that only a few users have need for or that cant be made open source. I've also included example template files for how to implement your own custom tag readers and writers.

I noticed there is an issue as well that this will help resolve #82

Sorry, I am a Golang newbie and my use case is to introduce a new key into the variant called 'rendition-id' to help clients create a rendition switcher.

package main

import (
	"fmt"

	"github.com/grafov/m3u8"
)

// https://godoc.org/github.com/grafov/m3u8#VariantParams

type myVariantParams struct {
	*m3u8.VariantParams
	RenditionId string
}

func main() {

	masterPlaylist := m3u8.NewMasterPlaylist()

	pp, _ := m3u8.NewMediaPlaylist(3, 5)
	for i := 0; i < 5; i++ {
		pp.Append(fmt.Sprintf("test%d.ts", i), 5.0, "")
	}

	// WORKS
	masterPlaylist.Append("chunklist2.m3u8", pp, m3u8.VariantParams{ProgramId: 123, Bandwidth: 1500000, Resolution: "576x480"})

	// Trying to extend VariantParams doesn't !
	// masterPlaylist.Append("chunklist2.m3u8", pp, myVariantParams{VariantParams: &m3u8.VariantParams{ProgramId: 123, Bandwidth: 1500000, Resolution: "576x480"}, RenditionId: "foo"})

	fmt.Println(len(masterPlaylist.Variants))
	masterPlaylist.ResetCache()

	fmt.Println(masterPlaylist.Encode().String())

}

Perhaps this is the same as #82. Anyway, just thought I'd convey my use case. My tact now is to fork and add the missing values.

This library uses the GPL license which makes it actually impossible for us to use as it would require us to use the GPL license as well as disclose our source code. Working on a commercial product it would mean that we need to move away from this library and roll our own implementation.

How deliberate is the choice of GPL. Would other, more permissive licenses, like MIT or Apache be a feasible alternative?

There appear to be various non-standard implementations of SCTE-35 integration with HLS.

The recent draft of HLS now has an official method to support SCTE-35 tags as well as the cue points. See: https://www.ietf.org/rfcdiff?url1=draft-pantos-http-live-streaming-18&url2=draft-pantos-http-live-streaming-19

I'd like this library to support the new standard, but #40 and #41 introduced support for a different standard. There's also at least two other formats I've seen.

I think we need a method to read multiple standards, store and manipulate them consistently and write multiple standards. With the focus being on the HLS RFC's method, and the existing format already supported by this library - but this may require some breaking changes.

This issue is open to discuss this.

Other support that could be added later: http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/primetime/pdfs/PrimetimeDigitalProgramInsertionSignalingSpecification1_1.pdf

Deprecation: MediaPlaylist.SetSCTE() has been deprecated, use MediaPlaylist.SetSCTE35() instead

SCTE has 3 new fields, .Syntax defines the format of the SCTE data, .CueType defines whether the cue point was start/mind/end, .Elapsed can be used for formats that track the elapsed time.

SCTE now supports another SCTE-35 syntax we've nicknamed OATCLS (due to the presence of this string in the tag), see sample-playlists/media-playlist-with-oatcls-scte35.m3u8 for an example. Both reads and writes are supported.

The stats show that the library still in use by many people and the code still actual. Thanks a lot to all the contributors! Of course, this lib is the small piece of code but it added some value to the applicability of Go for writing the video casting applications. Unfortunately, working with video is out of the scope of my current interests. I coding mostly on Go since 2012 and think this language was the right choice for me. But the areas where I apply my programming skills shifted a lot from the time when I started the M3U8 library. So in future, I could add minor changes like code style and readme updates but I have no resources to review the major changes that require the actual knowledge in modern M3U8 standard and in the areas of the video casting.

Now the project has two maintainers — me and @bradleyfalzon. Bradley helped a lot with reviewing and contributing. But it seems we need more people who currently working in the area of video casting and interested in support of this lib. There are a lot of issues that could be reviewed and merged.

I could still keep my rights of the project owner for the project safety. And keep the main purpose of the library — be simple and allow basic features for parsing and generating M3U8 playlists.

Drop a comment if you would ready to become the maintainer of the project.

Each sub manifest has its initial (media) sequence number and I was under the impression that the attribute SeqId from the MediaSegment was the individual media sequence for that segment, am I right?

Also, I was browsing through the docs and also the source code and I couldn't find where the attribute SeqId is filled.

Hi @grafov, I added an InsertSegment method to account for when segments arrive out-of-order during a live-streaming scenario. It was useful for me in a p2p context.

Just want to merge back in case this is useful for you as well :)

#EXTM3U #EXT-X-VERSION:7 #EXT-X-MAP:URI="EPICGAMING_S01E01_MARIOKART8_1080p.m4s",[email protected] #EXT-X-PLAYLIST-TYPE:VOD #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-TARGETDURATION:2 #EXT-X-BYTERANGE:[email protected] #EXTINF:2.000, EPICGAMING_S01E01_MARIOKART8_1080p.m4s #EXT-X-BYTERANGE:1054[email protected] #EXTINF:2.000, EPICGAMING_S01E01_MARIOKART8_1080p.m4s

in attributes of EXT-X-MAP, value of BYTERANGE is a quoted-string。but the lib is not a quoted-string。then play failed in safari。

retry this

import (
	"bytes"
	"fmt"

	"github.com/grafov/m3u8"
)

func main() {
	body := `#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PROGRAM-DATE-TIME:2022-03-01T20:15:19.786+08:00
#EXT-X-TARGETDURATION:4
#EXTINF:4.000,
test
#EXTINF:4.000,
test
#EXTINF:4.000,
test
#EXTINF:4.000,
test
#EXTINF:4.000,
test
#EXTINF:4.000,
test
#EXT-X-ENDLIST
`
	p, listType, err := m3u8.DecodeFrom(bytes.NewReader([]byte(body)), true)
	if err != nil {
		panic(err)
	}
	switch listType {
	case m3u8.MEDIA:
		mediapl := p.(*m3u8.MediaPlaylist)
		for _, segment := range mediapl.Segments {
			println(segment.URI)
		}
	case m3u8.MASTER:
		masterpl := p.(*m3u8.MasterPlaylist)
		fmt.Printf("%+v\n", masterpl)
	}
}

Expected Behavior

print the url of segments

Actual Behavior

program panic

Solve

https://github.com/grafov/m3u8/pull/186

Add support for attribute CHANNELS. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-10#section-4.4.6.1

https://github.com/grafov/m3u8/issues/181

CHANNELS should be recognized according to the RFC

All audio EXT-X-MEDIA tags SHOULD have a CHANNELS attribute.

Yes, I am aware of func SetCustomTag() but this is an existing tag and even if I could use that to bend the existing tag handler to include the CHANNELS attribute it would be nice if m3u8 can follow the standard.

There is an old and incomplete (lacks reader, lacks tests) PR for this in https://github.com/grafov/m3u8/pull/168

Maybe, maybe, we (my team), can finish that job.