MotionSpell / DVB-MABR-Tool

DVB MABR Open-Source Tool
0 stars 0 forks source link

unicast repair doesn't work #5

Open TuanTranBPK opened 1 month ago

TuanTranBPK commented 1 month ago

Configure GPAC multicast stream to deliver stream A (https://livesim2.dashif.org/livesim2/testpic_2s/Manifest.mpd) in multicast with small packet loss percentage (for example by adding ":errsim=0.3x50.0" in the "dst_filter_base" of app.py file). Configure GPAC multicast gateway to support unicast repair by setting "repair=full" and "repair_url = https://livesim2.dashif.org/livesim2/testpic_2s/" in config.ini

From the logs below, the GPAC multicast gateway detects the missing octets of segment and triggers unicast repair. However, when the player requests the segment, it gets 404. By checking the cache directory, the file size is still at the start of HTTP byte-range requests.

Logs from GPAC multicast server:

[DVB-FLUTE S0] Simulated error loss for LCT object TSI 20 TOI 29 service_name gpac.io:dvb-mabr:service:0 size 1428 (frag 39206 total 39206) offset 8568 (8568 in obj) [DVB-FLUTE S0] Simulated error loss for LCT object TSI 20 TOI 29 service_name gpac.io:dvb-mabr:service:0 size 1428 (frag 39206 total 39206) offset 9996 (9996 in obj) [DVB-FLUTE] Sending Bootstrap info [DVB-FLUTE] Mux rate 243 kbps [DVB-FLUTE] Sending Bootstrap info [DVB-FLUTE S0] Pushed A48/860687157.m4s (13283 bytes) in 1935527 us - target push 2000000 us [DVB-FLUTE S0] Sending Manifest Manifest.mpd [DVB-FLUTE S0] Sending init segment A48/init.mp4 [DVB-FLUTE S0] Pushed V300/860687157.m4s (39206 bytes) in 2001045 us - target push 2000000 us

Logs from GPAC multicast gateway:

[CACHE] Requesting deletion for http://gmcast/service1/https://livesim2.dashif.org/livesim2/testpic_2s/A48/860687157.m4s [HTTPIn] Switch from 860687157.m4s to 860687158.m4s [HTTPIn] Cannot resetup session from URL http://gmcast/service1/https://livesim2.dashif.org/livesim2/testpic_2s/A48/860687158.m4s: Requested URL is not valid or cannot be found [DASH] Error in downloading new segment: http://gmcast/service1/https://livesim2.dashif.org/livesim2/testpic_2s/A48/860687158.m4s Requested URL is not valid or cannot be found - starting countdown for 2000 ms (delay between retry 50 ms) [DASH] Set #1 At 7316 Next segment 860687158 (AST 1721374318047 - sec in period 1.72137e+09) should now be available on server since 57 ms - requesting it [DASH] Queuing next segment: 860687158.m4s

[HTTPIn] Switch from (null) to 860687158.m4s [DVB-FLUTE S1] Object TSI 20 TOI 29 partial received only [REPAIR] Repairing segment https://livesim2.dashif.org/livesim2/testpic_2s/V300/860687157.m4s - buffer status: 0 ms (0 for rebuffer 1 max buffer) [HTTP] Connecting to livesim2.dashif.org:443 for URL /livesim2/testpic_2s/V300/860687157.m4s [HTTP] Connected to livesim2.dashif.org:443 [SSL] Hostname livesim2.dashif.org matches livesim2.dashif.org [HTTP] Sending request at UTC 1721374318157 GET /livesim2/testpic_2s/V300/860687157.m4s HTTP/1.1 Host: livesim2.dashif.org User-Agent: GPAC/2.5-DEV-rev459-g457565ba1-master Accept: / Connection: Keep-Alive Range: bytes=8568-11423 Icy-Metadata: 1

[HTTP] HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type, Accept Access-Control-Allow-Methods: POST, GET, HEAD, OPTIONS Access-Control-Allow-Origin: Content-Length: 39206 Content-Type: video/mp4 Dash-If-Livesim2: v1.4.1, date: 2024-05-28 Livesim2-Requests: 3116 (max 10000) Timing-Allow-Origin: Date: Fri, 19 Jul 2024 07:31:58 GMT

Logs from directory where the cache is stored:

/tmp/gpac_cache/V300$ ll 860687157.m4s -rw-rw-r-- 1 user user 8568 Jul 19 07:31 860687157.m4s

touatily commented 1 month ago

The repair worked correctly, as evidenced by analyzing the logs.

Initially, there were two simulated network packet losses, each with a size of 1428 bytes:

First simulated error loss: [8568-9996[
Second simulated error loss: [9996-11424[

These consecutive losses created a single gap in the segment TSI 20 TOI 29.

Logs from the GPAC multicast gateway show that the full repair generated an HTTP request with Range: bytes=8568-11423, which matches the gap caused by the simulated losses.

The issue seems to be related to the HTTPIn filter switching the filename from 860687157.m4s to 860687158.m4s. The file is received as 860687157.m4s, as evidenced by the logs from the directory where the cache is stored. Additionally, the repair used the old URL before the filename switch: /livesim2/testpic_2s/V300/860687157.m4s

At this point, it's unclear what caused the filename switch or why it happened.

soheibthriber commented 2 weeks ago

Hello @TuanTranBPK @touatily I am going to port this issue to the main gpac issue stack. i am going to use elements from this discussion to create the issue. feel free to modify or comment in the issue page.

soheibthriber commented 2 weeks ago

https://github.com/gpac/gpac/issues/2943 link for the issue page