Invalid frames using videos at 29.97fps and Smooth Streaming

[jafs]

Environment

NOTE: Is not a MPD. To reproduce this bug, we use a Manifest that uses SmoothStreaming.

• [] The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• [v] The stream has correct Access-Control-Allow-Origin headers (CORS)
• [v] There are no network errors such as 404s in the browser console when trying to play the stream
• [v] The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• [v] The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page

NOTE: be careful with spaces in URL.

• Link to playable MPD file: "https://dashtest-usea.streaming.media.azure.net/32862eb6-4344-4c05-81cd-b349a11f8b0a/SD NTSC (720x480) 29,97fps (4 au.ism/manifest"
• Dash.js version: 4.4.0
• Browser name/version: Firefox 94.0.1
• OS name/version: Windows 10 20H2

Steps to reproduce

1. This problem was seem in our internal development environment, but can be reproduced easily in Dash Reference Client. So open the page: http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html
2. Use the URL provided in Link to MPD file (remember that this link is for SmoothStreaming).
3. Set the current time of video to 34ms (second frame).
4. If you test with another SmoothStreaming videos that uses 29.97fps, you can see how the erroneous behavior is repeated.

Observed behavior

When in the HTML video element, we set the current time to 34ms. Frame 0 is still displayed in the video.

Console output

NOTE: We store in temp0 variable, the HTML video tag element.

temp0.currentTime = 0.034

[735888][PlaybackController] Seeking to: 0.034 [Debug.js:169:25](webpack://dashjs/src/core/Debug.js)
0.034
[735897][ScheduleController][audio] [audio] lastInitializedRepresentationInfo changed to 0 Debug.js:169:25
[735921][StreamProcessor][audio] OnFragmentLoadingCompleted for stream id defaultId_0 and media type audio - Url: https://dashtest-usea.streaming.media.azure.net/32862eb6-434…alityLevels(127999)/Fragments(aac_eng_2_127999_2_1=280746666)  [Debug.js:169:25](webpack://dashjs/src/core/Debug.js)
[735947][StreamProcessor][audio] OnFragmentLoadingCompleted for stream id defaultId_0 and media type audio - Url: https://dashtest-usea.streaming.media.azure.net/32862eb6-434…alityLevels(127999)/Fragments(aac_eng_2_127999_2_1=300800000)  Debug.js:169:25
[735996][PlaybackController] Native video element event: seeked [Debug.js:169:25](webpack://dashjs/src/core/Debug.js)

Expected behavior

With same video but using hasplayer.js, we can see the second frame of video, when we go to 34ms.

Also, second frame is shown when we use the same URL of resource but using MPD: "https://dashtest-usea.streaming.media.azure.net/32862eb6-4344-4c05-81cd-b349a11f8b0a/SD NTSC (720x480) 29,97fps (4 au.ism/manifest(format=mpd-time-cmaf)".

[dsilhavy]

Can you please check the url to the manifest you provided, getting a 404

[jafs]

Hello, another URL version with encoded spaces in URL:

https://dashtest-usea.streaming.media.azure.net/32862eb6-4344-4c05-81cd-b349a11f8b0a/SD%20NTSC%20(720x480)%2029,97fps%20(4%20au.ism/manifest

If you need the proxy files generated in this test, you can find at this 7z: https://drive.google.com/file/d/1fr75twJmp9c6zwn4fUGqUsIWo_wW8ziL/view?usp=sharing

Regards

[bbert]

@jafs looking at your streams, MSS content differs from the DASH content If you look at trun tables from your video fragments, you will get:

• for DASH segment:

• for MSS segment:

Therefore, MSS content will start at tfdt=0 + 1st sample CTS offset, i.e. at 0.0667333 While DASH content will start tfdt=0 + 1st sample CTS offset, i.e. at 0.

That's why when you seek at timestamp 0, dash.js will seek at 0.0667333

[jafs]

Hi bbert, very thanks for the answer.

In our environment, we don't use Dash manifest (we don't use azure, but I upload the file to Azure to make public the info), only the MSS.

For better example, I upload a real generated proxy in our environment to:

https://drive.google.com/file/d/11A15oBmb4-EYD7p27BYKJrg8RZsCfrir/view?usp=sharing

If I play the media with the ancestor of Dash.js, the library: https://github.com/Orange-OpenSource/hasplayer.js/, the offset frame problem is not present...

So, I think there is a diferent treatment of the Manifest in the two libraries, because HasPlayer has not the problem of offset.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. However, it might still be relevant so please leave a short comment if it should remain open. Otherwise the issue will be closed automatically after two weeks. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it or contact @dsilhavy. Thank you for your contributions.