All audio and video are "non streaming" (afb423, e7aa44, 2eb176, eac66b, c5a4ea, ab4d13, 1ea59c, f51b46, f196ce, c3232f, fd26cf, d7ba54, ac7dc6, ee13b5, 1ec09b, 1a02b0)

[Jym77]

Our definition of non-streaming is

A non-streaming media element is an HTML Media Element for which the duration property is not 0.

However, the HTML specs for duration states:

If the media resource is not known to be bounded (e.g. streaming radio, or a live event with no announced end time), then the attribute must return the positive Infinity value.

Therefore, the duration is never 0 (actually, it might be for an empty media), and according to our definition, every media element is "non streaming"…

I am afraid that changing to "duration is not positive infinity" is not good enough because I understand that streams may have a non-infinite duration (e.g. live event with an announced end time). And it is bad if we qualify an actual streaming event as "non-streaming" because that makes it applicable for all the rules requiring captions or transcript and breaks the fail-on-fail relationship.

[carlosapaduarte]

Thinking about how to address this:

• the SCs apply to pre-recorded media, and define that as non live media
• (technically) streaming is different from live media, i.e. we can stream media that has been pre-recorded

So, I don't think we should use "non-streaming" in these rules. But, I'm not sure we can come up with a working objective definition of "live" 😕 We could say that the media resource is available in its entirety prior to the media player starts its playback. That is objective. But how can we test this? Any ideas?

[Jym77]

Good points… "Available prior to start playing" feels like it's never going to be the case. Because indeed, most video platforms these days effectively stream or in any case start playing asap while downloading still happens (and stop downloading if playing stops), so unless we manage to say "available on the server" (which is even less testable…) that's bad (rule would be OK as a rule but if it never applies…)

What about adding to the composition: rule(s) applies to all videos and we add another atomic "video is non-live". Then we only need an unambiguous definition, but it can be subjective. And live video pass the rule by passing the new atomic while non-live video have to pass one of the old atomic rules…

We might add "known duration" to the applicability. That will not catch all live video, but still some. And thus makes the rule a bit more focused.

[carlosapaduarte]

I meant "available on the server", otherwise it would be testable, but not really useful, as you point out. While "available on its entirety on the server" is objective, we are never going to be able to test it...

I'm not sure I understood your suggestion. Let me rephrase it to check if I got it:

• we remove the non-streaming part from the applicability of all rules
• we add an atomic rule to the composites, and the atomic passes if the video is a live video
• in this atomic we just need to come up with a testable definition of "live" to use in the expectation, which means it doesn't have to be objective, therefore might be easier to write

You said the atomic would be "video is non-live", which is why I'm confused 🙃

[Jym77]

😅 Yep, "video is live" is how it passes…

[carlosapaduarte]

I run into an unanticipated problem... Any good suggestions for a live stream to use in the passed examples of the new atomic rule?

[carlosapaduarte]

And you can have a look at #1661 to check my attempt at the "* is live" expectation. But I'm still without a clue about the resources for a passed example... unless the W3C has a live cam that I'm not aware of...