This message was deleted.
# cloud
s
This message was deleted.
m
cc @chilly-animal-65189
c
This means that the HTTP server either reported that it doesn't accept range requests, or returned a Chunked-Encoded response for a file that gstreamer needs to be able to seek into to read properly. Hard to tell more without knowing more about the server or the file.
r
@chilly-animal-65189 This is the nginx config of my server from which the file can be downloaded and being sent to livekit ingress -
Copy code
# Disable request and response buffering for tusd
        proxy_request_buffering     off;
        proxy_buffering             off;
        client_max_body_size        0;
        chunked_transfer_encoding   off;

        # SSE related configurations
        proxy_connect_timeout       5h;
        proxy_read_timeout          5h;
        proxy_cache                 off;

        proxy_http_version          1.1;
        proxy_set_header            Upgrade $http_upgrade;
        proxy_set_header            Connection "";

        # Add X-Forwarded-* headers
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-Host     $host;
        proxy_set_header   X-Forwarded-Proto    $scheme;

        # Accept range requests
        proxy_force_ranges on;
And this is the file Codec information -
Copy code
H264 - MPEG-4 AVC (part 10) (avc1)
This issue is not happening to every mp4 file being sent to ingress
c
Something in the response structure is preventing gstreamer from doing the piece wise reads it needs to to handle these MP4s. Looking at the actual HTTP traffic may give a hint.
Do the failing MP4 have their MOOV atom a the end of the file? Are they larger than the succeeding ones?
r
@chilly-animal-65189 how to find out this information from a video file?
After enabling the range requests support in nginx, I'm not getting this "Server does not support seeking" in dashboard, It is showing as publishing there
but when I check the ingress status, It's showing weird stuff there, BUFFERING on the 1st time & ENDPOINT_INACTIVE in 2nd. The stream is not running for this file.
Furthermore, the file is a screen recorded file if this helps at all.
c
MP4 files may be tricky to stream directly from HTTP. Gstreamer may have difficulties with this specific file. I can have a look at the logs if you give me the ingress ID. Otherwise, a sample file may help.
r
@chilly-animal-65189 This is the latest ingress ID - IN_eZPdzuPNuz35
One more thing, after every stream ends or in case of force close, I delete the ingress from backend using this code -
Copy code
client.ListIngress(ctx, &livekit.ListIngressRequest{RoomName: roomName})
but in the livekit dashboard, it still shows up with status buffering or publishing. If I try to list ingresses via the ListIngress() method, it returns blank as expected.
c
@acoustic-engineer-41666 Would you happen to know what we use as datasource for the ingress dashboard? ^
wrt IN_eZPdzuPNuz35, do you have the exact status/error code that was returned by ingress? I do not have access to it anymore since it was deleted
Getting a small sample file would really help too
Actually, for IN_eZPdzuPNuz35, it looks like it was deleted using an API call 600ms after it started: CREATE came at 132801. Ingress started sending media to the room at 132806:063, and the DELETE call came at 132806:698
r
@chilly-animal-65189 In my server, I've set as end the stream and update my server side data if ingress status is not PUBLISHING. So, the status of this ingress should be either BUFFERING or ENDPOINT_INACTIVE.
This is the file failing, its a screen recorded file in mp4. Other screen recorded files are also failing.
nvm the issue is solved. For this video file, I added range-requests in my nginx and during the stream ingress status was not PUBLISHING, for which I previously set as stream ended in my server.
Thanks for the help @chilly-animal-65189
👍 1