Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

- [x] I looked for a similar issue and couldn't find any.
- [x] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
- [x] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: http://gpac.io/bug-reporting/

---

Dear gpac team:

I'm trying out a low latency dash setup with the built-in HTTP server file sink. I tried requesting a ongoing segment with `curl`. 
I noticed that even though the header did say `Transfer-Encoding: chunked`, and the transfer is indeed using chunked HTTP chunked transfer correctly, the timing of the chunks delivery is delayed.

I have observed the following when a GET request is made against a segment that is being produced.
1. Transfer the already written data immediately as the first chunk(s).
2. When the segment is fully complete, transfer the rest of chunks.

But according to the docs, it should rather be that a chunk is transferred as soon as received.

My setup to reproduce and demostrate the mentioned behavior:
- `gpac` version
```
gpac - GPAC command line filter engine - version 2.3-DEV-rev612-gcea3eeb7-master
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
```
- Command to generate the low latency dash
```
gpac -i video.mp4 reframer:rt=on @ -o http://localhost:8080/live.mpd:rdirs=outdir:segdur=10:cdur=1:reqlog=GET:dynamic:timeout=30
```
- Command to request the producing chunk
```
curl --trace-time --trace-ascii tracefile -o /dev/null http://localhost:8080/video-post_dash_track2_5.m4s
```
- Key traces
  -  A chunk was sent upfront while the rest of the chunks are all sent at once around 15:34:20
```
0000: GET /video-post_dash_track2_5.m4s HTTP/1.1
002c: Host: localhost:8080
0042: User-Agent: curl/7.88.1
005b: Accept: */*
0068: 
15:34:16.544927 <= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
15:34:16.544993 <= Recv header, 22 bytes (0x16)
0000: Server: GPAC 2.3-DEV
15:34:16.545003 <= Recv header, 37 bytes (0x25)
0000: Date: Thu, 26 Oct 2023 07:34:16 GMT
15:34:16.545012 <= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
15:34:16.545020 <= Recv header, 24 bytes (0x18)
0000: Keep-Alive: timeout=30
15:34:16.545031 <= Recv header, 28 bytes (0x1c)
0000: Transfer-Encoding: chunked
15:34:16.545040 <= Recv header, 2 bytes (0x2)
15:34:16.545045 <= Recv data, 9846 bytes (0x2676)
...
15:34:20.816489 <= Recv data, 10000 bytes (0x2710)
15:34:20.817787 <= Recv data, 30186 bytes (0x75ea)
15:34:20.821023 <= Recv data, 10000 bytes (0x2710)
15:34:20.822142 <= Recv data, 10000 bytes (0x2710)
15:34:20.823493 <= Recv data, 10000 bytes (0x2710)
15:34:20.824825 <= Recv data, 10000 bytes (0x2710)
15:34:20.826173 <= Recv data, 10000 bytes (0x2710)
15:34:20.827521 <= Recv data, 10000 bytes (0x2710)
15:34:20.828869 <= Recv data, 10000 bytes (0x2710)
15:34:20.835266 <= Recv data, 10000 bytes (0x2710)
15:34:20.841620 <= Recv data, 10000 bytes (0x2710)
15:34:20.842950 <= Recv data, 10000 bytes (0x2710)
15:34:20.844094 <= Recv data, 10000 bytes (0x2710)
15:34:20.845188 <= Recv data, 2842 bytes (0xb1a)
```
[Gist for full trace](https://gist.github.com/hiimdoublej-swag/a6b07798fa2baf06877a1225cec60df1)

I'll happily provide more information to clarify, or help test out some setups if needed, thanks.
HTTP server file sink does not transfer chunks in time.
This is a GitHub Issue
repo:gpac
owner:gpac
Title : HTTP server file sink does not transfer chunks in time.
Issue date:

--- start body ---
Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

- [x] I looked for a similar issue and couldn't find any.
- [x] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
- [x] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: http://gpac.io/bug-reporting/

---

Dear gpac team:

I'm trying out a low latency dash setup with the built-in HTTP server file sink. I tried requesting a ongoing segment with `curl`. 
I noticed that even though the header did say `Transfer-Encoding: chunked`, and the transfer is indeed using chunked HTTP chunked transfer correctly, the timing of the chunks delivery is delayed.

I have observed the following when a GET request is made against a segment that is being produced.
1. Transfer the already written data immediately as the first chunk(s).
2. When the segment is fully complete, transfer the rest of chunks.

But according to the docs, it should rather be that a chunk is transferred as soon as received.

My setup to reproduce and demostrate the mentioned behavior:
- `gpac` version
```
gpac - GPAC command line filter engine - version 2.3-DEV-rev612-gcea3eeb7-master
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
```
- Command to generate the low latency dash
```
gpac -i video.mp4 reframer:rt=on @ -o http://localhost:8080/live.mpd:rdirs=outdir:segdur=10:cdur=1:reqlog=GET:dynamic:timeout=30
```
- Command to request the producing chunk
```
curl --trace-time --trace-ascii tracefile -o /dev/null http://localhost:8080/video-post_dash_track2_5.m4s
```
- Key traces
  -  A chunk was sent upfront while the rest of the chunks are all sent at once around 15:34:20
```
0000: GET /video-post_dash_track2_5.m4s HTTP/1.1
002c: Host: localhost:8080
0042: User-Agent: curl/7.88.1
005b: Accept: */*
0068: 
15:34:16.544927 <= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
15:34:16.544993 <= Recv header, 22 bytes (0x16)
0000: Server: GPAC 2.3-DEV
15:34:16.545003 <= Recv header, 37 bytes (0x25)
0000: Date: Thu, 26 Oct 2023 07:34:16 GMT
15:34:16.545012 <= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
15:34:16.545020 <= Recv header, 24 bytes (0x18)
0000: Keep-Alive: timeout=30
15:34:16.545031 <= Recv header, 28 bytes (0x1c)
0000: Transfer-Encoding: chunked
15:34:16.545040 <= Recv header, 2 bytes (0x2)
15:34:16.545045 <= Recv data, 9846 bytes (0x2676)
...
15:34:20.816489 <= Recv data, 10000 bytes (0x2710)
15:34:20.817787 <= Recv data, 30186 bytes (0x75ea)
15:34:20.821023 <= Recv data, 10000 bytes (0x2710)
15:34:20.822142 <= Recv data, 10000 bytes (0x2710)
15:34:20.823493 <= Recv data, 10000 bytes (0x2710)
15:34:20.824825 <= Recv data, 10000 bytes (0x2710)
15:34:20.826173 <= Recv data, 10000 bytes (0x2710)
15:34:20.827521 <= Recv data, 10000 bytes (0x2710)
15:34:20.828869 <= Recv data, 10000 bytes (0x2710)
15:34:20.835266 <= Recv data, 10000 bytes (0x2710)
15:34:20.841620 <= Recv data, 10000 bytes (0x2710)
15:34:20.842950 <= Recv data, 10000 bytes (0x2710)
15:34:20.844094 <= Recv data, 10000 bytes (0x2710)
15:34:20.845188 <= Recv data, 2842 bytes (0xb1a)
```
[Gist for full trace](https://gist.github.com/hiimdoublej-swag/a6b07798fa2baf06877a1225cec60df1)

I'll happily provide more information to clarify, or help test out some setups if needed, thanks.
--- end body ---
