StreamingEngine test failures on Tizen #4806
Comments
joeyparrish
added
type: code health
|
I see that there is a 150 ms gap in audio, and that gap jumping is ineffective for some reason. I was trying to figure out why there would be a 150ms gap, and I'm not sure at all. Each "frame" of audio is 1024 samples at 48kHZ, and the segment has 469 frames containing a total of 480256 samples for a duration of 10.005333... seconds. The metadata in our tests lists the audio segment's length at 10.005 seconds even. The video segment is exactly 10 seconds long. Based on the above data, I tried three ways to address this in the tests:
I think a solution that makes playback more robust both inside and outside of tests would probably be the best option, since gaps can and do happen in real life and the player is meant to survive them. But jumping 1ms farther didn't work. In fact, video.currentTime after the jump was still 300.150, even though it should have been 300.151. Jumping 2ms farther also had no effect. Jumping 5ms farther got us to 300.155 as it should, but playback was still stuck at that point. If there is some way to fix this at the level of gap-jumping, I'll do that. Otherwise, I'll fall back to removing the gap from the tests. |
|
In all cases, when playback is stuck, readyState is "2", which doesn't seem right given the buffered ranges. The gap-jumping change doesn't seem to be viable:
If we have to seek that far ahead of the gap to make this scenario work on Tizen, I don't think we'll be able to do that in production. |
For some unknown reason, using precise durations for these audio segments on Tizen creates gaps that can't be survived. I don't know why that creates a 150ms gap, and I don't know why we can't seem to jump over it. It feels very much like a bug in Tizen itself. Experimentally, I found that rounding these durations to 10s even removes the gap completely. I tried many other things, but this is the only reasonable thing I have found that works. More details on my investigations can be found in the issue on GitHub. Closes shaka-project#4806
For some unknown reason, using precise durations for these audio segments on Tizen creates gaps that can't be survived. I don't know why that creates a 150ms gap, and I don't know why we can't seem to jump over it. It feels very much like a bug in Tizen itself. Experimentally, I found that rounding these durations to 10s even removes the gap completely. I tried many other things, but this is the only reasonable thing I have found that works. More details on my investigations can be found in the issue on GitHub. This change in durations exposed some brittle tests in Player which had to be adjusted to be more robust. Closes #4806
For some unknown reason, using precise durations for these audio segments on Tizen creates gaps that can't be survived. I don't know why that creates a 150ms gap, and I don't know why we can't seem to jump over it. It feels very much like a bug in Tizen itself. Experimentally, I found that rounding these durations to 10s even removes the gap completely. I tried many other things, but this is the only reasonable thing I have found that works. More details on my investigations can be found in the issue on GitHub. This change in durations exposed some brittle tests in Player which had to be adjusted to be more robust. Closes #4806
For some unknown reason, using precise durations for these audio segments on Tizen creates gaps that can't be survived. I don't know why that creates a 150ms gap, and I don't know why we can't seem to jump over it. It feels very much like a bug in Tizen itself. Experimentally, I found that rounding these durations to 10s even removes the gap completely. I tried many other things, but this is the only reasonable thing I have found that works. More details on my investigations can be found in the issue on GitHub. This change in durations exposed some brittle tests in Player which had to be adjusted to be more robust. Closes #4806
For some unknown reason, using precise durations for these audio segments on Tizen creates gaps that can't be survived. I don't know why that creates a 150ms gap, and I don't know why we can't seem to jump over it. It feels very much like a bug in Tizen itself. Experimentally, I found that rounding these durations to 10s even removes the gap completely. I tried many other things, but this is the only reasonable thing I have found that works. More details on my investigations can be found in the issue on GitHub. This change in durations exposed some brittle tests in Player which had to be adjusted to be more robust. Closes #4806
For some unknown reason, using precise durations for these audio segments on Tizen creates gaps that can't be survived. I don't know why that creates a 150ms gap, and I don't know why we can't seem to jump over it. It feels very much like a bug in Tizen itself. Experimentally, I found that rounding these durations to 10s even removes the gap completely. I tried many other things, but this is the only reasonable thing I have found that works. More details on my investigations can be found in the issue on GitHub. This change in durations exposed some brittle tests in Player which had to be adjusted to be more robust. Closes shaka-project#4806
github-actions
bot
added
the
status: archived
These tests have been failing on Tizen since we re-enabled that platform in the lab 23 days ago:
Lab runs in general have been so flaky that I overlooked this until now. But this is consistent, and all 4 maintained branches are behaving this way with the same tests. (v3.2, v3.3, v4.2, v4.3)
The text was updated successfully, but these errors were encountered: