Open
Conversation
Contributor
|
No comment about the results? |
Author
|
This doesn't convert any of the existing symbols to use arithmetic coding, so the only significant changes in results are due to the extra framing added in the first commit (see that commit for details). |
added 4 commits
November 1, 2015 12:46
This adds simple framing to the stream so that each frame may be parsed individually. This is done by just adding a 4-byte big-endian length field to the start of each frame and byte-aligning the end of each frame. The extra storage for this framing (4.5 bytes pre frame on average) is not included in the printed statistics, though it will show up on AWCY, which uses the actual file size.
This will trap when run in a debugger, allowing the developer to examine backtraces, etc., to determine the cause of the error.
The encoder would write, and the decoder would read, split flags for rectangular blocks on the edge of a frame in keyframes. The only way to not split such blocks is to skip them, which is not a choice available in keyframes. In an invalid stream, when the decoder would read a flag telling it not to split a rectangular block, it would immediately return without filling in the deblocking info for that block. This would cause FPE's in the deblocking code when attempting to compute j%q_size (with q_size uninitialized at 0). To prevent this, just don't write or read the useless bits.
Daala's entropy coder supports a "raw bits" mode which just writes bits directly, working backwards from the end of the stream. This should be essentially as fast as Thor's current bit writing and reading code. This patch replaces that code with Daala's, allowing future patches to use the non-raw entropy coder. This lets the existing code be converted a piece at a time. Unfortunately, because Thor uses VLCs and does not match the number of bits written at the encoder with the number of bits it attempts to read at the decoder, the order the bits are written to the stream matters. As a short-term solution, we currently bitreverse all bits before writing and bitreverse them again after reading, so that the relative order of bits remains the same. It would also be possible to modify the calling code to expect the bits to be in a different order without any of this overhead.
thdav
pushed a commit
that referenced
this pull request
Nov 4, 2015
Contributor
|
Merged except for the actual addition of the entropy coder. Please can you rebase on the current master again and I will push to a new branch. It might also be an idea to reverse the Daala convention, and write raw bits forward and arithmetic coding bytes backwards. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.