-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
low-latency-short-buffer-playback test unclear duration observation #128
Comments
For what its worth, when running on a PC I often would often see QR codes flashing regularly, then one QR code would pause for a short period and then they would resume regular flashing. It often resulted in a duration problem or duration with missing frames if I remember correctly. I attributed it to software decode but it sounds similar to this and one or two other issues. I don't remember which tests it occurred on at this point since I tried a lot of different tests and combinations of tests. |
Thanks for the comment @gitwjr, when I run this on a PC browser I did not see waiting (pause) and resume. Also I have looked at reported recordings for all 8 devices from Plugfest, no longer duration is detected, it seems none of them went into waiting (pause). I suggest:
|
I checked my latest runs (4) from February 29th. These were using my Pixel 6a. The playbacks do not show an obvious pause. 2 failed for missing frames. 2 failed for duration I found several from January that show the pause but the OF was not recording the results back then so I don't have any matching results. These were run using the GoPro4. |
Thanks @gitwjr. I was looking for test result specifically for this low-latency-short-buffer-playback test. |
I found one test run that included low-latency-short-buffer-playback (using GoPro4 camera). Playback screen goes blank ~20 seconds into the playback for ~2 seconds then resumes. Although OF results were not recorded (remember that function was not working at the time) the results from TR were a pass for test workflow and video event ended fired. Test was run on 1/5/2024 using latest test suite as of that date. |
A proposal is implemented in Draft-CTA-5003-Ae-v2.05. |
Where can I find this draft please? The latest one from https://standards.cta.tech/wg/dpctf/document/33886, I cannot find the changes. |
https://standards.cta.tech/wg/dpctf/document/33886?downloadRevision=36523 CTA Causeway is missing one check-box compared to DVB and HbbTV for normal users, the ability to declare that a newly uploaded revision is the active one. The main download button always gives you the active version. To download a non-active version, you need to click on the date / time. |
All three best devices did not went into waiting status, and I don't have other recordings to check.
However, from reading the spec:
• Observe:
o If the video element transitions into playing state, cancel the timeout.
o If the timeout elapses before the video element has transitioned out of the waiting state, throw an error and terminate the test.
• In case the timeout resolves successfully: Append the rest of the CMAF chunks of CMAF track k.
Are we expecting to see "waiting" in playback and device would display a frame longer when "waiting" then transitions into playing state?
Also not clear what is meant by taking into account "The waiting_duration."?
○ Missing starting and ending frames.
○ Potential start frames being rendered before playback.
○ Frozen last frame after the playback ended.
○ The waiting_duration.
The text was updated successfully, but these errors were encountered: