Skip to content
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

Invalid frames using videos at 29.97fps and Smooth Streaming #3933

Closed
jafs opened this issue Apr 27, 2022 · 6 comments
Closed

Invalid frames using videos at 29.97fps and Smooth Streaming #3933

jafs opened this issue Apr 27, 2022 · 6 comments
Labels
Bug stale To be used by automatic issue staling and closing to indicate that this issue is about to be closed

Comments

@jafs
Copy link

jafs commented Apr 27, 2022

Environment

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

NOTE: be careful with spaces in URL.

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)".

@jafs jafs added the Bug label Apr 27, 2022
@dsilhavy
Copy link
Collaborator

dsilhavy commented May 3, 2022

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

@jafs
Copy link
Author

jafs commented May 5, 2022

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
Copy link
Contributor

bbert commented May 13, 2022

@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:
    image

  • for MSS segment:
    image

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
Copy link
Author

jafs commented May 16, 2022

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
Copy link

stale bot commented Oct 14, 2022

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 stale bot added the stale To be used by automatic issue staling and closing to indicate that this issue is about to be closed label Oct 14, 2022
@stale
Copy link

stale bot commented Oct 28, 2022

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.

@stale stale bot closed this as completed Oct 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug stale To be used by automatic issue staling and closing to indicate that this issue is about to be closed
Projects
None yet
Development

No branches or pull requests

3 participants