Width and Height was not associated and provided to decoder for H264 streams which have Nalus before SPS

Summary:
There is an issue with WebRTC for handling of certain H.264 bitstreams where the packets forming the H.264 stream has non-zero packets before the packet containing SPS.

Typically a IDR (key frame) will have SPS/PPS (if present) or the IDR slice in the first packet.
But this is not required in all cases, for example when packetization-mode = 0, you can have each NALU in separate packet. And certain NALUs can exist before SPS, for example SEI, AUD.

The way WebRTC associates width/height to encoded frames is by tracking the dependency of IDR slices to SPS/PPS.
RTP packets containing SPS/PPS have correct width/height stored in them during parsing of SPS in RtpDepacketizerH264::ProcessStapAOrSingleNalu
IDR packets refer to SPS using ppsid, spsid and the width/height fields get transferred from packet containing SPS to IDR packet in H264SpsPpsTracker::CopyAndFixBitstream.

When packets are assembled into a single encoded H264 frame in PacketBuffer::FindFrames, the loop goes through all the packets/nalus in backward scan from last RTP packet of IDR to first one.
Hence the order of NALUs during this scan is : Last parts of IDR Slice -> Mid parts of IDR Slice RTP packet -> first IDR slice Packet (this should have correct width / height) -> RTP packet containing SPS/PPS (this should have correct width/height)
start_index points to the first RTP packet of the frame and its passed into RtpFrameObject's constructor. RtpFrameObject will use the width/height stored in first RTP packet.

This works fine as long as the first RTP packet has width/height, which will be the case if first RTP packet is IDR or SPS.
In H.264 first RTP packet may be AUD, SEI in those cases, RtpFrameObject will create IDR with width/height = 0 and this causes problem for Android hardware decoders.
On Android hardware decoders rely on correct width/height to initialize the hardware decoder.

Verified on real scenario that we have.
Simulated on AppRTCMobile on IOS Simulator
Added unit tests : ninja -C out/Default && ./out/Default/modules_unittests --gtest_filter=*FrameResolution*

Bug: webrtc:11025
Change-Id: Ie2273aae5e81fd62497e1add084876a3aa05af4d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156260
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Shyam Sadhwani <shyamsadhwani@fb.com>
Cr-Commit-Position: refs/heads/master@{#29515}
2 files changed
tree: a63ff001a8b83d99362cf256fe9f85edb207427e
  1. api/
  2. audio/
  3. build_overrides/
  4. call/
  5. common_audio/
  6. common_video/
  7. data/
  8. docs/
  9. examples/
  10. logging/
  11. media/
  12. modules/
  13. p2p/
  14. pc/
  15. resources/
  16. rtc_base/
  17. rtc_tools/
  18. sdk/
  19. stats/
  20. style-guide/
  21. system_wrappers/
  22. test/
  23. tools_webrtc/
  24. video/
  25. .clang-format
  26. .git-blame-ignore-revs
  27. .gitignore
  28. .gn
  29. .vpython
  30. abseil-in-webrtc.md
  31. AUTHORS
  32. BUILD.gn
  33. CODE_OF_CONDUCT.md
  34. codereview.settings
  35. common_types.h
  36. DEPS
  37. ENG_REVIEW_OWNERS
  38. LICENSE
  39. license_template.txt
  40. native-api.md
  41. OWNERS
  42. PATENTS
  43. PRESUBMIT.py
  44. presubmit_test.py
  45. presubmit_test_mocks.py
  46. pylintrc
  47. README.chromium
  48. README.md
  49. style-guide.md
  50. WATCHLISTS
  51. webrtc.gni
  52. whitespace.txt
README.md

WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.

Development

See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.

Authoritative list of directories that contain the native API header files.

More info