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

DASH output with CEA-608/708 suffers from decoding error (hardware acceleration enabled) #3502

Closed
wongfei2009 opened this issue Jul 2, 2021 · 8 comments
Labels
priority: P1 Big impact or workaround impractical; resolve before feature release status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@wongfei2009
Copy link

wongfei2009 commented Jul 2, 2021

Have you read the FAQ and checked for duplicate open issues?

Yes.

What version of Shaka Player are you using?

v3.1.1.

Can you reproduce the issue with our latest release version?

Yes.

Can you reproduce the issue with the latest code from master?

Yes.

Are you using the demo app or your own custom app?

Demo app.

If custom app, can you reproduce the issue using our demo app?

What browser and OS are you using?

Chrome Version 91.0.4472.114 (Official Build) (x86_64) and macOS 11.4.

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

What configuration are you using? What is the output of player.getConfiguration()?

What did you do?

Playback a DASH output with CEA-608/708.

What did you expect to happen?
Playback correctly, won't stop due to decode error.

What actually happened?

As soon as, a video segment with H264 emulation start sequence is parsed and then decode. There will be a pipeline decode error and playback stops.

Screenshot 2021-06-24 at 5 42 09 PM

@wongfei2009
Copy link
Author

The bug seems to be in sei_processor.js, which should not call removeEmu_ to modify the input buffer directly. Because the modified buffer with H264 emulation start sequence removed will not compliant to H264 syntax. That causes decoding error to hardware decoder (software decoder can tolerate it).

@TheModMaker
Copy link
Contributor

Can you provide a sample manifest URL? It works fine for me with the CEA asset on our demo page.

@wongfei2009
Copy link
Author

It is because your CEA asset in demo page doesn't actually have any H264 emulation bytes to remove :) i.e. removeEmu_(naluData) always return 0 in your demo asset. I have an asset can hit the issue in 100% manner, but I don't have the content right to share. How can I share the URL with you in private?

@joeyparrish
Copy link
Member

Anything you share with [email protected] will not be shared outside the team. Please reference the issue number in your email to make it easy to find, and then reply here so we know to look for it. Thanks!

@joeyparrish joeyparrish added type: bug Something isn't working correctly status: waiting on response Waiting on a response from the reporter(s) of the issue priority: P1 Big impact or workaround impractical; resolve before feature release and removed needs triage labels Jul 7, 2021
@joeyparrish joeyparrish added this to the v3.2 milestone Jul 7, 2021
@joeyparrish
Copy link
Member

@wongfei2009, without content to test, we won't be able to work on this issue right now. Although this is a high priority issue, I'm going to have to bump this to the v3.3 milestone. Please let us know when you can share the content privately, so that we can verify the fix and create a regression test. Thanks!

@joeyparrish joeyparrish modified the milestones: v3.2, v3.3 Jul 9, 2021
@joeyparrish joeyparrish removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Jul 9, 2021
@wongfei2009
Copy link
Author

Asset able to trigger this issue has been shared via [email protected].

Thank for the attention.

@avelad
Copy link
Member

avelad commented Aug 31, 2021

I think the PR #3610 fixes this! (@enson-choy)

@wongfei2009
Copy link
Author

wongfei2009 commented Sep 13, 2021 via email

joeyparrish pushed a commit that referenced this issue Oct 12, 2021
When unboxing TKHD, the reader read int64 as trackId instead of int32. Thus unable to find matching timescale when doing TFHD unboxing. Therefore when parsing MDAT, the default timescale will be used which is 90000. All CC timestamps will then be incorrect.

This also fixes "Shaka Error MEDIA.VIDEO_ERROR (3,,PIPELINE_ERROR_DECODE: Failed to parse H.264 stream)" error when playing DASH MP4 H.264 streams with CEA-608 CC embedded.  It's likely that the VDA bundled in Chromium-based browsers have already included EPB detection & prevention. If we let the player to remove the byte, VDA will complain about stream conformance.

Closes #3502
joeyparrish pushed a commit that referenced this issue Oct 12, 2021
When unboxing TKHD, the reader read int64 as trackId instead of int32. Thus unable to find matching timescale when doing TFHD unboxing. Therefore when parsing MDAT, the default timescale will be used which is 90000. All CC timestamps will then be incorrect.

This also fixes "Shaka Error MEDIA.VIDEO_ERROR (3,,PIPELINE_ERROR_DECODE: Failed to parse H.264 stream)" error when playing DASH MP4 H.264 streams with CEA-608 CC embedded.  It's likely that the VDA bundled in Chromium-based browsers have already included EPB detection & prevention. If we let the player to remove the byte, VDA will complain about stream conformance.

Closes #3502
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Nov 8, 2021
@shaka-project shaka-project locked and limited conversation to collaborators Nov 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority: P1 Big impact or workaround impractical; resolve before feature release status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

5 participants