The boolean tracking appears to be something like an asset state machine / tracking running in the virtual player. Manually seeking the video tag is likely an unexpected change triggering an exceptional transition in the logic.
The thing to keep in mind here is that the seeking timeline of a video tag element does not need to represent the actual media timeline when you are using MSE. It can represent any time the virtual player running in JavaScript wants to maintain and is usually more related to the buffer timeline and ensuring pts continuity across segment appends. Netflix has historically had relatively simple streams which may have allowed this to be the actual seek time, but looks like some deeper streaming changes are landing. For a more complicated example take a look at how multi-asset vod and live streams in a single video tag surface times.
I don't work for Netflix, but do work in the field and since it's relatively small know some of the folks over at Netflix. They definitely aren't out to break things purposely, it's more likely not a case they exercise and broken by a change like someone else has said. If you want to patch the functionality it may be worth exploring the dispatch of mouse clicks on the seek bar. That probably does a translate to time and then calls the virtual player seek API which would be the new hook point you want.
Yeah, I have a feeling it was due to optimizations deeper in the stack, I'm just deeply unhappy that what essentially should be an interoperable API via the <video> element was locked down in such a spectacular fashion.
The edge cases of varying video providers has been really eye opening when i've been doing this project, it hard to imagine how screenreader software (or any meta-software that makes it easier for the disabled) works at all.
The DASH-IF group just finished a work item with the FFMPEG maintainers to build in all the functionality necessary for low latency DASH streaming. The parameters necessary have been documented in the standing "Low Latency Modes for DASH" CR: https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf
Section 9.X.6.3.6 Example: FFmpeg Configuration will give you a full sample command.
Java has two strong points, its a great example of OOP and it forces you to understand types. I find that if students don't learn these things early on they will never get around to learning it, then when they get to C or Python where types are more of a suggestion, they have a really hard time with it. Java is stricter and harder to learn I agree, but the fact that it makes you understand OOP and types just to use it properly makes you a far better programmer in my opinion. I think Java should definitely be used as a starter language.
If understanding types is so important, then why not go all the way and use either ML or Haskell, or at least Scala?
Most freshmen who stumble through a Java-school curriculum will not understand types at all, and based on confusion among a number of colleagues just yesterday (all Java programmers) about what a "sum type" is, it's clear to me that Java doesn't encourage developing a rigorous understanding of types, even for professional programmers.
Too, it's not a very interesting demonstration of OOP. Smalltalk or Ruby would be a more useful tool to use to teach OOP, iff teaching OOP is actually a goal.
Correct the %r8 - %r15 registers were added by the x86_64 architecture and are 64-bit in length just as the others are now. They are commonly used for passing arguments to functions.
Actually a fair number of shipments by small companies and even Fedex have shipment numbers that total out to 10 or 11 digits which fits a fully dialed international number perfectly and will be highlighted by Android. So the feature is bad and good at the same time.
Source: I made and maintain a shipment tracking progam on Android.
