upipe_h265f: declare one access unit of latency, consistently - #1248
Open
kierank wants to merge 1 commit into
Open
upipe_h265f: declare one access unit of latency, consistently#1248kierank wants to merge 1 commit into
kierank wants to merge 1 commit into
Conversation
The framer's latency was declared differently at its two flow-def sites: the SPS-parse path declared duration*2 while the store_flow_def path declared duration - half a frame on progressive content, and that is the value a decoder downstream actually sees. Measured at the avcdec input on a 1080p59.94 stream: 0.5 frames. The framer's real latency is one ACCESS UNIT - it cannot output a picture until the next AU begins - i.e. one coded picture: a frame when progressive, a field under field_seq_flag. Introduce au_duration holding exactly that and declare input_latency + au_duration at both sites. Also fix the duration derivation it exposed: duration is kept in FIELD units for the pic_struct arithmetic in prepare_au, but the VUI clock tick is one coded picture - a field when field_seq_flag, a frame otherwise, unlike H.264 where it is always a field - so only the progressive case must halve. The previous unconditional halving made field-sequential durations half a field (and their pic_struct products wrong by 2x throughout).
kierank
marked this pull request as ready for review
September 4, 2026 15:58
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
1 participant
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.
The framer's latency was declared differently at its two flow-def sites: the SPS-parse path declared duration*2 while the store_flow_def path declared duration - half a frame on progressive content, and that is the value a decoder downstream actually sees. Measured at the avcdec input on a 1080p59.94 stream: 0.5 frames.
The framer's real latency is one ACCESS UNIT - it cannot output a picture until the next AU begins - i.e. one coded picture: a frame when progressive, a field under field_seq_flag. Introduce au_duration holding exactly that and declare input_latency + au_duration at both sites.
Also fix the duration derivation it exposed: duration is kept in FIELD units for the pic_struct arithmetic in prepare_au, but the VUI clock tick is one coded picture - a field when field_seq_flag, a frame otherwise, unlike H.264 where it is always a field - so only the progressive case must halve. The previous unconditional halving made field-sequential durations half a field (and their pic_struct products wrong by 2x throughout).