I would like to understand if GPAC supports HLS [RFC8216bis-3](https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-13), since I'm trying to use gpac for implementing LLHLS Origin PUSH setup and I'm dealing with several problems  which I'm going to report below. I would like to know better how GPAC should work.

GPAC 2.2 Command on Ubuntu 20.04: `gpac -graph -r -stats -i video.mp4 reframer:rt=on -o http://localhost:8000/live.m3u8:gpac:hmode=push:segdur=6:cdur=1:profile=live:dmode=dynamic:hmode=push:llhls=br -no-h2`

Client Player: [Hls.js](https://hlsjs.video-dev.org/demo/)

1) Is there any support to Playlist Delta Update? It looks that gpac sends media playlists every time that they are changed, is that right? If it is so, should I overwrite the playlists on server side? 

2) In both RFC8216 and RFC8216bis-13, there is a specification about EXT-X-TARGETDURATION, which MUST NOT change (see [General Server Responsabilities](https://datatracker.ietf.org/doc/html/rfc8216#section-6.2.1). Why does gpac send a new media playlist with EXT-X-TARGETDURATION=10 altough in the previous requests it was 6 as I declared into the command? (See files in the attachments)

3) If you look at the version 15 of live1.m3u8 in the attachments, you can observe the following aspects:
        > EXT-X-TARGETDURATION=11 (still changing before previous one)
        > All media segments previous at _video_dash_track1_9.m4s_  are not present anymore
        > There are some media segments with subsegments and other without. 
    Does all look correct for you?

4) Client player interrups the playback because it makes a request for a segment that has not available in the server side yet. Why does it happen? Should player follow and make request according to what is written inside media playlists?

5) Gpac prints a lot of error messages regarding Network Unreachable and some issues on dasher filter.

In the attachments you can find:

- _playlists.zip_: contains some of the most important versions of playlists exchanged between gpac and server.

- _gpacLiveStreamingHls.pcap_:  contains the whole network trace of all packets exchanged between gpac application and server both of them running on the same host. Server uses tcp port 8000. It was made with _tcpdump_

- _gpacLogsScreenshot.png_: logs printed by the command above

Please let me know, if you need more information about the test that I run.

[playlists.zip](https://github.com/gpac/gpac/files/11461733/playlists.zip)
![gpacLogsScreenshot](https://github.com/gpac/gpac/assets/40350337/4ebfa352-9549-4e0b-a3e8-bd1419a6ab1c)
[gpacLiveStreamingHLs.zip](https://github.com/gpac/gpac/files/11461737/gpacLiveStreamingHLs.zip)

HLS RFC8216bis-13
This is a GitHub Issue
repo:gpac
owner:gpac
Title : HLS RFC8216bis-13
Issue date:

--- start body ---
I would like to understand if GPAC supports HLS [RFC8216bis-3](https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-13), since I'm trying to use gpac for implementing LLHLS Origin PUSH setup and I'm dealing with several problems  which I'm going to report below. I would like to know better how GPAC should work.

GPAC 2.2 Command on Ubuntu 20.04: `gpac -graph -r -stats -i video.mp4 reframer:rt=on -o http://localhost:8000/live.m3u8:gpac:hmode=push:segdur=6:cdur=1:profile=live:dmode=dynamic:hmode=push:llhls=br -no-h2`

Client Player: [Hls.js](https://hlsjs.video-dev.org/demo/)

1) Is there any support to Playlist Delta Update? It looks that gpac sends media playlists every time that they are changed, is that right? If it is so, should I overwrite the playlists on server side? 

2) In both RFC8216 and RFC8216bis-13, there is a specification about EXT-X-TARGETDURATION, which MUST NOT change (see [General Server Responsabilities](https://datatracker.ietf.org/doc/html/rfc8216#section-6.2.1). Why does gpac send a new media playlist with EXT-X-TARGETDURATION=10 altough in the previous requests it was 6 as I declared into the command? (See files in the attachments)

3) If you look at the version 15 of live1.m3u8 in the attachments, you can observe the following aspects:
        > EXT-X-TARGETDURATION=11 (still changing before previous one)
        > All media segments previous at _video_dash_track1_9.m4s_  are not present anymore
        > There are some media segments with subsegments and other without. 
    Does all look correct for you?

4) Client player interrups the playback because it makes a request for a segment that has not available in the server side yet. Why does it happen? Should player follow and make request according to what is written inside media playlists?

5) Gpac prints a lot of error messages regarding Network Unreachable and some issues on dasher filter.

In the attachments you can find:

- _playlists.zip_: contains some of the most important versions of playlists exchanged between gpac and server.

- _gpacLiveStreamingHls.pcap_:  contains the whole network trace of all packets exchanged between gpac application and server both of them running on the same host. Server uses tcp port 8000. It was made with _tcpdump_

- _gpacLogsScreenshot.png_: logs printed by the command above

Please let me know, if you need more information about the test that I run.

[playlists.zip](https://github.com/gpac/gpac/files/11461733/playlists.zip)
![gpacLogsScreenshot](https://github.com/gpac/gpac/assets/40350337/4ebfa352-9549-4e0b-a3e8-bd1419a6ab1c)
[gpacLiveStreamingHLs.zip](https://github.com/gpac/gpac/files/11461737/gpacLiveStreamingHLs.zip)

--- end body ---
