Very good catch, I thought I remember a magic number for "infinity" length, but I ended up not using it.

-9223372036854775807 is kinda an unfortunate value in JavaScript, because it's much smaller than JS' Number.MIN_SAFE_INTEGER (-9007199254740991).

Anyway, I tested it in Safari 13 on an iPhone simulator (which is the latest modern browser without BigInt support), and it is still a ridiculously small number (even though there's some wrapping):

let magic = -9223372036854775807
->          -9223372036854776000

Close! And since we're not doing math with the value (only using it as a boundary), it's probably fine. I'll return the magic value instead, matching the other platforms (yikes!)

Son of a...

../lib/src/video_player.dart:39:18: Error: The integer literal 9223372036854775807 can't be represented exactly in JavaScript.
Try changing the literal to something that can be represented in Javascript. In Javascript 9223372036854775808 is the nearest value that can be
represented exactly.
  milliseconds: -9223372036854775807,
                 ^^^^^^^^^^^^^^^^^^^

Dart nagged about me using -9223372036854775807 as a value, and asked me to use -9223372036854775808 which kind of defeat the purpose of having a "magic number" that is different across platforms :/

Anyway PTAL @stuartmorgan, other than standardizing the "live" duration across the whole plugin, it seems we're running out of options here :)

It seems like the next best option is to decide on our own standard and have web be the first to adopt it, and then we can do a breaking change at some later point to move the other platforms over to it.

Your point about a threshold is a good one. Maybe we should just make -1 be our new target standard for representing this at the platform interface layer? I assume there are no legitimate cases of negative durations.

Maybe we should just make -1 be our new target standard for representing this at the platform interface layer? I assume there are no legitimate cases of negative durations.

I thought about -1 as well, but then decided to do a blame on the current value of TIME_UNSET to understand why exoplayer had settled in such a "wacky" value (other than maybe matching androidx.media2.common.SessionPlayer.UNKNOWN_TIME). From their commit message:

- Use a single constant for unset/unknown times across
  all time bases. Note also that this moves away from
  use of -1 for unset/unknown times in ms, which was a
  bad choice (it might conflict with real times, such
  as a time representing being just behind the start
  of a live window).

If we follow the same trick that ExoPlayer2 used to come up with their value, but that works fine in JavaScript:

JS_COMPATIBLE_TIME_UNSET = Number.MIN_SAFE_INTEGER + 1; // -9007199254740990

The number is several orders of magnitude larger than the current one, but if when converted from milliseconds to years it is still over 285000 (sounds long enough for any pre-roll!)

It seems like the next best option is to decide on our own standard and have web be the first to adopt it, and then we can do a breaking change at some later point to move the other platforms over to it.

I'll use that, and create an issue to standardize the value across the different implementations, and the flutter-provided UX and logic of our Player (which seems to always assume that the duration of a video is always finite!)