Bug(v0.0.0.2): .webm video play crash on linux

[lidel]

When I try to play ipfs://bafybeieb33pqideyl5ncd33kho622thym5rqv6sujrmelcuhkjlf2hdpu4/Big%20Buck%20Bunny.webm the browser hangs, does not react to any UI input nor does redraw.

Playing the same video from https://dweb.link/ipfs/bafybeieb33pqideyl5ncd33kho622thym5rqv6sujrmelcuhkjlf2hdpu4/Big%20Buck%20Bunny.webm works ok.

I tested prebuilt v0.0.0.2 for Linux (RPM) (rpm2tar chromium-browser-unstable-113.0.5672.126-1.x86_64.rpm)

[John-LittleBearLabs]

It "worked" for me. I entered the URL, left, came back and it showed the loading thing turning, did some other work for a while, and eventually sound started coming out. I switched back and indeed the video was playing.

I wonder if this is less of a crash and more like unacceptably terrible performance.

[whizzzkid]

It crashed on my m1 mac, never saw what's in the video.

[John-LittleBearLabs]

So I'm not sure I'm investigating the same issue you have both seen, because it's never crashed for me. It froze and my desktop environment (GNOME) complained about it being unresponsive and prompted me for whether I'd like to wait or "Force Quit", but if I let it sit for an insanely long time it'll eventually work. In a release build that seems to be somewhere in the neighborhood of 5-10 minutes, in a debug build 1-2 hours.

I was assuming this was a problem with the number of round trips on the network (several hundred modestly-sized requests instead of 1 large one from dweb.link). Shockingly, that's not where the overwhelming majority of the time is going. The headers that are being placed in there for debugging in devtools, each one takes longer than the previous one to be added to the metadata, and it gets to completely absurd levels because in this setup there's a separate few headers for each CID in the DAG that was resolved in the process of dealing with this URL. In this case that's: 1 for the directory at the root CID bafybeieb33pqideyl5ncd33kho622thym5rqv6sujrmelcuhkjlf2hdpu4 1 for the root of the file (linked to by the directory) QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T 4 for the top-level links of that file (Qmefro9w9tV2RNcqvEEWpeQh4puYfBRhG6pUe3UfquL8uU...) 813 links from those 4 (QmbHVkhGs8dTgdSvBsjc73TqKQoiLLQb3eqiqdXrykqD3J...)

I watched until those headers were taking 3 seconds a piece, which is insane, but it was still getting worse.

I tried an experiment of limiting the number of "Server-Timing", "Block-Source", and "ZZZ-" headers to those dealing with the first 9 CIDs max. Then the release build loads the video and starts playing it in 2-3 seconds.

Do y'all think it's OK to just "solve" it like that, or should I do something different like track the total count of CIDs and include something like "+ 810 more CIDs"?

[lidel]

@John-LittleBearLabs as discussed on call today, let's remove DoS vector and stop setting these debug-level headers for every block, make the headers cumulative.

Would below be possible?

• have one server timing entry with time til the root block Server-Timing: ipfs-ttfb;desc="time til the first block was fetched from {gateway-host}";dur=1463.2
• have one another entry per gateway hostname, with total time spent making requests to each (for all blocks, cumulative per gateway): Server-Timing: {gateway-host};desc="time spent fetching N blocks (Y bytes in size) from {gateway-host}";dur=4200
• if possible, have a single header, with stats Ipfs-Block-Sources: {gateway-host};blocks=2;bytes=4563,{other-gateway-host};blocks=1;bytes=42
  • :thought_balloon: we may skip this if Server-Timing one already includes block count and total bytes

Together, these will allow pretty good visibility into performance across gateways, one will be able to spot underperforming one, but without going into full debug mode.

[John-LittleBearLabs]

I do fear people will look at these sums of timings and think they happened sequentially. The issue with that can be clearly seen in this screenshot.

The total time is 21 seconds, yet 4.4 minutes was spent fetching 88 blocks from that one gateway. Because, naturally, multiple requests were sent to that gateway in parallel.

[lidel]

@John-LittleBearLabs Ack, this looks pretty confusing, especially with the info is cut by devtools anyway.

Maybe just keep "til the first block" in Server-Timing (and rename it to shorter first block from {gateway-host}) and move totals out?

To make it easier to eyebald, would it be possible to add one Ipfs-Block-Sources per gateway?

# Ipfs-Block-Sources: {gateway-host-a}`;blocks={count};bytes={bytes};cdur={ms-cummulative}
Ipfs-Block-Sources: {gateway-host-a};blocks=2;bytes=4563;dur=10340
Ipfs-Block-Sources: {gateway-host-b};blocks=1;bytes=42;dur=1053

[John-LittleBearLabs]

Seems somewhat workable to me for now. There's a bunch of devtools enhancements slated for phase 2.