touatily
commented
1 day ago This behavior is expected because the server for stream A does not support partial repair using HTTP Byte range requests. GPAC detects this and blacklists the server, preventing it from being used for partial repairs, as the server responds with the entire DASH segment instead of the requested byte range.
A warning message has been added to inform that the server has been blacklisted in gpac/gpac#3002 ([REPAIR] Server "https://livesim2.dashif.org/livesim2/testpic_2s/" does not support byte range requests: Server is blacklisted for partial repair). Starting from the second repair attempt, GPAC does not find any valid server for partial repair, which is why the error message [REPAIR] Failed to find an adequate repair server - Repair abort is displayed, and the repair process is aborted.
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 config.ini 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
The configuration files for both gateway and server are found in the attached log.
From time to time, the segment isn't correctly repaired (see attached logs on 2 diffrent tests)
Other remark, there is message error "[REPAIR] Failed to find an adequate repair server - Repair abort" in both cases where the segment is correctly and incorrectly repaired. I'm not sure what does it mean unicast-repair.zip