Conversation
H264Packet appended every FU-A fragment to its buffer, even when the fragment with the S bit had never been seen. When the E bit arrived it emitted the tail of the NAL unit behind a synthesized header, which decoders reject (for example an IDR slice with no slice header). Follow RFC 6184 section 5.8, as the H265 depacketizer already does: reset the buffer on an S fragment, drop fragments that arrive with no start, and discard a pending NAL unit when a single NAL or STAP-A packet shows that its end was lost. Fixes pion#370
Thank you :) |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #372 +/- ##
==========================================
+ Coverage 87.45% 87.47% +0.01%
==========================================
Files 28 28
Lines 3173 3177 +4
==========================================
+ Hits 2775 2779 +4
Misses 398 398
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
JoTurk
left a comment
JoTurk
left a comment
There was a problem hiding this comment.
change is minimal and does look good to me and seem to follow the spec, we should merge this after we add media tests to https://github.com/pion/browser-tests should do it this weekend.
Thank you.
Signed-off-by: phatlc <phatle.hsd@gmail.com>
|
@JoTurk I merged current I also noticed that the e2e media SRTP test in pion/browser-tests#111 has landed since your review. Does that cover the media validation you wanted for this change, or is there a separate H264 check still needed? |
2 participants
H264Packet appended every FU-A fragment to its buffer even when the
fragment carrying the S bit was never received, then emitted the tail
of the NAL unit behind a synthesized header once the E bit arrived.
Following RFC 6184 section 5.8 (and matching the H265 depacketizer):
must be sent back to back
Orphan fragments return an empty payload rather than an error, so
callers that stop on errors (h264writer, save-to-disk) keep running
after a mid-keyframe join or a lost start packet. If you'd rather
surface errExpectFragmentationStartUnit like H265 does, it is a one-line
change.
Fixes #370
AI disclosure: I used AI assistants (Claude, OpenAI models) while writing
and reviewing this change; I checked the RFC, the tests and the diff
myself and am responsible for it.