[feature] hls m3u8 format

[josepowera]

I was just testing 0.0.3 and found some ideas that might be for general use. I'm mostly targeting player compatibility of hls m3u8 format. I have to start learning python to be able to make PR once in future. :)

-use leading zeroes for segment filename, because looking thru the folder to debug .ts files looks way simpler when files are sorted ascending.

seg11.ts 
seg00000011.ts

-add option --segmentfileprefix for segment file name prefix...
Why: because if app is restarted file names should change in order for CDN to refresh them. For .ts you normally configure CDN cache for 24hours or more.

If user can provide prefix, it's easy to change - for example using bash epochtime variable on app start. There is another option to write last segment# to file, and reread on start, but that would just complicate things...

-when you write custom hls attribute it's better to be on safe side, that some players don't break. Just use double hash ## for line to become comment

#EXT-X-UMZZ-VERSION:0.0.3
to:
##EXT-X-UMZZ-VERSION:0.0.3

same goes for Iframe

#Iframe:213.0
to:
##Iframe:213.0

-write program-data-time with max 3 decimals...
It would make sense to format time output (program date time) to max 3 decimals in "seconds" part. It's probably just some double rounding, that got this extra data, however it's nice to have output that is up to specification or at least example from official specification.

original variant m3u8

#EXT-X-PROGRAM-DATE-TIME:2023-04-11T16:31:37.433+02:00
#EXTINF:3,
https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/20230404T122017/master_1660/00068/master_1660_02627.ts

umzz output:
#EXT-X-PROGRAM-DATE-TIME:2023-04-11T14:32:59.430210Z

and Specification from apple Examine a Low-Latency HLS Playlist

#EXTM3U
...
#EXT-X-PROGRAM-DATE-TIME:2019-02-14T02:13:36.106Z

[futzu]

• I'm cool with 3 decimal places on the date time. I'll fix that shortly.

• If user can provide prefix, it's easy to change - for example using bash epochtime variable on app start. There is another option to write last segment# to file, and reread on start, but that would just complicate things...

  • We could write the segment number, and that would be good for crashes as well.

• We can add custom segment prefixes later, but I know that is important. I just try to keep it as simple as possible until we get it working.

• How many zeros in a segment name? Give me a number and I'll update it.

Sidenote:

use ls -rt to sort segments in directories

a@debian:~/build$ ls -rt 0/
seg0.ts   seg13.ts  seg26.ts  seg39.ts  seg52.ts  seg65.ts  seg78.ts  seg91.ts   seg104.ts
seg1.ts   seg14.ts  seg27.ts  seg40.ts  seg53.ts  seg66.ts  seg79.ts  seg92.ts   seg105.ts
seg2.ts   seg15.ts  seg28.ts  seg41.ts  seg54.ts  seg67.ts  seg80.ts  seg93.ts   seg106.ts
seg3.ts   seg16.ts  seg29.ts  seg42.ts  seg55.ts  seg68.ts  seg81.ts  seg94.ts   seg107.ts
seg4.ts   seg17.ts  seg30.ts  seg43.ts  seg56.ts  seg69.ts  seg82.ts  seg95.ts   seg108.ts
seg5.ts   seg18.ts  seg31.ts  seg44.ts  seg57.ts  seg70.ts  seg83.ts  seg96.ts   seg109.ts
seg6.ts   seg19.ts  seg32.ts  seg45.ts  seg58.ts  seg71.ts  seg84.ts  seg97.ts   seg110.ts
seg7.ts   seg20.ts  seg33.ts  seg46.ts  seg59.ts  seg72.ts  seg85.ts  seg98.ts   seg111.ts
seg8.ts   seg21.ts  seg34.ts  seg47.ts  seg60.ts  seg73.ts  seg86.ts  seg99.ts   index.m3u8
seg9.ts   seg22.ts  seg35.ts  seg48.ts  seg61.ts  seg74.ts  seg87.ts  seg100.ts
seg10.ts  seg23.ts  seg36.ts  seg49.ts  seg62.ts  seg75.ts  seg88.ts  seg101.ts
seg11.ts  seg24.ts  seg37.ts  seg50.ts  seg63.ts  seg76.ts  seg89.ts  seg102.ts
seg12.ts  seg25.ts  seg38.ts  seg51.ts  seg64.ts  seg77.ts  seg90.ts  seg103.ts

[futzu]

I really want to try it without re-segmenting, you cool with that?
Maybe the way to go is to have a re-segmenting option, but by
default we just rewrite the m3u8 files, what do you think?

[josepowera]

I separated this Issues for only future requests, just to keep bug fixes as priority, and at the same time keep logging any idea.

For segment numbering I'd go with seg0000001.ts (total 7 numbers). Reason: 201600 segs in a week at 3 seconds. (7243600/3). That means that even if you keep 1 month log you're still on safe side.. For normal video this would be big, but if you save audio with 64kbit it's not that much data..

For segments I was working with nice trick.. ls -l --time-style=full-iso to have full timestamp of file (including ms).. But yeah, I'm lazy and prefer to open folder in midnight commander. Thx for ls -rt!

[futzu]

Tell me this, what is your reasoning behind 3 seconds?
7 digits for segment names, I can live with that.

[josepowera]

3 seconds. No special reason, It could be 2 seconds like your default (thats 1209600 in a month), it was just quick calc.. My First calc was done with apple spec for 6 seconds, than decided that if we double (half) the number we are on the safe side... For LL-HLS I see live numbers down to 2 seconds. But that's another story.