Warn on unsupported video

[jprochazk]

When a user loads a video which we can't load for some reason (failed to load, unsupported container format, unsupported codec, etc.), we should report that to them in some way other than a short-lived warning notification.

Some error cases are:

• Firefox doesn't support WebCodecs outside of Nightly
• Safari doesn't support AV1
• Unsupported video container format
• Unsupported video codec (inside the container)
• Container parse error
• Codec configuration error
• Decode error (WebCodecs)

[gavrelina]

A ui/ux proposal!

• highlight the component in the stream that causes an error to improve its discoverability
• in the error copy itself mention explicitly what's wrong and why and how users can recover from it (i.e. linking to github issue to follow or docs)
• visually display smth explicitly "broken" instead of the video in the Viewer, like this:

[Wumpf]

👍 makes sense, thank you so much for chiming in here!

A few thoughts: I think the error text needs to show both when the specific components (like the blob here) is clicked, as well as when the entity containing the broken video is selected. Mostly because it's much more common to click on an entity.

On the streams panel having only components highlight in the error color is probably enough though (and liiikely also too hard otherwise)

As we progress on this we might want to have different error icons and error handling (the loose list in the ticket description will need some structuring), but I'd say for now we should not make much fuss about it.

@gavrelina does this make sense?

[gavrelina]

@Wumpf makes a lot of sense!

About the entity msg => it would also then be visible if users click on it via the blueprint, right? that would also largly increase the discoverability! I do worry (slightly) that copying it in few places comes across as "omg! so many errors everywhere, panic!", hence my initial idea was to only show at Blob level and highlight Blob in red so that users would go there to find it. so kinda direct them with color nudging :) what do you think?

And moving forward from here it still makes sense to revise (revive?) the different gradations and make this thing work : https://github.com/rerun-io/rerun/issues/4304

[jprochazk]

From: https://github.com/rerun-io/rerun/pull/7398#discussion_r1753388072

I don't know if you've experienced this scenario: You're playing a video on the web, and it suddenly fails with an error of some kind. The player just stops, and the controls become inactive, so you can't seek to a different point in the video anymore. But then you reload the page, and seek after the point where the player previously stopped with an error, and the video continues playing back just fine.

I think we could do a lot better than web video players here, by always allowing seek even in the case of an error, and more importantly also highlight which segments are broken on the timeline, so the user knows exactly where to seek next to try and catch a part of the video which can be played back.

This kind of behavior would definitely follow our "handle anything the user throws at it" philosophy

[gavrelina]

@jprochazk I can already picture how we mark some specific events/part on the timeline where one encounters an "error"!