Incredibly large values of LL-HLS segments/parts

[PanicKk]

So, I was experimenting and decided to read a random .m3u8 file from the ones I specified to generate, and I caught something really strange...

#EXTM3U
#EXT-X-TARGETDURATION:2
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:1351
#EXT-X-SERVER-CONTROL:PART-HOLD-BACK=4.29492e+08
#EXT-X-PART-INF:PART-TARGET=1.43164e+08
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-PROGRAM-DATE-TIME:2023-05-30T09:39:07.933Z
#EXT-X-PART:DURATION=0.5,URI="'index_0001351'_track1_.ts.1",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.5,URI="'index_0001351'_track1_.ts.2",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.5,URI="'index_0001351'_track1_.ts.3",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.5,URI="'index_0001351'_track1_.ts.4",INDEPENDENT=YES
#EXTINF:2,
'index_0001351'_track1_.ts
#EXT-X-PART:DURATION=0.5,URI="'index_0001352'_track1_.ts.1",INDEPENDENT=YES
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="'index_0001352'_track1_.ts.2"
#EXT-X-RENDITION-REPORT:URI="index_1.m3u8",LAST-MSN=2480,LAST-PART=3

Some of the values are extraordinary large, especially for specified values of 2s for segments and 0.5s for parts...
#EXT-X-SERVER-CONTROL:PART-HOLD-BACK=4.29492e+08
#EXT-X-PART-INF:PART-TARGET=1.43164e+08

I really do not believe that this is supposed to happen!

• Why is this happening?
• Is this a problem?
• How can I solve it?

[jeanlf]

we would need a source file and the exact command line used to reproduce

[PanicKk]

Hi! This is the command I am using!

gpac -i rtmp:https://127.0.0.1:1935/live/livekey1234:gpac:analyzeduration=10M:probesize=10M:fflags=genpts:hlsc=true:fintra=0.5 --template='index_$Number%07d$' @@ ffsws:osize=1920x1080:keepar=nosrc @ c=libx264:b=5500k:profile=main:level=3.0:preset=fast:maxrate=6600k:bufsize=9900k:FID=VENC1080 @@ c=aac:b=96k:FID=AENC1080 -o 1080p/index.m3u8:segdur=2:cdur=0.5:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC1080,AENC1080 @@ ffsws:osize=1280x720:keepar=nosrc @ c=libx264:b=2000k:profile=baseline:level=3.0:preset=fast:maxrate=2400k:bufsize=3600k:FID=VENC720 @@ c=aac:b=96k:FID=AENC720 -o 720p/index.m3u8:segdur=2:cdur=0.5:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC720,AENC720 @@ ffsws:osize=854x480:keepar=nosrc @ c=libx264:b=985k:profile=baseline:level=3.0:preset=fast:maxrate=1182k:bufsize=1773k:FID=VENC480 @@ c=aac:b=96k:FID=AENC480 -o 480p/index.m3u8:segdur=2:cdur=0.5:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC480,AENC480 @@ ffsws:osize=640x360:keepar=nosrc @ c=libx264:b=486k:profile=baseline:level=3.0:preset=fast:maxrate=583k:bufsize=874k:FID=VENC360 @@ c=aac:b=40k:FID=AENC360 -o 360p/index.m3u8:segdur=2:cdur=0.5:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC360,AENC360 @@ ffsws:osize=426x240:keepar=nosrc @ c=libx264:b=216k:profile=baseline:level=3.0:preset=fast:maxrate=259k:bufsize=388k:FID=VENC240 @@ c=aac:b=40k:FID=AENC240 -o 240p/index.m3u8:segdur=2:cdur=0.5:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC240,AENC240 @@ ffsws:osize=256x144:keepar=nosrc @ c=libx264:b=126k:profile=main:level=3.0:preset=fast:maxrate=151k:bufsize=226k:FID=VENC144 @@ c=aac:b=4000k:FID=AENC144 -o 144p/index.m3u8:segdur=2:cdur=0.5:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC144,AENC144"

It is not a constant issue, most of the time I get the right values, but sometimes they are extraordinarily high, which is not supposed to even happen.

Also, I've been using GPAC 2.0 and this command works fine, but I am trying to update to 2.2 to stay up to date, and the filters are not connected.

These are the commands I've tried with GPAC 2.2:

gpac -i rtmp:https://127.0.0.1:1935/live/livekey1234:gpac:analyzeduration=10M:probesize=10M:fflags=genpts --template='index_$Number$07d$' @@ ffsws:osize=854x480:keepar=nosrc @ c=libx264:b=985k:profile=baseline:level=3.0:preset=fast:maxrate=1182k:bufsize=1773k:FID=VENC480 @@ restamp:fps=30/1:rawv=no @@ c=aac:b=96k:FID=AENC480 -o 480p/index.m3u8:segdur=4:cdur=0.5:asto=3:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:hlsc=true:fintra=0.5:SID=VENC480,AENC480

gpac -i rtmp:https://127.0.0.1:1935/live/livekey1234:gpac:analyzeduration=10M:probesize=10M:fflags=genpts @@ ffsws:osize=854x480:keepar=nosrc @ c=libx264:b=985k:profile=baseline:level=3.0:preset=fast:maxrate=1182k:bufsize=1773k:FID=VENC480 @@ restamp:fps=30/1:rawv=no @@ c=aac:b=96k:FID=AENC480 -o 480p/index.m3u8:segdur=4:cdur=0.5:asto=3:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:hlsc=true:fintra=0.5:template='index_$Number$07d$':SID=VENC480,AENC480

gpac -i rtmp:https://127.0.0.1:1935/live/livekey1234::gpac:analyzeduration=10M:probesize=10M:fflags=genpts:hlsc=true:fintra=0.5 --template='index_$Number%07d$' @@ ffsws:osize=854x480:keepar=nosrc @ c=libx264:b=985k:profile=baseline:level=3.0:preset=fast:maxrate=1182k:bufsize=1773k:FID=VENC480 @@ restamp:fps=30/1:rawv=no @@ c=aac:b=96k:FID=AENC480 -o 480p/index.m3u8:segdur=4:cdur=0.5:asto=3:profile=live:dmode=dynamic:llhls=sf:muxtype=ts:SID=VENC480,AENC480

I get these errors:

Filter ffdmx:hlsc option set but not used
Filter ffdmx:fintra option set but not used
Filter ffdmx:template option set but not used

Has there been any changes on how the latest version parses and links filters?

[jeanlf]

hlsc and template are options of the dasher and when set locally, should be set on the output filter (mpd or m3u8) not on ffdmx.
fintra is an option of ffenc and should not be set on ffdmx.

Also in your commands, the restamper filter is useless since it does not link to anything.

I tried your command generating the rtmp from a looping local source, I cannot reproduce. I think the issue comes from the RTMP source, I suspect the timestamps are sometimes broken. Could you please try to rip a session to gsf and upload it ?

Ripping to gsf
gpac -i RTMP_URL -o rip.gsf

in your setup, add at the end:
@@ -o rip.gsf

[jeanlf]

any news on this ?