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

Robust handling of unescaped NAL units in byte stream #96

Closed
kqyang opened this issue Mar 21, 2016 · 0 comments
Closed

Robust handling of unescaped NAL units in byte stream #96

kqyang opened this issue Mar 21, 2016 · 0 comments
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request

Comments

@kqyang
Copy link
Contributor

kqyang commented Mar 21, 2016

We expect all NAL units having emulation prevention applied, i.e. sequence of 000001 should have been escaped, otherwise the NAL units cannot be extracted correctly. However, it is not always the case in field, e.g. #93.

We need more robust handling here. It is difficult and complicated to handle it perfectly. We will start with a simple algorithm and see how it goes.

Previously, whenever we see start codes 000001 we will start a new NAL unit. In the new algorithm, we will parse the NAL unit type, and only start a new NAL unit if it is a valid NAL unit type.

@kqyang kqyang added the type: enhancement New feature or request label Mar 21, 2016
@kqyang kqyang changed the title Robust handling of unescaped NAL units in transport stream Robust handling of unescaped NAL units in byte stream Mar 22, 2016
@kqyang kqyang closed this as completed in 0c46943 Mar 24, 2016
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 19, 2018
@shaka-project shaka-project locked and limited conversation to collaborators Apr 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants